Frameworks & Build Tools

There are many variants of React to choose from today. While optionality is excellent, it can also bring confusion when it's time to decide on your tech stack.

We wrote this guide to bring clarity to the framework discussion.

Each framework will have unique selling points on why you would choose them for your project. Read below to investigate those features a little deeper.

But first, a hot take

For anyone that doesn't already know, Andrew Clark (above) is a core contributor to React whose recent work includes Hooks, Server Components, and Suspense.

Don't overanalyze what Andrew is saying above. You're not losing any "cool points" if your project is still a React SPA. In fact, if your entire app is hidden behind authentication (like a dashboard) - SPAs are still a perfectly valid way to ship it.

This whole framework debate/conversation is still being played out in the open-source community. In general, over the past few years, the pendulum has swung back towards SSR (server-side rendering) because of the benefits it brings to certain types of applications. A lot of developers have realized that SSR can result in a better experience of their product (app OR site), and thats the reason why this pendulum is swinging back in this direction. No one has an agenda, there's no conspiracy.

Some valuable advice when working with these frameworks is don't fight the frameworks' choices. If you disagree philosophically enough with React or the framework at hand - just choose another. Inventing and managing your own internal framework, or bastardizing a meta-framework to fit your needs is likely only going to cause you headaches and lots of effort spent maintaining your app as opposed to improving it.

Read more from the official react documentation on their endorsement of framework usage.

Vanilla React (SPAs)

Given today's options, it is less likely that you should start a React project from scratch and more likely you should reach for a framework. A React SPA could be a good choice for you if:

• The scope of your app is very lightweight and a relatively simple SPA that doesn't need the advantages of server-side rendering. This scope is very unlikely to change anytime soon.
• Your app is not lightweight or straightforward, and your team will manage all dependencies and technical choices you'll likely need to make for the project to succeed (routing, data fetching, etc.).
• Either of the above is true and practically the entire application lives behind authentication

One final reason you might start with plain React is if you are introducing it to a legacy application. This is a good way to slowly migrate different parts of the application first to React, and then to the latest React framework (like Next.js or Remix) if you desire features like SSR.

Whatever you do, don't start with CRA (Create-React-App)

• It is outdated (with more issues popping up every day)
• It ignores the advice of picking a framework instead of just React
• The authors themselves have said they don't intend on adding new features or maintaining it much further
• Vite is the current recommended alternative
  • Read this guide on migrating your app from CRA to Vite

Build Tools

Webpack was the undisputed winner here for a long time. You probably won't get in too much trouble if you use it now (other than sitting around waiting for development builds to finish). TLDR: It works, but it's slow.

But, now Webpack faces competition:

• Vite - a great modern alternative to Webpack that leverages browsers' native ES modules support for better performance (less code sent to the browser until required). An excellent option for building web apps and websites
  • github.com/vitejs/awesome-vite
• parcel - another modern alternative build tool + development server, if you are developing a library/package this might fit your needs better than Vite
• esbuild - a very flexible zero-config solution for large projects with intricate needs. Will probably be able to do what you need, but at the cost of a pretty steep learning curve

Snowpack used to be a great tool, but it is no longer maintained and recommends Vite as an alternative build tool solution. wmr can also be used as a build tool, though it generally has less open-source support and popularity than the options above.

Further reading:

• Comparing the New Generation of Build Tools

React Native

For building native (iOS, Android, Windows, MacOS) and web applications.

You can also use a framework like Expo to build, debug, and simulate an application that will run all the available platforms using the same codebase. There is much to write about React Native and its various restrictions outside the quirks of using Expo - visit the React Native Framework Framework Tips to see what we can recommend.

Web Frameworks & The Shift Towards SSR

Before jumping into the frameworks below, it can help to understand why this shift has happened:

1. SEO (Search Engine Optimization) - Many articles claim that client-side rendering hurts SEO performance. Google even recommends moving away from "dynamic content rendering" which tells a server to give a different response depending on the user-agent of the request (bots get different content than users do). While the official position is that client-side rendering is treated the same as server-side rendering, the results speak for themselves. Most companies do not possess the resources or knowledge to properly assess if client-side rendering is hurting their SEO. Therefore the best option for many companies is to take an approach that's tried and true and that does not present un-necessary risk for search engine bots. That option is server-side rendering. Simply put: bots can parse server-rendered content much easier than client-rendered content.
   • In tandem with this, functional meta tags like opengraph tags for social networks are much simpler to implement
