The best CMS for Next.js

Why React Bricks?

React Bricks is the first CMS built in React, for React and Next.js with true visual editing. You can provide to your content editors a great editing experience like that of Wix or Elementor, but with a great developer experience, too.

Working with React Bricks in Next.js is like playing Lego bricks, as you create content blocks as React components, super-powered by React Bricks' visual editing components.

Your content creators or customers will use these bricks to compose the content, with all the freedom they need, but with no way to break the design system.

Getting started with Nextjs

Creating a Next.js website or blog with React Bricks is a matter of minutes: you just need a free account and you can launch npx create-reactbricks-app@latest

From the React Bricks CLI you can choose one of the 3 Next.js starters:

• Website with Tailwind CSS
• Blog with Tailwind CSS
• Empty project for any CSS framework

What is Next.js?

Next.js is a framework to develop React apps and websites with great performance and SEO optimization.

Next.js in fact has the ability to use SSR (Server-Side Rendering), SSG (Static Site Generation) or ISR (Incremental Static Regeneration, which is unique to Next.js).

SSR, SSG... what does it mean?

Here we explain quickly what all these acronyms mean and what I suggest for the common use cases. If you want to learn the tradeoffs in depth, you may also read Matteo's article Server Side Rendering vs Static Site Generation vs Incremental Static Regeneration.

Server-side rendering

With Server-side rendering (or SSR), the React rendering process is run on the server and a HTML page with content is produced, so that the search engines' web crawlers can see the content of the page without having to execute JavaScript. Once the page is loaded, the client application starts, matching its status with the server-generated DOM.

SSR is great when you need SEO and you want to be sure that the user has always the latest version of a page, even if it means a higher load on the server (because Node.js needs to render the pages server side, instead of just returning a static page).

Static site generation

Static site generation may sound like a thing from 1998: the server returns a static HTML version of your website, generated at build time.

Actually there's much more, because the build process optimizes images, creates optimized junks of JavaScript code that are lazy-loaded and, as soon as the client app starts, it has the power of a single page app, with link preloading etc.

Static site generation is great anytime you don't have a very big number of pages (because that could make the build time too long) and your content doesn't change very frequently (because otherwise you would need to rebuild very frequently).

Incremental Static Regeneration

Incremental Static Regeneration is a way to have the advantages of both SSR and SSG avoiding the pitfalls of both.

With ISR, every time a page is visited, it is rendered server-side (SSR), but then it is cached as a static page, so that the next visit will receive it much more quickly and with no server load. You can specify a stale time so that, after the stale time, to the next user is returned the static page, but meanwhile the page is renewed via SSR.

In this way you can have many pages, because you don't have the long static generation at build time, but, most of the times (for the most visited pages), the page is served very quickly as a static page.

Benefits of React Bricks over a headless CMS

1. Direct Visual editing

A direct visual editing experience like Elementor, but on a fast React frontend. Your content creators are productive as if they were using Word or Pages and they have no way to break the design system.

All the freedom Content creators want; no more than they need.

2. No context switching - It's just React!

With React Bricks you don't have to access a headless CMS to create fields and then come back to code to get the data and use it. You define your fields as props of your React components.

The props that are visually editable are managed by React Bricks visual components; the other props are mapped to sidebar controls. Easy and powerful.

3. No framework lock-in

Your site is framework-independent: you could switch from Gatsby to Next.js or viceversa in a matter of minutes, just setting up a new starter connected to the same React Bricks app.

No need to change from a GraphQL connector to direct REST API calls, no change of "Image" component (in your bricks you don't use the Gatsby or Next "Image" component, but the one from React Bricks, which is cross-platform).

4. No need to train your users

A headless CMS can be a complex beast for Content creators. They are not DB admins. With React Bricks they feel at home from the first minute. They are happy and don't need to ask you, so you save time.

Why React Bricks is the best CMS for Next.js?

React Bricks is great for developers, because you define the content blocks using React components. Each content block React component has also a "schema" static property that defines how props like the background color are edited via sidebar controls, validation rules etc.

In the JSX you can use the React Bricks library visual editing components, like Text, RichText, Image, Repeater, to have a visual editing experience like the one you can have with Wix, but with your own design system (so that you make your customers or marketing team happy, too).