I am rebuilding TrendWeight from the ground up, and this article is about one aspect of that project.
The new TrendWeight was always going to be created with React. That was a given. I fell in love with the core idea of React years ago (given state -> render a UI), and am a drinking-all-the-koolaid fan at this point.
But there are parts of the React ecosystem that are not fun. I don't want to have to figure out bundling. I don't ever want to configure webpack by hand. That's fun for some people, but not me. I just want it to work. And keep in mind that bundling is just *one *of the things you need to figure out to create a production-ready app with React.
Fortunately, there are many "meta frameworks" these days that abstract all of the stuff away and just give you a clean development experience.
For the new TrendWeight, I had to choose one.
Create React App
Create React App (CRA) has been around for a long time. It was created by Facebook (who also made React), so surely it knows how to do React "the right way". Even though it sometimes positions itself as a quick prototyping tool, I have made real apps with it in the past. I have also maintained apps for years that were based on CRA. It works.
But... It feels like it's nearing the end of its prime (if it hasn't already ended).
The dev experience is ok, but subpar compared to the alternatives.
It can only make client-side SPA apps (vs server-rendered apps or hybrid apps)
One of the creators of CRA explained recently that he's not sure CRA is the right long term path for React apps.
CRA does what it does really well, but it just doesn't feel like the right framework to start a new project in if I want to stick with something for years to come and be able to take advantage of future improvements to React.
Next.js
Next.js describes itself as the React framework for production. It has a lot going for it...
It does everything that CRA does and then a lot more.
It can build client-side-only apps but can also build full stack apps that do server-side rendering (SSR), entirely statically generated sites (SSG), or a sort of mix between the two with incremental static regeneration (ISR).
Excellent SEO. Since pages can be either server rendered at runtime or statically rendered at build time. Search engines see the full contents of pages without having to load and run JavaScript.
It handles routing out of the box (normally would use React Router by hand in a CRA or similar framework)
It does code splitting by page automatically
It has a lot of focus on production performance and includes optimizations for image handling, third party script loading, and font loading.
It has a company (Vercel) and a professional team behind it that is committed to continuing to improve it over time.
The Next.js team appears to be collaborating effectively with both the core React team on things like React Server Components and with the Google web team on optimizing apps for the best user experiences.
Sounds great. There are some possible complications that should be noted, though.
Because it's not just a client-side app building framework, most of it's coolest features need a backend server (or a serverless platform, which ultimately still runs on servers).
Many would arguably the "best" place to host a Next.js app is at Vercel. The devops experience is top notch, and everything just works on the day that a new feature is added to Next.js. But Vercel's pricing isn't great if you have a large team or if you use a lot of bandwidth. You can host it elsewhere, but you usually lose some of the magic Vercel brings.
The downsides of Vercel's hosting pricing aren't likely to be an issue for me (I'm a one-person team and TrendWeight isn't popular enough to use more than 1TB of bandwidth in a month).
I really like Next.js. I played with it and fell in love. I'm probably biased at this point, to be fair. The beta version of the new TrendWeight is currently a Next.js app.
Vite
Vite is a relative newcomer for React apps. By the time the chatter about Vite got loud enough for me to look at it, I had already started building the new TrendWeight with Next.js, so this didn't get a super serious look.
It aims to have a blazing fast developer experience while also making all the hard things easy (similar goes to CRA).
It's very new. I can't point to something specific, but it just "feels" not quite as mature as CRA or Next.js.
I've recently used Vite for a small project at work and I was impressed with the speed of starting up the dev server. It was really nice.
I think it's likely that Vite could be a contender as a long term replacement for CRA for those that are looking for the same kinds of dev and build tooling that CRA provides, but with newer techniques.
Even if I had looked at this before picking Next.js, I probably wouldn't have picked it because I want more than just a client-side app. Vite has some SSR support, but it's still experimental.
Remix
Remix *was *around when I started looking at frameworks but it was in a closed beta available only to people willing to pay for it. The launch was... weird. Much of the messaging came across as a bit like, "Good news, we've finally figured out how to build good web apps. You're welcome!" The perceived smugness turned off a lot of people. That and the fact that it was closed made it uninteresting to me at the time.
Fast forward to November 2021 and Remix is now open source and people have been able to start looking at what it could actually do, and parts of it are very interesting.
It's more like Next.js than CRA or Vite in that it is a full stack framework with a server.
The server can run on lots more types of hosts than Next.js including both Cloudflare Workers and Fly.io meaning your "server" can run fully on the "edge" right next to your users.
It presents a different (for React apps, at least) way of thinking about the boundary between client and server. For example, you write functions that are responsible for loading data and that sit beside your components. The Remix server seamlessly uses these functions when rendering your UI without you having to write typical code to call an API to get data. The Remix team asserts that this is a better way.
It's interesting, but similar to the Vite situation, it because interesting well after I had already started building with Next.js. I'm still watching it carefully though.
I'm inclined to build something with it at some point just to get some hands on experience. My games site is due for a refresh, and I may try Remix for that.
Conclusion
As I mentioned above, for TrendWeight I picked Next.js. I've been pretty happy with the choice so far. It's been easy to get up and running, the dev experience and the devops experiences have been great. I haven't run into any major roadblocks, so I'm feeling pretty good about the choice.
If Next.js worked out-of-the-box on Cloudflare Workers (CloudFlare is killing it with their Edge Compute services), I think it would be a slam dunk choice for most of my projects. I'm not sure how motivated Vercel is to make Next.js work on a competitive hosting service though.
