A love letter to a JS component-ready content management system
It doesn’t matter which JavaScript framework you prefer because there’s one thing they all have in common—they’re all component based. Bigger applications are combinations of hundreds, if not thousands, of JavaScript components.
But even though this is great from a technical perspective, I always struggle to make this principle clear to non-technical people. To explain the component movement to the people that fill the applications that I build with data and content was always very hard–until last year when I found out about Contentful.
So let me tell you how I feel about Content Management Systems that “just work” in modern Frontend applications.
My dearest component-driven CMS,
I have something important to tell you. And what I’m about to say might surprise you. But before I tell you—do you remember how we met?
A long time ago I was working as a software developer for a startup here in Berlin building your typical single page application (SPA). We wrote our CSS in Sass and had a generated “living style guide” integrated with the project. Life was good and we were drinking the Kool-Aid of the component movement like there was no tomorrow. Everything from pages to form elements to transitions became a component. Business logic continued to live on the server side, so a lot of components were doing XHR requests. But in general, everything was working out just fine.
By contrast, content edited by non-technical people was managed via configuration files written in YAML or JSON. This setup came with its own set of, shall we say, challenges. We had to teach editors how to edit JSON files, how to make commits to GitHub, and deal with a never ending stream of requests asking for help with file formatting issues. But we rolled with the punches. Because that is how startups work—F*** it! Ship it!
We learned that technical data structures, or excel sheets, had not been invented for content management.
Not surprisingly—this did not turn out well. This setup caused recurring issues, including production downtime caused by syntax errors. We learned that technical data structures, or excel sheets, had not been invented for content management. They should instead be used to model data, do calculations and track items—but not to act as a writing interface for authors.
But why did we end up with content-filled config files in the first place? The reason for using these files was the unwillingness to deal with the infrastructure side of things—and a desire to not increase complexity for things that were not directly tied to the business side of things.
DevOps is a really interesting field—but it’s not for me
A failing installation on the command line can literally ruin my day, sending me to scan Stack Overflow for a clue to the solution. I just don’t like it. And there are thousands of people out there that are way better at it than I am.
And you know me! I am the kind of person who fiddles around on CodePen after work to relax. I prefer to build beautiful UIs, not set up databases, build custom editor interfaces, or force myself into loving a classical CMS.
What I want is a tool that I can quickly configure.
What I want is a tool that I can quickly configure. A tool that offers a convenient interface to editors and then simply returns a few kilobytes of JSON data whenever I ask for it.
Extending an existing application with curated content
But why am I telling you this? I’m telling you this because the first time we met I was in a lot of pain.
We needed an interface! And this moment my dear CMS was when you and I met for the first time!
The pain came upon me when I had to extend our application to include a section for events that the company was doing. Things got complicated. One event could include a title, a description, and a date – we looked at the requirements from a technical perspective and decided that it’s now time for something more advanced than JSON files. We didn’t want to model these options in a text file and we clearly didn’t want to explain all these options to anyone non-technical. We needed an interface! And this moment my dear CMS was when you and I met for the first time!
The data managed by editors was right at my fingertips – just one API call away.
You showed me the concept of content types which lets me define the data structure I needed to feed my components. I could set these up in a minute and I didn’t have to worry about pages, infrastructure or SQL schemas. The data managed by editors was right at my fingertips–just one API call away.
Because of you I was able to give editors what they wanted – an interface that they can use without caring about quotes and semicolons.
And you also gave me something I had always wanted–clearly structured data and a way to not worry about changes made by non-technical people.
And with these first components being connected to your API, I discovered that I already had a crush on you. I didn’t have to deal with anything, you simply took care of me. I felt safe!
Building bridges between your components and your content model
But this crush was only the beginning though. I got the feeling that we should take our relationship to the next level. The fact that we could define and adjust data structures like we wanted them amazed me and the editors. We simply gained a lot of speed.
But there was more!
The application grew. We added more components that were controlled and edited by non-technical people. At some point, people asked for a flexible way to build full landing pages. And now people were asking for more—more flexibility and more ways to present their ideas to the world.
To help our editorial team work faster we decided to construct a website builder. The idea was that the builder should make it possible to include an optional hero image, one or more items in the main content area, and one or more items in an optional sidebar. It should also be possible to reuse old entries.
I did not have to reinvent the wheel!
And wow! This was the moment when I fell completely head over heels. I discovered that I now had a small set of already defined building blocks. And all I had to do was to put them together. The code and the content components were now connected and reusable. I no longer had to rewrite stuff over and over. In other words: I did not have to reinvent the wheel!
So we defined a top level “page” component that held all the content entries. And thanks to your linking feature I was able to fetch everything I needed within a single API call. Complete pages defined in an easy to use JSON structure were right in front of me. I defined JavaScript components for every content type, and the website builder was able to react to the structure it received because the JSON representation of content entries also included meta information about what kind of entry they were.
Due to the direct connection of content type and JavaScript component our website builder became really powerful and extremely flexible. Words can’t express how happy I became!
You let me be who I am
So my dearest component driven CMS, I don’t think there’s a way back. I love you because you let me be who I am. With you on my side, I can focus on the things I care about the most and ignore the rest! Thank you!
XOXO
Your Stefan
