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 100% the reason why this pendulum is swinging back in this direction. No one has an agenda, there's no conspiracy. Sometimes, SSR just seems to work really well for certain use cases.

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 diligently manage all dependencies and technical choices you'll likely need to make for the project to succeed (things like routing, data fetching, client vs server rendering, etc.). Note, this is more of a warning than it is a viable option for your project
• Either of the above is true and practically the entire application lives behind authentication

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

React Native

For building mobile (iOS and Android) applications.

You can also use a framework like Expo to build an application that will run natively on Android, iOS, AND modern web browsers using the same codebase. We plan on building this section out a little more in the future, providing learning resources and common tips for React Native projects. Have ideas? Help us out and pitch them in our git repository.

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 vs. Next (for websites)

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

If you're looking to build a website (potentially with some simple features hidden behind authentication), other than developer experience (dx) you're getting the same end-result picking between Next.js and Gatsby. With Next being the more flexible option (without sacrificing performance) there aren't many reasons to recommend Gatsby. Again, you should consider the DX of everyone that will be working on the project, but as far as functionality - Next.js gets you everything Gatsby does and more. Gatsby can support server-side generated responses at runtime, but in general, Next has better support for this feature. If your project has any potential to grow beyond the current spec/scope - we recommend Next.js. Traditionally, some arguments favoring Gatsby might have referenced integrating GraphQL easily, or the plugin library - Next.js has since closed the GraphQL gap, and it's likely you'd be able to find plugin alternatives given the vast React ecosystem.

Further reading

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

Next vs. Remix (for web apps)

Remix is something 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. That was a jargony way of saying: Remix really tries to make your app fast out of the box. It's a bit of an unorthodox way of building a UI for your application needs, but the decisions are intentional. 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, Next encourages a Node.js approach (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 static websites.

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

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
• 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