Is the future really headless?
Headless CMS's seem to be all the rage these days and you see headless CMS vendors saying "Headless is the future". However, I wonder if they are right for most small businesses. It seems that while you have the flexibility to build your front end the way you want, you have to hook up more services to make it all work.
If you're just building a website for yourself then that seems fine, but if you're building websites for clients is this the best way to go? They have to pay for a headless CMS and pay for another service to host their site?
What are your thoughts?
Do you think that headless CMS is the right way to build websites now? If so how are you managing that with your clients?
If you're going headless how has that helped your process of building websites?
Or do you prefer a more traditional CMS where more is built-in? If so, why?
I'm trying to understand for myself and my agency if headless is the way to go or if we should stick with what's working for us so far.
Thank you!
When you build something in a JavaScript framework (or any decoupled codebase), you can bolt on huge bits of functionality that you would typically have to migrate the whole infrastructure to.
This is where headless comes into its own.
I built a basic web app, but as time went on I wanted a shop (Shopify API) and then later I wanted a blog (WordPress via treaclewp.com) being able to bolt these on without having to transfer the codebase into liquid or PHP is perfect.
For most people a traditional CMS would be the best solution but there are niche use cases for headless like when you want to present content in non-websites like webapps and mobile apps. Instead of having a marketing site and a webapp on separate domains you could have the fat client webapp display CMS content. But you have to make sure it's server-side rendered so the search engines can crawl it.
It depends on the use case. For most companies, headless is currently not a good fit. I worked at an agency that started pushing headless CMS solutions, and it didn't go well.
One of the selling points of headless is having a clear separation of content from presentation. That way, you can reuse your content in many different ways. When the customer wanted to update their site, they had difficulty figuring out what they needed to do. They were still thinking about pages on their website and not the data used to create those pages.
Another issue is that it can be tricky to configure a fast yet accurate preview system. The customer adds content, and they want to see what it will look like on the website right away. If the preview requires rebuilding, it could be over a minute (or longer) before the customer sees the changes. Authoring content is iterative. If the write-preview cycle is slow, it amps up frustration.
There is also the security of the preview. If it's not in the CMS, the user might have to log into a preview site separately. That's another step that causes friction.
As a developer, we see all the technical benefits of headless. However, we need to understand the customer's needs and abilities. There is a real opportunity for a hybrid solution to author a site in a simple, user-friendly way and reap all the benefits of a headless system.
I agree with you here. As a developer I can see the benefits for me with headless, but I question the actual benefits for the customer. Anytime you introduce more parts to a system you welcome potential complexity.
A hybrid approach makes sense to me too. The CMS manages the content and displaying pages but it has a robust API to deliver the same content to other systems if necessary.
If you're clients have 1 site traditional CMS is fine.
More and more folks are wanting multiple sites, mobile apps etc (not sure it actually moves the needle, but they love being busy)