A Component-Based CMS and why Rich-Text editors are bad

This post will briefly examine how traditional systems approach content creation, what challenges this brings, and how a component-based CMS is different. And why it is better.

Traditional CMS

How content is approached on the modern web has changed quite a bit. Traditional content management systems use themes to decide your website's specific look. When adding new content, you use a rich text editor to write. The content of the rich text editor is then transformed into the theme-specific HTML and displayed on your website. Especially the usage of the rich text editor comes with several problems.

The problem with rich text editors

A fundamental challenge here is transforming the text entered into a rich text editor into the HTML output. Since a CMS wants to provide a lot of flexibility with a rich text editor, it lets you create many things. Like headlines, paragraphs, lists, links, tables, images, etc. This is a not-so-simple technical problem; more often than not, the generated HTML is terrible or even buggy.

Even if a rich text editor offers a lot of possibilities, in the end, it still is limited. For example, you cannot add forms with it. Or more complex constructs like a newsletter subscription form. And even if it would allow it, complexity would increase, leading to more bugs, lousy HTML, and worth maintainability.

To extend the functionality, even more, there are two main approaches.

The even bigger problem: adding HTML and CSS directly

To further expand the capabilities of a rich text editor, a CMS lets you switch to HTML mode.

And then hell breaks loose.

In HTML mode, an editor lets you do the coding yourself.

Doing something wrong is very easy this way. Also, it makes the person creating a new site need technical knowledge. HTML and CSS are programming languages, after all.

Another problem is that once so much flexibility is provided, it's easy to fall into the trap of using workarounds just to get a specific outcome. For example, you use some inline styles, available CSS classes, or random code snippets just to get that specific looks you saw on another website.

Doing so makes a website unmaintainable at some point because you can no longer know what is used and where it is used as a developer. Changing code leads to so-called regression issues - meaning you change or fix something here and break something somewhere else.

From a designer's view, it is a nightmare as well. Allowing so much flexibility will lead to inconsistent UI almost always. It is super simple to use colors, not in brand or applying margins that are just some random numbers, but not at all agreed on with the designers.

Using text placeholders

The second typical way of extending the capabilities of a traditional CMS for content creators is using some custom text placeholders. For example, if you want to add a newsletter subscription box, you would enter something like

[[NEWSLETTER_SUBSCRITION_BOX]]

Just from a pure developers way of thinking: This is just a hack Having a simple typo by mistake is very common, and nothing works as expected.

Also, how do you know all the text placeholders? Every plugin that adds those might have different syntax, making it even more complicated for content creators.

And then what if you want to change some specific properties of the newsletter subscription box in the current context you are using it? You would need to add more arbitrary text placeholders.

It is also unclear whether or not the newsletter box can be configured and, if so, how.

Overall rich text editors in traditional CMS are prone to errors, hard to maintain, and not easy to use, especially for more complex functionalities.

In the end, everyone is frustrated:

• the content creator fiddling around with a programming language
• the developer hunting bugs he is not responsible for
• the designer because everything is off everywhere

Luckily a component-based CMS solves all of those issues, as we will see in the next part.

Component-based CMS

A component-based CMS eliminates the need for bloated rich text editors, entering HTML directly or fiddling with CMS as an editor yourself. It, therefore, makes it easier to enter content without technical knowledge, increases maintainability, lets you extend its functionality quicker, and is less prone to hard-to-find bugs. In the next part, we will discuss what components are and how our component-based CMS works.

What is a component?

For frontend developers talking about components has become very natural over the last couple of years. Building an entire website out of a set of building blocks is the norm.

A component can be very small, like just a line of text, or more complex, like a newsletter subscription form with text input, a button, some description text, and a link to privacy terms.

Since one primary goal for a component is to be reusable, they are configurable. So I can have a red, blue or black button. They all use the same component, but the color is configurable.

This makes working with components very flexible and keeps them maintainable but also extendable. If you need new functionality, you create a new component by reusing what exists and extending it if necessary.

You still have a rich text editor Does that mean you do not use a rich text editor anymore?

No, it does not. But what you can do with a rich text editor is very limited. Or you even use a markdown editor, which is easier to maintain and less error-prone.

You can still write text with bold styles, add links, a list, and a few more things. But that's about it. Everything a bit more complex will be a component.

By the way - the rich text editor is also a component with a configurable text property.

No more HTML or arbitrary text phrases

You will not write custom HTML or use specific text phrases when working with a component-based CMS. You always use a component from the existing set. You create a new, configurable component if you need even more functionality.

If an editor adds a component to the CMS, he can directly see all its configurable options. There is not much you need to remember this way or do wrong.

A developer has much more control over what can be used and how. If there is an issue, it is immediately apparent where to look and how to recreate it. This leads to bugs being solved much quicker, too.

Designers can also be sure that components look as intended. And if an element should be adjusted, it is guaranteed that this happens everywhere it is used. This makes it possible to evolve the looks of a website with confidence.

Applying some styling

Sometimes you still want to have a choice on some aspects of the looks as an editor. And a designer can give that options in a controlled way that ensures everything is visually aligned throughout the whole website.

For example, you will not set the color codes directly like

style="background-color: #FF0000"

Instead, you have a configurable field "backgroundColor" and a dropdown of available values, like "red" "blue", or something more in the scope of your CI as "primary", "secondary", "warning"…

Decreasing the flexibility from "you can do whatever you want" to a defined set of options helps keep the website more concise.

Also, it allows developers and designers to define what is possible and what is not. You can also be sure that working around it without a discussion in a broader round cannot happen. This leads to a more maintainable, well-aligned, and fast-to-extend content site in the long run.

Video: Using a component CMS in practice

After discussing why a component-based CMS is so great, let's have a look at how we added the next newsletter-subscription section at the end of this article with our component-based CMS:

Conclusion

Working with components is the de facto standard in frontend development and applying these principles to a CMS gives a lot of benefits. It creates a proper separation between design, development, and content creation. Using workarounds by editing plain HTML or CSS makes it impossible to maintain a content website over time and is not possible using a component-based approach. It is also much easier for content creators since they do not need more in-depth technical knowledge. And the risk of mistakes decreases a lot as well.