Today we released in beta a hybrid CMS that embodies the vision of my post “The shape of the CMS to come”, published on January 22, 2020.
In this post I highlight the reason why this new kind of CMS is better than traditional and headless CMSs and I explain the technical choices that we made.
This is of course a biased vision, but I wouldn’t have invested in the development of this product if I hadn’t firmly believed that this is the way we’ll edit websites content in the future, starting today 😊.
A block is a good atomic unit to create a website. It’s easy for the content editor to reason about a “hero unit” or a carousel; on the other side, such a block is a self-contained part of design system. Less than a block and you have single texts and images, more than it and you have an entire page.
Even Wordpress, with the Gutenberg editor, is going in this direction.
So, a block-based CMS is great for both Content editors and Designers.
React Components return JSX and have a very clear “props” interface. JSX is a good candidate as a common language between developers and designers and constraints on props can enforce a design system.
So, React components are great for Designers and and Developers.
With a hybrid CMS you have the separation of concerns for technologies between front-end and back-end (as in a headless CMS) which is great for developers: the website can be a React-based static site made with Gatsby or Next.js, while the API are a hosted service the front-end developers don’t need to care about.
On the other hand, a hybrid CMS doesn’t decouple the visual aspect of the website from the Admin Dashboard, so that it's possible to have WYSIWYG editing. What you see in the Admin Dashboard is exactly what you will see online.
So, a hybrid CMS is great for Developers and Content editors.
Our CMS React Bricks is three things at once:
A React library to create a great content editor and define block types and rules, with its companion Viewer component for the front-end
A set of starter projects (which use the library) to kick-start your website with Gatsby or Next.js maintained up-to-date directly by the React Bricks team
A Software as a service API for data persistence, image optimization and serving over CDN
A React Bricks starter is a static website which contains a
/admin directory with the Admin Dashboard, which you can customize with your logo (and soon with your colors).
In this way, it combines the advantages of a static site for the front-end (speed, deploy to CDN, security) and the features of a dynamic React application for the Admin dashboard.
React Framework agnostic (Gatbsy, Next.js): this means you can switch from Gatsby to Next.js or viceversa in literally 2 minutes (download new starter, copy the
/reactbricks folder with the schema) and you are up and running!
Styling agnostic (use the CSS library you want)
Hosting agnostic: host the static front-end wherever you want. You may often stay inside Netlify or Zeit Now free tier.
This one is a tongue-twister: if you can repeat "hosting agnostic" three times in a row, you deserve access to the beta :)
We are replacing our stack (Wordpress REST API + Gatsby) with React Bricks Beta for some customers' websites and we won't come back.
Surely there are things to improve: we have many ideas for the future and I'm sure beta users will give us many new ideas.
This is the way I like to build CMS-based websites for our customers.
I'm not sure this project will reach large adoption, but I'm sure in the future you will edit websites in this way, with React Bricks or another system similar to it.
Here you can find the beta website, with a demo, all the docs and the form to request invite to the beta: https://www.reactbricks.com
Please, let me know what you think about it. Your opinion is really invaluable to me.
Thank you for your time 😊