In recent years we have seen a number of new React meta-frameworks emerge. Next.js, Gatsby, Remix, Redwood, Blitz... the list goes on, and it is starting to get overwhelming. It also raises the question of why there are so many meta-frameworks in the first place?

But before we answer that, let's define "meta-framework"

A framework built on top of another framework

All these meta-frameworks are built around React. They extend it by adding additional features. Instead of spending time doing boilerplate stuff, we can use out-of-the-box solutions provided by the framework. Hence, more time to focus on building a great user experience.

Calling React "a framework" is somewhat controversial, some argue it is just a library. I personally think of React as a framework, but I'll save my argument for another article...

The special case of React

Unlike other front-end frameworks, React is unopinionated in many aspects. It has no standards on how you organize code, routing, styles, tests, etc... It only provides a view layer and you have to fill in the missing parts yourself.

This flexibility of React, useful at times, can also be confusing. There is no right or wrong way of doing things. Most of the time, you will find yourself needing more than React to build a full-blown web application. You will end up adding third-party libraries, which is a hassle as there are so many of them. And as your application scales, it will be much harder to maintain, opening room for bugs and errors.

To overcome these limitations, many meta-frameworks have emerged. They provide standards for organizing code, handling routes, forms, and much more. They make the development process consistent and enjoyable. They also enable cool features like server-side rendering(SSR), static site generation(SSG), and automatic code-splitting. Everything you need for a production-ready app!

But why so many?

I speculate the growth in popularity of React and the dramatic change in the JavaScript ecosystem might have contributed to this. Creating scalable and robust web applications, while maintaining a good developer experience has been the motivation behind most of the frameworks.

The way we develop and ship web applications has definitely changed in the past few years and each framework has a unique way of solving the current challenges in web development.

So what are my options?

Well, here are the most widely used ones:

Next.js

Next.js provides many data fetching options, including server-side rendering, static-site generation, and an interesting one called Incremental Static Regeneration(ISR), which allows you to add static pages incrementally after build time.

If your site needs to support multiple languages, Next.js has a built-in Internationalization feature. Deploying a Next.js site on Vercel is also a breeze. But if you plan to self-host or use other cloud services, you might need to do a bit more tweaking.

Gatsby

Gatsby started out as a static site generator, but now it can also be used to serve dynamic content using server-side and client-side rendering. It has a great variety of source plugins for fetching content. If you are building a site that will integrate with a headless CMS, Gatsby might be a good option.

Gatsby uses GraphQL as the default data layer. You can use it without GraphQL, but you will miss out on some features.

Blitz

If you are coming from a Laravel or Ruby on Rails background, you will enjoy working with Blitz. It is a full-stack framework built on top of Next.js and has a "Zero-API" approach, you just import server code to the client.

It also provides built-in authentication and session management and other handy setups. But if you need an advanced backend, it might not make the cut for you.

They have also announced recently about pivoting to framework-agnostic toolkit

Remix

Remix is all about the fundamentals of the web. It is built on top of web standards and emphasizes how HTTP and HTML work. The API is simple and easy to follow.

A cool feature of Remix which sets it apart from the others would be the focus on progressive enhancement. HTML <form> in Remix is a built-in solution for data mutation and will work even when JavaScript is not enabled! So a Remix app can support even the oldest browsers. Using nested routes, you can keep UI in sync with server-side data without a complex state-management setup.

Even though Remix does not support static site generation, it can achieve comparative performance through an edge-native architecture.

Redwood

Redwood helps you build a web app fast! It provides a pre-configured development workflow with a handy command-line tool for generating project assets. A Redwood project is a monorepo with a React frontend and a custom GraphQL API.

It has a neat integration with Storybook and helpers for managing forms. Also, boilerplate tests and mocks are automatically generated. It really simplifies the development process but it is highly opinionated, which could limit its use case.

Closing thoughts...

Don't choose the framework, let your project choose it for you!

Even though diversity is a good thing, there is no doubt it puts developers in a difficult position. So a rule of thumb would be to let the requirements of the project guide the decision. If you have clear requirements, then choosing a framework will be less frustrating.

Hope you enjoyed this article, thank you for reading!