2. Faster initial render/content paint - This is a particularly useful point to consider if you know your users might be using your application on slow internet connections. Faster load times will be easier to achieve in the near future with features like Remix's Nested Routes (Next.js equivalent is the App Router)
3. Meaningful HTTP error codes - Returning 400/500 codes isn't really possible with a client-side router
4. App will run better with JS disabled - Not sure how many people run their browsers with JS disabled by default - but perhaps this is your audience! If so, SSR is probably exactly what you need

About Next.js, Remix, Gatsby

All 3 frameworks lay the foundations for an application/website built with React. Some things to note:

• Each framework provides some tooling out-of-the-box for you when starting a new project, and this tooling is meant to make your life easier as a developer
• If you embrace what each framework offers, taking advantage of the vast react ecosystem will be much easier
• Each framework will be better suited for some use-cases, and ill suited for other use-cases

Before you dive in below, you may benefit by watching this video by Ryan Florence explaining the differences in approach from a server and cache perspective of the frameworks below. After you've watched it, you'll be heading into the next section with a strong understanding of SSG (static site generation) vs SSR (server-side rendering), as well as caching strategies that can decrease the load you put on your server while still serving your users dynamic content that will lead to a positive experience.

Comparison

React SPA vs. React Frameworks

CRA (Create React App) is a bad starting point for your next production application. Next.js and Remix are great options for web applications, or you could go with a SPA if it fits your requirements.

Gatsby is good for websites

Gatsby is not ideal for web applications that have lots of user interactions changing data or dynamically rendering data fetched from an external source (like a DB).

Some arguments favoring Gatsby might reference integrating GraphQL easily, or the plugin library - Next.js has since closed the GraphQL gap, and you'll probably easily find open-source alternatives for most Gatsby plugins.

Long story short: Gatsby can be great for content-driven public websites that need to load fast. For more reading, reference the following:

• Gatsby vs Next.js - Official Gatsby.js comparison

Next & Remix

Next.js and Remix can be used for websites that Gatsby are good for, but they really shine for slightly more complex web applications that interface with today's modern data systems. Remix is something a little newer, attempting to take advantage of many current browser standards that can naturally make web applications more accessible and quicker across many devices and network capabilities (Progressive Enhancement). That was a jargony way of saying: Remix really tries to make your app fast out of the box. It's definitely different from building SPAs, but just try to stick with it to see the benefits. When comparing Remix to Next.js:

• Both use the folder/file structure to setup the "routes" of your app
• Both take advantage of HTTP caching to deliver results to users as fast as possible
• Both provide built-in mechanisms for data fetching in your components
• When compared to Next.js - in most cases its probably more affordable to ship a Remix app via cloudflare workers than it is to ship a Next.js app on Vercel
• When compared to Next.js - The way it "blends" server and client-side code / components receives a lot of positive feedback
• Remix is built on top of standard Web APIs making it easy to deploy to the "edge", Next.js encourages a Node.js server (for now)
• Remix relies less on Node.js, meaning Remix is more portable to non-node environments like Cloudflare Workers or Deno Deploy and also makes it easier to run "on the edge"
• Remix apps will tend to "work" quicker - since their underlying fundamentals are based on web standards (like forms for mutating data). In other words: Remix makes it so your users don't have to wait for a large JS bundle (04.chunk.js) to finish loading before they can interact with the page

Further reading:

• Remix vs Next.js - Official Remix comparison

High-Performance Websites

Some new ideas are floating around to get really performant websites (blogs, portfolios, marketing sites, ecommerce, etc.).

If this fits your use case, you might benefit from looking into Astro or Qwik, which are easy to integrate from a React perspective.

• With the recent updates to Astro, this is actually becoming a very compelling alternative tech-stack for applications.

Monorepo / Nx

Managing multiple applications/projects under a single repository is much easier with tooling like Nx. Particularly, it makes it much simpler to have shared code between multiple client web/mobile applications with a monorepo setup.