Introduction
Low-code vs No-code: many articles explain the differences, benefits and drawbacks of the two approaches. In this article I'd like to narrow down the topic to that of content management systems (CMS). I will broaden the use of the term "CMS" to include visual site builders, which are starting to blend in with more traditional tools.
I will focus on how different types of CMS lead to code, no-code or low-code approaches in the front-end development of a website.
We'll start with monolithic CMSs, travel through developer-centric solutions like headless CMSs, look at no-code tools and eventually get a glimpse of the future in a recent new approach.
Monolithic CMSs πΏ
A monolithic CMS such as Drupal or WordPress usually leads to a "low code" experience on the front-end, but, depending on how it is used, it can also be a completely "no-code" or full "code" experience.
I will now use "WordPress" as a synonym for monolithic CMS, as it is easier to say. Keep in mind that WordPress is a great product and nowadays it can be used also as a headless CMS exposing REST or GraphQL APIs.
For very simple projects, where you can just set up a website with a pre-made template and you are good to go, WordPress is a no-code tool.
As soon as you want to change something, WordPress can become a low-code tool, because you can just change some HTML code in the PHP templates and change the CSS files.
If you create templates from scratch, it is a full "code" solution, because you have to write all of your template files in PHP, using the WordPress framework (the "loop"!).
Monolithic CMSs are flexible, as you can choose how much code to write, based on your needs and your skills.
Usually a developer would like to write code to limit what the content creators could do, to avoid having customers breaking the website, for example placing a table that breaks the responsive layout or creating red text over a green background (the designer says thank you).
To do so developers create fixed fields that can be used on a page (for example using Advanced Custom Fields), so that content creators end up filling gray forms instead of writing content in a free way.
Don't get me wrong, content creators don't want to have total freedom and to break the design. They just need to get the job done. And the best way to get the job done is to write content as you do in Pages or Word, which unfortunately is not appropriate for designers, unless you can guarantee that the corporate image remains safe.
And the fact is that many front-end developers would laugh today reading what I said about developers that want to write code in WordPress. Modern front-end developers don't want to see PHP code at all: they want to leverage a modern stack solution, using a JavaScript framework like React, Vue or Angular.
Monolithic CMSs are still by far the most used kind of CMSs and offer a certain amount of flexibility, but, as we saw, they tend to be always a suboptimal solution for at least one of the involved actors (developers, content creators, designers), based on how they are used.
Luckily today there are tools that are more suitable for web agencies working with modern front-end stacks: read on!
Headless CMSs π€―
With headless CMSs you have the separation of concerns between the back-end (database, APIs, image processing) and the front-end (the website consuming the APIs and rendering the content).
The backend is usually of no concern because it is provided as a service, so the front-end developers can focus on creating the website using a modern stack, for example using a React framework like Gatsby or Next.js.
Headless CMSs require coding: a developer needs to write the code for the front-end website in order to fetch content from the APIs and present it, usually using a JavaScript framework.
Headless CMSs are great for developers, because they have total freedom in choosing the framework they prefer without the hassle of creating the APIs and the Admin interface for content editing. And they offer better performance, scalability and security out of the box.
The problem with headless CMSs is that a core actor in the adoption of the CMS, the Content creator, is not happy with this solution. Why? Because the content creator loses the visual editing experience that he could have with a blank WordPress page (the infamous blank page that horrifies designers and frightens developers).
Visual site builders ποΈ
Visual site builders like Wix or Webflow exhibit a simple point and click interface in order to deliver a user experience that is very similar to that of a word processing software like Word or Pages.
Visual site builders are no-code tools and they are great for Content creators with no particular corporate image needs or no developers available.
In particular, tools like Wix address pure Content creators who don't need to change the graphics and are ok with the provided templates, while more advanced tools like Webflow allow the user to change every aspect of the page content. In one case you cannot express your exact corporate image, in the other one the content creator has too much power, like in the blank WordPress page case.
Either way, content creators may be happy, while designers are not. And developers? They are not really involved in this case (so they are skeptical, I tell you by experience π).
The missing pieces π‘
Developers usually prefer a "code" solution like a headless CMS while content creators usually prefer a "no-code" solution like Wix. But... the funny thing is the reason for the like/dislike is not the quantity of code, but something else.
Developers prefer a headless CMS over a monolithic CMS not because they can write more code, but because they can write code in a better way, using better tools, with a better architecture.
Content creators prefer a visual site builder not because they don't have to code: at a corporate level they have developers that can code on their behalf. They prefer a visual site builder because they can have a visual editing experience.
And designers? Well, they need to be able to express the exact corporate image (so no Wix, sorry) and be sure that nobody will break the corporate image (so no "unleashed" WordPress or WebFlow, sorry, sorry).
We need something new. Will it be a no-code tool? A full code solution? Read on!
A new approach β¨
From what we saw, it seems that full code means the ability to reproduce the exact design system and create constraints so that the editors cannot break the design, using a modern development stack.
Is this in contrast with visual editing, the great UX that content creators are looking for?
Well, in a way yes, because for a single developer or a small team, it is impossible to re-create a complex system like Wix for a corporate website.
So what we really need is a development framework that allows developers to create something great like Wix, but with our own corporate design system and constraints, in order to be sure that nobody will be able to (accidentally!) break it.
And this framework should be great for modern front-end developers, keeping the advantages of headless CMSs. It should be a front-end library created with a JavaScript framework like React, Vue or Angular, with a decoupled API as a service.
And what about the "design system" thing? What is it? Let's simplify: it is a set of content blocks with a designer-designed design that can be used in your content. Ok, so we need a way to create content blocks with React (or Vue, or Angular) with visual editing that save content on headless APIs as a service.
Is it code? No-code? Low-code? Well, at the moment it could be a solution where you have to write code using this library, but the library takes care of many things for you, like calling APIs, wiring the visual editing to your content blocks, rendering on any framework like Next.js or Gatsby, etc. So we can say such a solution is a low-code one. You just write the components, the library does the magic. And clearly the experience for the content creators is completely no-code, a no-code tailor-made for them: no useless power, but comfortable constraints.
Is it the future or... now? πΈ
Well, it is just now. I know two CMSs that follow this philosophy, Tina and React Bricks, both working with React. Tina works with Next.js, React Bricks works with Next.js and Gatsby. They have a similar idea behind them, but different approaches.
Tina has an experimental feature for visual editing ("inline editing") while React Bricks has been created from day one around the core concept of visual editing. React Bricks is born to be a one stop shop where content is persisted on APIs as a service and image processing is done by the same APIs, while Tina started as a Git-based CMS and it leverages an external service (Cloudinary) for image processing.
And... I created React Bricks, with the help of my team.
Ok ok, so I am biased. I am biased because I believe so strongly in what I say here that I founded a start-up based on this concept. I turned a profitable software house working for customers into a product-centric bootstrapped startup.
I believe this is the way we can create great user experiences for everybody: content creators, developers and designers. I believe this is the way people will edit websites very soon. And they will have fun. Again.
BTW, if you want to have a look at React Bricks... π
Top comments (0)