Skip to content

The shape of the CMS to come

Matteo Frana on January 22, 2020

In this article I express my vision about the future of Content Management Systems. I think that CMSs haven't yet taken advantage of the convergenc... [Read Full]
markdown guide

I might miss something but I don't get why people always see the content editor as part of the "headless" back-end and not as a part of the front-end ?

What prevent us from integrating our own editor in the front-end, protected by the usual permission system ? If an headless back-end can deliver content it also can ingest it.

Of course you can still deliver a basic content edition experience on the back-end to kickstart everything but separating the edition from the display seems counter intuitive and not supported by any technical limitation.

Am'I oblivious to something or is it just a general bias ?


This is great and it is indeed the direction we are taking with ReactBricks: the Admin is inside the Next.js or Gatsby project. This way we also solve the problem of "sharing bricks components between admin and frontend": they are the same project! 😊


always nice to learn I'm not completely out of my mind :-) I'll follow your project hoping to see it kickstart a new "path" for the modern content stack.


(Unless i misanderstand the post,) Being stuck with React is not a solution, i think. The FrontEnd must be agnostique and at the choice of the developper.
JSX is a pain to read. I prefer by far the SvelteJS solution and keep my good old HTML+CSS+JS.
(great post though ! Made me think :)


Hi. I agree that it is not a solution for everyone. But it is a great solution for React developers. I see that JSX is indeed a great way to build a design system by developers who code. If you are interested, this talk by Isha Kasliwai is just about this:


This is exactly how I see it. And what I'm trying to achieve as well, trying several technical options. An opinionated design system that's usable with compostable blocks and adjustable props. Indeed, not simple. Keeping an eye on your work. Kudos


A CMS is primarily concerned with content modeling, workflow and collaboration. CMS are very complex systems and in this context, the content editor is only a small part of the whole. In any case I agree, I definitely prefer "blocks" editors, they are now a pretty consolidated solution.

As for the headless architecture, I would like of being able to choose what type of format to have in response to a query. In some cases I would like a representation of the content in JSON, in others an RSS feed, in other cases it might be useful for me to have a rendered and optimized version of the content in HTML or AMP that can be cached until the content changes.

In any case I will keep the public front-end agnostic preferring a very simple and SEO friendly approach. I like the idea of ​​using Custom Elements, Fetch and History API for interactive elements and to make the pages navigation experience more pleasant. If I were to use a design system or a library to build reusable components, perhaps I would use them to develop the most complex part, the CMS application.


This feels very much like what Gutenberg for WordPress is doing. It’s a hard problem to solve, but strides are being made.


Yes. I feel much more productive with React components as blocks than creating custom blocks with Gutenberg. It is also much simpler to render them with a React-based frontend like Next or Gatsby.


To me it’s not a choice of one versus the other. I have a couple of projects that have custom React components. I render those components on the front-end, and also import and use the components within the Gutenberg block. That way they share code, and stay dynamic.

I can even put children blocks within the custom component, and it will render. Especially handy for things like InpectorControls.


Interesting 👏😃
Reminds me of by @jxnblk 🤩
So many cool projects coming up 🥳


Looks like you share a common vision about the future of content management with 😉

code of conduct - report abuse