Why Working with Content is Hard for Developers
April 18, 2022
- Traditional CMSs require a lot of knowledge and effort to build, deploy, and maintain.
- Static site generators don't scale well beyond hobby sites.
- As revolutionary as headless CMSs were, they didn't make building front-end applications easier.
- Gatsby re-imagined the experience of building a website, and yet the opinions it imposes on working with content are limiting.
- Modern frameworks have brought an incredible developer experience, but require that developers manually build a mechanism to process content.
1. Traditional CMS Separated Content from Code
Monolithic Applications are Limiting
- Managing infrastructure: Developing a monolithic application usually means managing the infrastructure of that application. You have to know how to work with web servers. You have to be well-versed not just in making database queries, but in managing and optimizing databases themselves.
- Slow and insecure: Though traditional CMSs often have caching mechanisms, they are notorious for slow performance and security vulnerabilities.
- Not sufficient for today's needs: The tools we have at our disposal today turn many developers away from what is becoming an antiquated pattern for building web experiences.
2. Static Site Generators Offered a Simplified Approach to Building Content-Driven Websites
Developer Experience with SSGs Degrades Beyond the Hobby Site
- Validations: Validating content is either not an option or must be done manually.
- Relationships: Creating complex relationships among content is often a manual process, and can drastically lengthen build times.
- Components & Interactivity: Client-side component libraries are not supported out of the box. Interactivity is inherently more difficult to implement and manage.
- Performance: Though some SSGs are optimized for build performance (e.g. Hugo), many slow down significantly as the number of files grows.
- Tight Coupling: Content and code are tightly coupled, which means it’s difficult to have a source of truth for content serving multiple websites.
Content as Data
3. Headless CMS Decoupled Content and Code
- Simplified front ends: Developers no longer had to manage the content-editing mechanism for a website. No more databases or authentication for the typical websites.
- Multiple front ends (omnichannel): A single content source could serve multiple front-end sites.
- Unlocking SSGs for editors: Non-technical content editors could manage content for static sites without needing to access Git/GitHub.
Front Ends Weren’t Easier to Build Because of API-Driven Content
- Added complexity: It added complexity in a lot of ways. If using a classic web framework like Ruby to manage the front end, you’d have to make API calls for data, rather than being able to use the standard and familiar ORM.
- Additional layer: With SSGs, the addition of a headless CMS meant adding another layer to the application. You’d often still have to cache that data to local files so the SSG could read and render it.
- Availability risk: Because content was stored in a separate application, the risk of content not being available increased.
- Previewing difficulties: Headless CMS also made it more difficult to preview content before publishing, especially when building the site using an SSG.
4. Gatsby Popularized Content as Data using GraphQL
Content Processing in Gatsby is too Opinionated
- GraphQL required: To work with Gatsby, you already have to learn React. Adding this layer means yet another thing (GraphQL) developers have to know to use the tool.
- Content validations: Gatsby doesn’t provide content validations out of the box.
- Loose modeling structure: When working with local markdown, there is no concept of modeling. The content appears structured, but comes as large data objects with potentially conflicting properties and types. A lot of type- and presence-checking is often required.
- Lack of TypeScript: Seven years later and many versions later, it’s still difficult to work with TypeScript.
5. Modern Frameworks are Unopinionated on Content Processing
- Variable rendering techniques: Within a single site, developers could choose whether a page should be statically rendered or server-side rendered. Suddenly we had the power of on-demand content without the need for a single-page application or client-side data fetching.
- DIY content processing: Next.js brought no opinion on how content should be handled. It left the GraphQL layer out and instead focused on providing developers the tools they needed to build powerful websites, while bringing content from anywhere.
Building a Content-Processing Mechanism is Really Difficult
- Low-level code: Writing the processing logic, including working with content-processing libraries and their plugins. This is a lot of base-level logic and adds a number of dependencies to your project.
- Caching: Caching processed data. Caching is hard. Not caching degrades the developer experience.
- Content relationships: Rich and complex content associations, so that objects can live as individual content files but be embedded as necessary when used as data.
- Live reloading: For some frameworks, like Next.js, pages are not live-reloaded automatically when editing markdown content. That’s another mechanism to build.
- TypeScript support: Generating/writing type definitions. If you want to work with TypeScript and strongly type the data, that must be generated manually.
- Validations: Data validation logic will have to be implemented manually, or you’ll want to build an abstracted system that accepts validation settings through configuration.
6. Contentlayer Makes Content Easy for Developers
importcontent just as you would any other library or component
- Validations: Built-in and configurable content validations
- Performance: Incremental and parallel builds
- TypeScript support: Strong-typed data (TypeScript types are generated automatically)
- Live reloading: When supported by the framework
Sean C Davis@seancdavis29
April 21, 2022
Working with content data (e.g. Markdown files or CMS) is a surprisingly difficult and laborious task when developing modern sites (e.g. with Next.js). Contentlayer is a content SDK that aims to make content easy for developers.Read more