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...
For further actions, you may consider blocking this person and/or reporting abuse
Was curious on your thoughts about WebFlow? Do you like their approach for UX, DX, and the content editors' experience?
I think WebFlow is too complex for content editors and... too flexible.
The interface is complex and, when editors learn how padding, margin etc. work, they can use them to change the design, which is something they shouldn't be able to do.
So I think WebFlow is a good aid for web developers, not a tool for content editors.
With React Bricks we give complete flexibility to developers (React code) but good constraints to content editors: you can decide in code what content editors can change, both via direct visual editing and via sidebar controls.
What do you think about it?
great point. I also think it is good (imperative) to keep design-editor and content-editor separate.
(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: youtube.com/watch?v=29m5DgNyUcA
Thanks, i'll take a look.
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.
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)
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
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.
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.
Interesting 👏😃
Reminds me of blocks-ui.com by @jxnblk 🤩
So many cool projects coming up 🥳
Looks like you share a common vision about the future of content management with tinacms.org 😉
Yes, I think so ;)