How to start a React Project in 2023
robinwieruch.de
robinwieruch.de
And now I just read this article, and, well, I'm even less motivated to get into this stuff. Is this just a really bad time for React? Or is it always such a chaotic changing climate around it?
Angular lost me going from 1-2, for example. Not because Angular 2 was bad, but because they decided they needed to do a fresh start. Vue2 -> Vue3 is almost the same story, though I stuck with that one. Rails? Oh boy...PHP? That is a damn nightmare. Tell me without looking at the docs what the best practices should be for even the most basic stuff.
If I have to rewrite large portions of my code for a new revision, even a major one, you are most certainly doing it wrong. If you want to rewrite the project, at least care to add a compatibility layer (which some projects have done, but most have not).
I just did the "create-next-app" and, I can't claim that all of that is not eventually needed in some form or the other; however, it is mind blowing that I think I know how to hello world a video game with less crap here.
That point is crazy to me. Yes, if you are making a multi platform game, you will need a ton of boilerplate. Will far outstrip the boilerplate that this react thing gave me. Same for if you have a large team building a web based application.
However, for dipping your toes in to the frontend part of a web page, it is boggling to me that they also push so much on you that are not directly front end concerns. Worse, there is a ton here to help with "fast" web pages. Problem is, most of the slow pages out there are slow because the teams just can't keep up with all of these shifts in how you are supposed to do things. Every page that is actually fast, simply stayed with how to do things years ago.
Not really. Most pages are slow not because they're using outdated techniques, or they're still serving everything from a large Windows Server running an ancient version of .NET. Those old react pages aren't slow either because they "didn't keep up", they still run fine.
Pages are slow because of the obscene amounts of tracking and "user conversion" techniques. Banners, notices, trackers to make note of everything you do on the page, trackers to make note of errors, third party trackers, ads everywhere because a simple static one isn't good enough, list goes on.
Guess what those old pages that "stayed fast" don't have? You guessed it, all those BS trackers, they weren't readily available back then.
And yeah, for public sites, tracking almost certainly dominates how slow things are. I was thinking of internal tooling sites. I remember how fast many of the tools were when I started at the last job. I also remember how slow all of them were getting as I was leaving said job. It is more than a touch insane.
There was this really horrific one I did experience, come to find out the entire company is relying on this angular app that connects to an ancient mac mini that IT is responsible for but mostly forgot about. Wasn't a large company, but they weren't stalling in growth!
I can't really cite examples, as I'm not at the old job. But silly things like our "news" homepage was getting so that it lazy loaded all of the news. HR things would load in parts, too. And issue tracking seemed to constantly be a mess.
The tool my team controlled had bloated to excessive points. Some of that was almost certainly my fault. I had designed a somewhat granular backend. That said, I remember things were certainly faster before we had a ton of redux based code to do things.
You are correct that there can be more interactions on the frontend, but frontends were both faster and easier to deal with when they did not do all of this. For many internal tools, bouncing back the validation from the backend is also easier to understand than the validation that the website is providing.
I suspect it is a bit of a curve. Zero interaction on the front is not pleasant. All of the state replicated on the front is also not useful and likely to be more problematic.
And I know it is more than a straw man. There really were bad sites like that. We have swung to another side of bad code, though.
Not that I like the idea of several MBs of JS being sent over the wire either... I know that is also a thing, not to mention poor state mgt, which is also a regular occurrence (most angular apps have many state bugs).
Personally, I'm not too bothered by client rendered/driven apps... They can often be split accordingly, and it's reasonable to stay under 500kb JS payload for a moderately sized web application. Not that everyone has as much awareness. I think of the browser as a thick-ish client toolkit as much as it is a rendering platform. That doesn't mean SPA is the right way for everything. I wouldn't do it for a mostly text content site (news, blog, etc). And most of my work is web based applications, not text driven content sites.
There's even a new crop of frameworks coming up now, like Astro, Qwik, Solid, etc. Plus a paradigm shift towards MPA and abstractions like server components.
Before that you had 2-3 years of stable blindfolds before knowing what the other teams cooked secretly.
I have been trying to get into front end JS development and it feels like every guide is broken within 6 months... When I actually succeed at one part, I then realize that to add testing, or bundling, I need to follow this other guide, which isn't stable anymore, and then breaks the whole project. I have tried 4 or 5 times now trying different frameworks and "quick start" features or following recent YouTube videos, giving it 3-5 hours each time, and I can't get a working typescript based UI + test + bundler to work.
Edit: I should say, I'm open to any _working_ guides that go from start to bundle that you all know about...
Too many projects. Not enough focus. Everyone creates their "alternative".
Sorry you're experiencing this. It's not "just React" though, it's pretty much all Javascript (or Typescript) now. Especially front-end, but I swear, JS/TS on the front or back is like trying to learn to drive a car in heavy traffic while also repairing the brake lines which are malfunctioning
I would also argue that poor web standards support hinders the future of React, especially for web components.
Like yourself I also prefer written docs, but trying to find such structured info was an exercise in futility. At the end I used my existing Pluralsight subscription and went through the React 18 path they have which is around 18 hours or so in total. The courses covered different topics around React like components, hooks, testing etc. Good thing is the courses also have full transcripts! I followed them along and created some small apps myself in the process. Now I'm pretty much sure I can handle working with React in a normal job setting. You might want to consider that option. To be honest FE seems like programming on easy mode compared to some of the things I'm used to working on in my day to day. If you are an experienced programmer you should have no problem getting caught up to speed on that relatively quickly.
Chances are you aren’t materially smarter than the hoards of smart people doing this day-to-day and find it ‘not-easy-mode’, and that you’re instead in deep Dunning-Kruger territory.
You watched the VHS about foundation repair but you’re yet to get thrown off-course when you find out that you don’t know what carbon-fibre stucco lath is.
I'm sure React has it's own intricacies just like every other tool and it takes time to appreciate those. I can see how managing your reconciliation state can become a big hurdle in larger projects for example. I've done WPF, MFC and a lot of other things on native desktop programming and the ideas in React are not that different. Those ideas in the browser context are actually easier to deal with than on a native platform hence my "easy mode" thought.
I've been a fan for several years now, almost a decade and I adopted the hooks relatively early on as well. It feels right, even if something under the covers are complex, you don't have to think about a lot of that when you aren't looking at it.
The Javascript ecosystem tends to have lots of flux with new libraries and ways of doing things coming out all the time. I have found React to be one of the most stable libraries around. I can update versions of React and my code continues to work as before. Libraries that I depend on tend to have more issues with this and version updates can mean changes in the API for the library or a newer version of React not being supported.
My suggestion for someone learning React would be to start with the simplest way of getting started and learn React before learning concepts brought in with frameworks, etc. If I were to start learning React today, I would start with Vite.
Svelte does it most simply though. I've been doing React for years now, but it still feels ridiculous to me compared to Svelte and others.
I honestly think people who like React have Stockholm syndrome. And everyone is taken hostage since it's the most popular one. UseEffect is ridiculous, hooks in general are ridiculous, mapping over array to create elements is ridiculous, having no tools out of the box for JSX to do simpler if else, for loops, etc. All these bizarre concepts just to hack around JS to make all of it work. And in the end it's all very difficult to read and reason. And all this bizarre boilerplate is just tech debt. It does nothing to describe what is actually going on in that component.
The newer frameworks (Svelte, SolidJS, etc) definitely seem to improve on React. But it will take some time for the wider ecosystem of libraries to catch up (and ideally for one of the newer frameworks to establish themselves as the next-gen "winner)
As someone who was in a similar boat (2 decades of .Net essentially, with a lot of HTML/JS but no frameworks), I found jumping into Angular very nice in this regard.
New versions every 6 months but not with "changing things for the sake of change", actual small but incremental improvements. The documentation I've found to be great, and since it is "opinionated" it easy to jump between multiple projects and not feel completely lost.
It seems a lot of flak that Angular gets is because it is "opionated" but I look at this as a major positive.
I've jumped between React projects and have been bewildered at how different they all are.
The whole framework vs. library thing.
Edit: Found this old GitHub issue I stumpled upon when looking up why this performance improvement wasn't the default.. I think these comments are interesting:
> Both OnPush and zone coalescing would, however, change the default semantics of building Angular apps. This is outside the scope of the feature.
> We did discuss this a couple of months ago and felt that we shouldn’t since it would complicate things for new user which are not familiar with change detection.
I have become to love it.
However, it should be way simpler now with the upcoming Angular version that's supporting signals now.
Signals look identical to React hooks.
https://2022.ng-conf.org/a-new-layout-ahead
More recent versions (I'm currently on 15) don't seem to have these issues, as least from my working with them. I started an enterprise product on version 13, the upgrade path to 15 has been smooth and so far, so good.
The old doc was like 10 years old, they just officialized the new one this week.
Create React App was the recommended way to build a React app for like forever but Facebook stopped maintaining it 2 or 3 years ago. The drop-in replacement is Vite.
And have you checked Web 3.0?
It’s simpler to learn. Guides are phenomenal. Creator is a designer and author of Vite.
React is great in that it’s being developed by a great team of diverse engineers. However diversity comes with differing opinions of end user experiences.
In the world of product development and innovation, the role of a designer is often more impactful than that of an engineer, especially when it comes to shaping the overall user experience.
Designers possess the unique ability to understand the end user's needs, desires, and challenges, translating those insights into functional and aesthetically pleasing solutions. Their holistic perspective allows them to balance form and function in a way that elevates the value of the end product.
While engineers excel at the technical aspects of a project, ensuring that the underlying systems function properly and meet performance specifications, designers take a more human-centered approach. They focus on usability, ergonomics, and aesthetics, often serving as a bridge between the technical and the emotional aspects of a product. This ability to understand and empathize with the user is invaluable, as it ensures that the product not only performs well but also resonates with its intended audience on a deeper level.
Collaboration between designers and engineers is crucial, as their combined skills and expertise can lead to groundbreaking innovations. However, it is the designer's intuitive understanding of the user experience that often plays a key role in creating a product that stands out from the competition and truly resonates with consumers. By prioritizing the needs and desires of the end user, designers help to create products that are both functional and emotionally engaging, ultimately enhancing the overall success of a project.
Thus why the more granular and slower approach such as Vue is what I think is software framework done right.
And I manage several junior developers and I've seen them struggle to understand all of these, even over many months including pair programming and code review feedback.
That being said, I was able to jump into an existing codebase and be useful in about a week with very little prior knowledge of React (just some dabbling in React Native pre-hooks), so I don't think it's hard to learn enough to start doing useful things with it, especially if you already know Javascript/Typescript.
And I would agree that I've struggled much more with other React libraries than core React itself. It's been a long time since I've had to look anything up for core React hooks, I can write lots of React code (in Typescript) and be relatively confident it will work as intended, barring some dumb mistake I made or a misunderstanding of how the data flows in the existing codebase, as long as it compiles.
It is really unappealing and driven by "smart" people.
1. The "tutorials" are terrible. 2. The tooling - webpack etc - is terrible. 3. Things change too quickly. 4. There are an absurd number of technical layers trying to make frontend "safe" like backend EG typescript.
I like react as long as I am the only author involved. All the FE devs I've been forced to work with pull in an asinine number of external dependencies, weave painfully elaborate webpack setups, among many other things. I can't stand it.
I've have some side projects in typescript, e.g. https://aperocky.com/cellular-automata/, and none of it needed react or any of the common frameworks. Just pure HTML and javascript, turns out it's not that hard.
I've had much better mileage with Vue.js - far more opinionated (which I like in a framework).
> Is this just a really bad time for React
There are some concepts you may struggle with. That's to be expected.
But the new docs don't represent negative change. The old docs were not representative of how most react is written today. That was really confusing for newcomers. There's nothing "wrong" with doing it the old way, but most jobs that use React are going to require you to work with hooks in some capacity.
You wouldn’t see this shit otherwise.
Especially with Meta’s resources, there were MUCH better ways to handle React’s documentation situation. The JS community, but especially React, just happens to set the bar on the floor as far as end user communication goes, compared to other open-source projects, say…Django, with like…two paid staff and a bunch of volunteers.
This isn’t just the cost of progress. It’s laziness.
Now, I like React, more or less. But some of the discussion around React reminds me of Wimp Lo from Kung Pow ("...we trained him wrong as a joke..."). For instance, the whole immutability for performance thing (I get it, but lol). Or statements like this: "[w]ith Hooks, you can extract stateful logic from a component so it can be tested independently and reused" (thank God someone finally figured out how to reuse stateful logic in software /s).
Sure enough, they had. I was left in a state somewhere between dumbfounded and amused. Reading the justifications for what they'd done just made both reactions more intense.
How is `react new` not a thing?
It's like telling someone who wanna learn Python to start with Django.
I've always felt that the biggest problem with the Javascript ecosystem is that it's entirely too preoccupied with syntax. Remember CoffeeScript!? Some of the most influential forces in the community can waste entire years bikeshedding some syntactic thing that is mostly a matter of personal aesthetics. And this trickles down to the grunts trying to ship a product.
It's a fundamental drawback to Javascripts other strengths. And that's the reason it's so easy to find Express apps that are hot garbage. It's one of the most enduring myths that If you know Javascript, you can write a Node app.
It only works because software has been such an economically productive force, that having thousands of professionals spending weeks deciding whether semicolons are good or bad, or fighting their webpack configs, or migrating for loops to array methods... whatever... it still makes money at the end of the day.
jquery was a library. React is a framework because you're passing in code to React, which it then uses to do things like render components and respond to state changes.
React misleadingly called itself a library to distinguish itself from more batteries-included frameworks like Angular.
If I build an app on React, there's not much chance I'm ever going to swap it out for anything else, thus it's a framework.
If I use Twilio's JS library for sending SMS and then decide to swap to a different vendor (or a different library for the Twilio API) that's fairly easy with the right design.
Preact exists though? And literally emulates React's API. It even has a guide for aliasing the Preact module as React with your bundler so your app wouldn't need any code changes. Can a framework do that?
1. Longevity
2. Market share
3. Developer supply
4. Third party support. (Ecosystem)
5. Technically mature and advanced
Among those criteria react excels at first four. And is good enough for the fifth.
So, most business will pick react. Depending on the local environment, some may pick angular for those same reason.
All newer, better technologies will be evaluated afterwards and only if react and angular prove to be too troublesome for the business's current needs.
This is why "react new" is not a thing. This sentiment is echoed almost weekly basis. Recent threads were under title "React is holding me hostage"
Hence newer projects are likely to pick react instead of solid/svelte
It's a library, less of a framework. For frameworks, you can bring together your own, or use next.js etc. For that matter, getting started with react/jsx and vite.js or parcel are easy enough.
The ecosystem is confusing, but I'd argue it's still quite straightforward to start a new project: either use one of Vite's basic React templates or Next if you want an opinionated framework.
> `react new`
This is basically what create-react-app was, but the community came out with better options.
Sorry for the rant :-)
The question I'd like to explore, is what if you just author web pages in html, css, and javascript? I feel like web standards are very good, browsers are incredibly powerful, to the point it may be safe to attempt this approach.
Writing pages for modern browsers, with no polyfills, no transpilers, is quite pleasant. Writing JavaScript with arrow functions and destructuring and jquery-esque selector methods, and consistent event apis, is very pleasant. The module system is fine (I'm warming up to it). But how many professional front-end or full-stack folks would even know?
JS hatred is a huge problem. It has driven huge projects since XHR was invented. Google's GWT was one of the first, targeted at Java devs. jQuery was a bit js hatey, too (early devs didn't know where js stopped and jquery began, including me). And js hatred continues to drive countless projects promising devs 'you don't have to learn js'.
I believe this attitude is utterly foolish. To build a webapp without knowing the foundations of the web is foolish. And much of the misery devs experience is because they weren't willing to do the harder, but wiser, thing and just suck it up, and learn how to program browsers. Literally every dev who's ever believed the line about not needing to know html, css, or js has discovered how utterly false this is.
(TypeScript is actually an exception here since it's a strict superset of JavaScript, so if you are a TS expert you are already a JS expert)
Something we haven't done a great job of, so far, is talking about how you can use Next.js for SPAs or client-only React sites. You can start with basic HTML/CSS/JS, deploy and host anywhere, and then optionally opt-into features that require using a server (and host somewhere like a Node.js server or through a Docker container). Next.js can generate an HTML file per route, rather than having one large SPA bundle.
There's been a lot of feedback around CRA no longer being recommended and folks looking for a replacement[1]—and uncertainty if Next.js is the correct solution. We've been working on some better docs[2] that help explain how to use Next.js without a server.
[1]: https://twitter.com/dan_abramov/status/1636886736784457734
It's about the burden of mixing SSR and CSR, Vercel's next.js and sveltekit are both SSR-first by design no matter how you sugarcoat it. I may use them when I need SSR one day, but please stop overselling it as CSR-ready.
Talking about documentation, please do not forget Vuejs, it has the best document all in one place in the JS ecosystem, by the way, it is a true CSR SPA and its SSR(nuxt) is truly an opt-in.
So one more time, explain like I'm five, what does next.js actually Do?
Next level (no pun intended): Makes working with React easy.
And another: Next.js provides tools for web developers (rendering UI components, fetching data from APIs, optimizing and displaying images and fonts, etc.) to create fast web sites/apps.
I'm not dismissing Next.js or you, I just feel like these aren't great points in a vacuum.
Obviously these things can be done without using Next, React or even Javascript, like you say, but it all comes in a really well-integrated solution that mostly just works.
The point is that it's not clear what exactly Next does, let alone why it does those things. In my mind, Next (and friends) just helps smooth the edges of all aspects of modern web development. That's just not a very specific statement. Also, a lot of those edges aren't so sharp for a lot of use cases since modern browsers and servers offer the same functionality. I still think Next and friends are useful because the edges may not be as sharp, but there are quite a lot of them.
E.g. a traditional SPA (client only) can handle dynamic routes without extra intervention of a higher level router.
Otherwise yes SSG can be useful :)
If you have rewrites it is not anywhere that purely takes HTML/CSS/JS.
If I have `pages/blog/index.tsx` in my NextJS app this will get output to `blog.html` and can be deployed like a static site without further top-level routing.
You're referring to static routes.
This is not the same as any non-React or non-Next SPA either way. A lot of them have SPA support i.e. route anything to index if there is no match. They may not have random rewrite support though.
And that IMO is kind of where the problem is - what level of abstraction should be added? Lots of beginners had problems because they were bombarded with the many confusing things to install to make something, and more often than not routing was one of them. It's just that Next.JS' is opinionated, but I'd argue so is everything else.
And many believe they do not need server-side JavaScript at all. We just need an SPA to speak to our API. We do not need "best of both worlds". Next is just more complexity over plain old client-side React. That's why some people including me are looking for alternatives to React recently. Next is not what we want or need.
- create-react-app
- React
- Vite
- Webpack
- esbuild
- TypeScript
- ESLint
- Vue
- Remix
- Next.js
- OpenNext
- Astro
- Gatsby
- Parcel
- Turborepo
- React Native
- Expo
- Tauri
- Electron
- SvelteKitThis comment encapsulates the experience so, so well. I have no idea what is going on, everyone tends to have a very strong opinion on which way to go, but no one can provide an explanation of the baby steps in how to get started. Or even why to get started. It's maddening.
Solution 2: Otherwise you could try to use CSS modules (Vite supports them out-of-the-box I think).
Solution 3: Otherwise you could try one of the many "CSS-in-JS" libraries like styled-components.
Personally I'm using the solution 1, did for more than a decade, works fine, scales well, nothing to install and learn, just old straightforward CSS.
Separation of concerns with what are essentially totally different markup languages is best when you can. We tolerate it with JSX because there isn't a fantastic first-class declarative way to express an object, a list of objects, or filtering in HTML. (I have seen WebComponents and the MDN tutorial seemed like taking a step back.)
I use TailwindCSS [1] for all my styling needs and couldn't be happier.
If you really want scoped CSS in React this approach [2] can also work, and it makes it easy to use tailwind if you want.
[2] https://miyauchi.dev/posts/lib-vite-tailwindcss/#css-modules
Instead pick a stable tech. In js framework land, no tech is stable. But relatively speaking, react, Vue and Angular are more stable and popular. Among these Vue is more newbie friendly than others.
So, I would start with Vue. Checkout laracasts course on vue 3 to get started.
So since the person we're making suggestions to is (so far as I'm aware, and I'm pretty sure I remembered my dried frog pills today) very definitely -not- me, I think I agree entirely with Vue as a starting point.
Eg. Why would I need to care about electron and react native for a web app?
- TypeScript (langauge) - React (framework) - Vite (build tooling) - ESLint (linter)
That's not really any different to any other language. Maybe you have one extra tool in there for the build step.
1) "How to start a Java project" - very vague, the article will arrive at your doorstep in book form as there are tons of possible ways depending on the use case
2) "How to start a REST API backend in Java" - a handful of bigger contenders are left on the table; some feature and performance comparisons could be handy
3) "How to start a REST API backend using Spring Boot" - a focused set of steps that leaves you with a controller class that will happily greet the user when a GET request is sent towards its general direction. I don't really want to explore the possibility of creating an application using NetBeans Platform or whatever at this point.
Here the casual reader might think that we are at level 3, but it seems that it's closer to level 1.
That we have a wealth of good solutions is amazing, and it feels like people will find anything to complain about. If we had just a couple it’s lock-in or bad ecosystem. When you have a lot it’s messy and stupid.
It feels like a communist Russian coming to a US grocery store in the 80s and concluding it’s ridiculous they have too many choices how can they ever decide what to eat.
Note that's also a "sandbox" for development purposes. If I were creating a new production app today, I would probably use Vite, which uses esbuild under the hood anyway. It's super easy to get started [1] with not only React, but also Lit or Vue or any other number of pre-configured templates, and it takes care of all the drudgery of bundling and tests for you so that you can get straight to work.
[0] https://github.com/splitgraph/madatdata/tree/main/packages/t...
If I build an MPA, why should I choose Astro if I can choose Rails? That’s a serious question to the HN community, not a rhetorical one - would very much love to learn if there’s something new here.
Rails, Django/Flask or even Apache Struts or Java Spring would do good in this use case.
I get that you don't like RSCs, that's fine you're allowed to have that opinion, but you can't justify it by saying it's a CRUD framework. Apples and oranges.
The problem is that as soon as your frontend needs to be dynamic, these frameworks do nothing for you. You can do it on your own by using a library like React and making API calls, but that comes with its own set of issues.
RSCs are a way of addressing these issues by making UI and data streaming a core feature of the framework.
With Django you create an API endpoint that queries the database (this already gets complicated if you want types), then on the frontend fetch that endpoint (using some kind of library to manage the request complexity for you), then render that data.
With RSCs you write a server component that grabs data from the database directly and render it.
GraphQL addresses some of the same problems, but has its own set of issues. It's all about tradeoffs.
There's some term confusion. "Static pages" is a different concept -- when there's no code executed on the server, server can only serve static content (no DB naturally), usually from a CDN that can cache responses. We're talking here about dynamic pages.
> a server component that grabs data from the database directly and render it.
Render where?
1. If it renders it to the html content for the browser, it's called "templating", and all the frameworks have been doing it for 20+ years (e.g. ASP, JSP, Jinja).
2. Render to the browser -- it still need to pass that data from server to browser, there's no way around it. And the idea of abstracting that, so the user would not know or care where the code is executed is not new at all. There were multiple attempts, for example see JSF, released on 2001. It burned in flames because you really want and need to know where the code is run.
And there never-ending attempts to at least write in the same language on server and browser, without abstracting the XMLHttpRequest (aka AJAX aka Fetch) layer. For example Node.js -- to use JS on server. Or GWT -- to use Java in browser (died, because you still absolutely want to know how it will be compiled to JS). Now Kotlin compiles to JS. Those are successful to a point. And the ultimate answer to bring all the languages to browser -- WebAssembly.
My point is -- all the attempts aiming to abstract away client-server boundary has been an utterly obvious failure. But if RSC does not aim to abstract it, then it's not different than technologies from 1999, but in Javascript.
For example, an admin panel for changing your models (like Django Admin), performance monitoring like Phoenix's LiveDashboard.
Rails is faster for building an MVP. But it's significantly worse than a project built with a typed language when it comes to extending and maintaining.
I thought I had misconfigured Sentry (for error logging) because the type of errors that plague Rails, or any language that is not typed, just don't happen with a typed language (unknown method called on NilClass).
We can decide to make a column in the DB to no longer allow NULL values, and we are immediately notified by the TypeScript compiler about every line that needs to be updated.
The Ruby/Rails magic feels like its not worth it for long-term or even short-term maintenance.
I'm not sure that the academic work on software engineering really bares this out. Th Static vs. Dynamic debate is far from settled and increasingly looks to me like a matter of preference.
Can you elaborate on this? Is this using something like knex/objection or something else?
Is there something that will do this if one is using mostly raw sql with knex?
I don't have experience with Knex so I, unfortunately, don't have an answer to your question.
RSCs (and Next) are (going to be) built for dynamic pages. Loading new data from the backend is as simple as editing an ERB template, and you get updates on top of that. Suddenly you don't need to think about APIs nearly as much, you don't need to worry about making fetch requests, you don't need separate codebases.
If Rails decides to make data and UI streaming a primary building block then that would be awesome. Until then, that's why you would use RSCs.
I'm glad we have several options for building modern frontends, I'm very excited to see how things will shake up in the next few years.
In the web browsers eyes, a Next.js app is just a plain old html page load when you navigate within the app. I believe the days of SPA’s and mounting on the bang# sign are dead. Some smart folks realized that it was more computational efficient to output plain old html like back in the days.
The most I've seen it used is for backporting fixes from future Rails versions or other gems that are hard to update - and again it's easy to do this in an organized and clean way
Just because ruby gives you the tools to do stupid things (and every language lets you do stupid things) doesn't mean that you should do them in a real business app
You could stick with webpack. Its defaults have gotten better, even if CRA never quite aligned with that shift. (It is still slow and prone to config-related crankiness, but you don't need two thirds of what CRA ejected.)
So far in my own development, I find I generally prefer to use esbuild directly rather than the added weight of Vite and sometimes Vite feels like Create-React-App in that way that it obscures the power of the underlying components, though unlike Create-React-App Vite doesn't offer any sort of "eject" option. Vite adds some nice things like HMR support, but also now that browsers support script type="module" you can get nice dev experiences from unbundled modules without HMR and tools like esbuild/webpack become more of a "final pass" for Production rather than an always present development need. (Which is how Vite powers things like HMR, too, but you can do it by hand so easily now, I haven't yet been convinced to use Vite in a project.)
So, let's recap the real rad method to start a React Project in 2023:
npx webpack-cli init Advantages:
1. You get what you want: a web bundler and a dev server
2. No premature bargains or decisions, all this base belongs to you.
3. Expand infinitely and meaningfully with modules you will want to utilize for covering your app's use-case, starting with react and react-dom
npx webpack-cli init Disadvantages:
1. Have to learn about your problems and discover solutions
2. Have to scroll through solutions documentation and configure them manually
3. Have to own your technical decisions and structure
No I just want to build an app fast. Frameworks allows this to. One NPX command gets you a running app.
> 2. No premature bargains or decisions, all this base belongs to you.
Cool now you're the only snowflake in the world with a setup like your custom setup. All online help on frameworks people commonly use is useless to you, good luck
> 3. Expand infinitely and meaningfully with modules you will want to utilize for covering your app's use-case, starting with react and react-dom
Nope, with this naive approach you will soon encounter scalability problems, you will need code splitting, (per page maybe?), and you will inevitably re invent NextJS or a similar framework.
> 1. Have to learn about your problems and discover solutions
I want to focus on my client's problems not my problems
> 2. Have to scroll through solutions documentation and configure them manually
Yep
> 3. Have to own your technical decisions and structure
There is enough to own in this world. I guess you're also the kind of person who want to build your own Linux Distro and own the entire stack?
If you don't have solid experience already: Don't plan your projects with anything except plain React configured with TypeScript. Use "Create React Application" (cra) to set it up and stick with the standards.
Everything else you can add later - if you need it - and in the mean time you have the chance to move faster without breaking things and make better decisions.
If you already have solid experience: consider this anyway if it is just another web application. I personally at least have seen a lot of time wasted because people always deviate from the standards both in React, Angular and Maven.
When time comes to add things we think we need, think about the tokens mentioned in https://boringtechnology.club
I do love NextJS but I will try a few more Fresh projects soon.
The biggest svelte complaint I see is that there aren’t enough libraries. That’s because it is trivial to built things with svelte. And as a UI engineer you should know how to build, not just npm install some-shit
Source: former UI tech lead, been using react since Dec 2015 and have built apps with it that are used by millions of users.
No, that’s not a good sign for a framework. If you need an enormous ecosystem of helpers to get anything done, that’s a detriment. Svelte doesn’t have libraries because it doesn’t need them. Kit comes with tons of out of the box features, and there’s nothing I can’t achieve with either:
1. My own JavaScript code. 2. An NPM package IF need be.
Seriously. Svelte has everything react has, with a much better developer experience. It’s the evolution of vanilla web, and even if I got canned tomorrow, I would search until I found another job with either stack freedom or svelte as it’s framework.
I genuinely don’t get why the webdev community insists in making their jobs so difficult by refusing to actually learn the tools they’re using. CRA is unnecessary, Next.js is unnecessary. The simple tutorial on the React website gives you everything you need to get started, and you can research which other tools you need once and be good forever.
If you only need a bundler: Vite
If you want to be happy: Don't.
I really don't understand why the outcry even exists. It's recommended for a reason and whining about how SPAs still exists misses that no one ever said that it doesn't. The only thing people are mad about is that Vite didn't make the list but that's understandable because I could never tell the new React developers we just hired to do this project by themselves with Vite. But with Next.js (or whatever else on the list) it was a matter of "File here, this URL, your React component here. Don't think about SSR I'll take care of it if we need it."
And it just works. Even too good because they run into issues so rarely that I forget that they make so much progress and we're already on our 3rd project with it. And they literally started coding 5 months ago.
And if you care about what's going on under the hood, guess what? You're one Bing chat away from finding Vite and a few commands to have it running locally. Want SSR now too? Guess again, you are already setup to do exactly that in a way more ergonomic way than the low level Vite plugin (which I like, but I would never be able to hand-off to other developers)
Is it? This is the first I’ve heard of this fantastic news. What’s changed to have caused the increased importance?
A lot of leading maintainers now feel that the best solution is more of a middle ground where frameworks support both server side and client side rendering with the developers given the flexibility to choose what renders where (or on both) depending on the app's needs. React is driving a lot of this now with server side components, but there's a lot of frameworks that were doing it beforehand which has inspired much of what they're doing now.
Vite seems like the best batteries-included solution that is still relatively lightweight compared to going all in on a framework like Next.
I feel like the React folks are in this unfortunate position where they have to cater to people differently than other JavaScript libraries do, because to a lot of people, "React" means more than just a JavaScript library. And to some, they've never written JavaScript without React or even without build tools for that matter. I personally prefer the less-is-more approach to learning JS or any JS library (start with an .html file and a <script> tag, work your way up) and even though that may be a healthier way of learning React, it might frustrate more new users who just wanna make a shiny app.
Nvm, roadmap.sh/frontend came to my mind.
The same could ultimately happen to React as well. I'm working on a new project right now using Remix, which is great, but I've also realized that really nothing I've done wouldn't have worked just as well without React. Fortunately I really enjoy Remix, but if SvelteKit or SolidStart provide a similar experience I don't really see why I would stick with React.
Angular? Migrating from one major to another was always source of great pain.
My only concern are signals. They seem like worse Observables just for the sake of something new. Hope they never get added
If you're ok with learning something with less adoption but similar batteries-included feel I'd recommend learning SvelteKit. I see it do a lot of things that Angular does well without failing were it's bad (i.e. breaking changes every six months).
Anecdotally after 6 years of React, switching back to Angular it has a huge learning curve. Such a large surface area with zonejs, rxjs, modules. I feel productive with it now and actually prefer services + rxjs to redux. I like how much is included and has established pattern but it feels very heavy handed, just adding a single component involves a stupid amount of boilerplat.
If you are new to angular, then I suggest stay away and come back in a year or two because Angular is going through a major paradigm shift. From webpack to esbuild, from zones to signals, from Rxjs everywhere to signals for synchronous change detection etc.
But also Angular has egregiously big build times as your project scales up, and that sucks.
A 56 module Angular 15 codebase `npm start` takes 10 seconds, and compiles after change faster than a browser refresh. The build takes 67 seconds.
What scale up are you talking about so that I know in the future what to look out for?
Do you know which parts of the build are taking the longest? Transpiling, bundling etc?
If you don’t want to work on the bleeding edge, then don’t upgrade right away. That’s true of literally every library out there.
And IMO it’s trivial to host a next app just about anywhere. Vercel has done a much better job with portability than you would typically expect from similar companies.
The docs for NextJS are also just… rock solid. It really feels like they cover everything.
I’m not affiliated, just a happy developer using their framework.
I'm more than a little wary, as I have seen how easily out of hand the front end can get. Any "services" we are writing will be backend and mirroring all of that effort on the frontend feels very misguided. Not at all happy that the first thing I stumble into is looking to be a giant featured framework.
I genuinely don't understand why so many people want to abstract the platform away in projects that only run on a single platform (the browser in this case). You want to be as close to your platform as possible if you care about performance and resource use.
So make a cute name and logo, make a website using words like "superhero" and "fun!", and make an announcement on Hacker News (where someone will invariably make some comment about not needing a framework lol)... then toss it in the pile with the thousands of other (unmaintained) front end frameworks.
Have fun with your performance and resource use, though. Sounds really interesting.
It’s a batteries included React framework for scaffolding out a Stripe level frontend, complete with a blog and documentation.
It’s built on top of Next.js, and is essentially free to host. :)
Please check out my minimum viable prototype and tell me what you think: https://elegantframework.com
It felt like "ravioli code" to me, and it seemed wrong that everyone was reluctant to use "eject", but then you couldn't configure any of the underlying tools, like Webpack, easily either.
Tools should be easily composable, they shouldn't be clumped together with an inflexible "ravioli" abstraction.
I’m not disparaging it generally though. It was truly useful to many people and reduced barriers to allowing people to more easily experience React. Arguably, the mess of needing to understand internals of CRA to solve weird bugs or needing to eject was in some ways a good thing. Perhaps people wouldn’t have made it that far without the initial ease of building with react!
You’re absolutely right though. The design of CRA imposed a lot of inevitable issues. Partially due to how webpack works and due to (in my opinion) the fragility of the npm ecosystem. There was so much complexity and so many dependencies. Perhaps some of these things changed for the better over time — it has been a while since I looked at it. The last time I did, that aspect was labyrinthine and awful to navigate when things went wrong.
Definitely, it was neat how the developers gave you a survey if you did use "eject".
But I think the answer is to deal with the issue of making tools more easily composable, or improving the documentation of how to use them, rather than providing the abstraction.
Mostly tbh to stop the freaking thing spawning inotify watchers for the entire contents of node_modules - I don't mind having to do a manual restart when I've changed dependencies and I definitely -do- mind having it eat a shedload of my user's inotify kernel allocation. (I know you can up the allocation, that's not the point, why are you on my lawn? :)
> which day to day tech workers working on internal B2B do not face
That's so true. Good luck explaining to management that the front-end app needs additional cloud resources, such as a server, so we are on the edge of the trend with SSR.
Most apps behind a login face tough architectural / security meetings, defending SSR for their use-case.
Currently, React Router is the only React framework that is even offering a solution to data fetching, mutations and transitions in the CSR space. Very basic problems.
NextJS is not at all a CSR framework. In that space it suffers all the problems your average CRA application has.
Take a look at Amazon’s or Google’s enormous list of cloud products and tell me your eyes don’t glaze over. And that’s not even the full ecosystem, it’s just the products directly supported by one company!
There isn't really two different EC2-like systems, or two different S3 products, there's a new "popular" JS UI framework every year, and if you're still using the older framework 4 years later, it likely needs a heavy rework to upgrade to the latest version.
I "learned" SQS 6 years ago, now I just keep up with the minor feature releases.. same with S3, and Lambda. In the same time I've looked at 4 different UI frameworks that have no overlap but try to do the same and result. Their services exist and they work.. and generally a guide from 5-10 yeas ago is still valid today (though the UI might be different, but the content remains reasonably valid)..
On the other hand NextJS/React have been both productive and intuitive. There are so many examples out there and people are constantly talking about the nuances of both here and on other sites.
It'd be great to see Next integrate something like TRPC/OpenAPI into it so calls to the backend could be statically typed. That would really polish up the end to end experience.
I've been using their superjson library with Remix & its pretty much solved all of my client/server type issues.
I feel like StackOverflow for Svelte is healthy and due to the batteries-included approach for storage and CSS the community is a lot less fragmented than the React community was (and maybe still is, I don't know).
Webpack can be set up with esbuild and will be equally fast, while being more flexible to configure, especially regarding multiple CSS entry points, which to my knowledge is not possible with Vite.
Can anyone with experience replacing CRA with Vite speak to how true this is?
Seriously there is zero reason to use monstrous, painful software unless you're a sadist.
Use something like solid or better yet go for a substantially better language like Imba, especially if you're a startup.
Most folks aren’t trying to win a CS purity contest when founding a company.
But that Imba thing? I rewrote this and the kindest I can say is.... I don't see the value add? Learning it isn't going to be transferable?
function signal(value) {
const subs = []
return {
get: () => value,
set: (newValue) => {
value = newValue
subs.forEach(f => f(value))
},
sub: (action) => subs.push(action),
}
}
Of course Solid's signal implementation is much more robust and have some very mild magic to make the UX better, but the core concept is really simple. Read about Solid's implementation here https://dev.to/ryansolid/building-a-reactive-library-from-sc...
The runtime has to maintain a graph of those signals tree in memory at all time, no? Compared to React that can throw away the vdom after it finished the render.
Just `npm create tamagui@latest`
See: https://tamagui.dev
Happy hacking!