Photo by Hal Gatewood on Unsplash
Are you a react developer? Then this day and age must be very exciting. Gatsby, nextjs, netlify, the JAM stack, you name it. You can setup a complex web project in no time.
Modern tools are amazing. But, what I want to talk about in this article, modern CMS are not. Working with today's CMS solutions frustrates me. The time spent integrating with a CMS and managing content and its structure doesn't feel right.
I thought a lot about my experiences and dreamt up a new approach to solve my frustrations. A better CMS for React projects. Let me explain further.
A better developer experience
There are many small points of frustration. The big one for me is content-structure. Most CMS define their content-structure with some sort of types. Every CMS has those: Wordpress has post types, CraftCMS has sections and Contentful has content types. They all refer to the same: A table in a database. This works great for structured data like blog posts or ecommerce products.
It does not work well for websites that have a lot of unique elements. Plenty of times your website consists of things that only exist once. For example: an about page with a hero component, a background image and a CTA button. It is hard to normalise websites into database tables.
The solution:
Derive content-structure from code. Guess what knows most about your website's structure? The code behind it!
This also solves a lot of related pain-points I have encountered:
- No need to manually define your content-structure through a web-UI
- It is far easier to test different content values
- You are probably versioning your code already with Git. So your content structure is versioned as well.
- No need to migrate your content structure to other environments, just deploy your code
A better editor experience
CMS UIs give editors a hard time. We developers sometimes look down on editors, because they have a hard time understanding how the CMS works. But think about that for a second: There are dozens of input fields hidden in a nested tree structure. Editors have to match those with the website in their heads. Without knowing about the code or the content-structure.
Headless CMS's have become popular because they let developers choose what technology they want. As a result the website moved further away from the CMS. Editors are the ones that lose out.
The Solution:
Merge CMS-UI and website. Editors should have the feeling they edit the website. Every change is immediately reflected on the website. We build websites with React, a powerful frontend library. Why not use it to power the CMS too?
What's next?
All I have right now is a prototype that uses local storage (as seen in the videos above). The next step would be to publish an NPM module and to develop a simple data syncing service, so we can try this in a real world scenario.
Are you fed up with the CMS landscape? What do you think about the approach described above? I very much appreciate every opinion and every reply. Thanks for reading.
Top comments (3)
I appreciate where you are coming from in this article - I believe there is a delicate balance between the CMS data and its structure and the code that consumes it. Headless CMS is a direct reaction to the nasty code-bloat that tends to come from Traditional CMS.
I believe a good CMS should be flexible enough to work with any language or framework, and it should be tailored to make life easier for both the editors and the developers who use it.
You should definitely check out TinaCMS then!
Right now Tina has adapters for React, but it's designed for more. We're planning on introducing Vue adapters, with community interest in adapters for Svelte and Web Components.
Disclosure: I'm one of the the Tina maintaners :)
Thanks! Actually, I work at Agility CMS - which works with all tech stacks.
Happy to see that you are doing well with Tina - all the best!