Choose Boring Technology for Content

Every content management build reaches the same fork. Someone asks for a proper editor, meaning bold, italics, headings, images, tables and a drag handle. It is a reasonable request and it is usually the single most expensive decision in the project.

The cost is not the install

Rich text editors are large, deeply interdependent packages. They tend to ship as a core plus twenty extensions that must all agree on the version of the core. When one moves, the others do not, and the failure often shows up not as a broken editor but as a build that will not complete.

On one project this pattern cost five weeks of intermittently failing deploys and eventually needed every version pinned exactly plus an override block to stop the package manager resolving anything else. That is a lot of engineering for a feature used to write about one article a month.

What we use instead

For sites publishing a handful of articles a year, we use a plain text area with two or three conventions. A blank line starts a new paragraph. Two hashes make a heading. A leading dash makes a list item. The content is stored as structured blocks rather than a blob of markup, which means it can be rendered differently in different places and queried sensibly later.

• No dependency that can drift and break a deploy
• Content stored as data, not as markup that has to be trusted and sanitised
• The stored form and the editing form can be tested against each other directly
• A non-technical person learns it in about a minute

When to spend the money

This is not an argument against rich editors. If a team publishes daily, needs inline images and embeds, and has several authors who will never learn a convention, buy the complexity and maintain it properly. The mistake is installing it by default, for a site that publishes monthly, because it felt like the professional choice.

Every dependency is a small ongoing subscription paid in maintenance. Some are worth it. Most are bought without asking the price.