DEV Community

loading...
Cover image for The shape of the CMS to come

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...
Collapse
thom4s profile image
Thomas

(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 :)

Collapse
matfrana profile image
Matteo Frana Author

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: youtube.com/watch?v=29m5DgNyUcA

Collapse
thom4s profile image
Thomas

Thanks, i'll take a look.

Collapse
driky profile image
Cédric Chatelain

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 ?

Collapse
matfrana profile image
Matteo Frana Author

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! 😊

Collapse
driky profile image
Cédric Chatelain • Edited

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.

Collapse
youssefrabeiii profile image
Youssef Rabei

So first of all Amazing Job 👏 i loved your project so much and your vision
In the past like 3 months or so I've been thinking of how I can build a "wix-like" builder but not only the text or color or the visual things i could edit i wanted to click a button and change the code (I was thinking JSX too 😂) or even i write my own New component and add them to "My library of components" and i thought that i would make it in Next.js
So after reading this post and spending the last 2 hours on your site, I really loved it
And I really want to join you on this journey (That will change how we make sites)

Collapse
tomhermans profile image
tom hermans

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

Collapse
matthijsewoud profile image
⚡️

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

Collapse
matfrana profile image
Matteo Frana Author

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.

Collapse
matthijsewoud profile image
⚡️

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.

Collapse
marianoviola profile image
Mariano Viola • Edited

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.

Collapse
canrau profile image
Can Rau

Interesting 👏😃
Reminds me of blocks-ui.com by @jxnblk 🤩
So many cool projects coming up 🥳

Collapse
dirtyf profile image
Frank Taillandier

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

Collapse
matfrana profile image
Matteo Frana Author

Yes, I think so ;)