Choosing a tech stack for a project is not always easy, especially if you are not a technical person. If you are the person responsible for commissioning a new website build for your company, you might get overwhelmed by the new stuff that popped in recent years.
If you choose to do the research, you’ll quickly come across terms like JAMStack, static generators, headless CMS, or headless e-commerce. These new inventions are making waves now, so if the cool kids in the startup world use ‘em, it should be the way, right?
Right?
Don’t just follow the pack. Make an informed decision.
If you’re a developer, you often get excited about the new technologies and want to play with them. Just like a kid wants to immediately play with a new Lego set (and me, you can tell my mom, she knows). But what’s good for a developer, isn’t always in pair with what’s good for the client. On the other hand, successful new technologies always start with a need to solve some problems better. Maybe you have the same problem?
Let me explain the good and the bad sides of the possibilities there, without pushing you into one or another choice.
Why should I choose a headless CMS?
Headless CMS (or headless e-commerce if you’re building a store) is an administrative panel that supplies all the data and functionality over an API. The user-facing interface is typically built as a separate application. Typically, if you talk with a dev shop about building the project using a headless solution, they are going to build the front-end on top of one of the popular reactive frameworks, like Vue or React. In such a case, typically an SSR (server-side rendering) solution of some sort is being used so that the site is SEO-friendlier. Such stack is often called JAMStack, which is an abbreviation from Javascript, API, and Markup.
If you choose to build with JAMStack, one of the popular static site generation tools might be typically used. Depending on the preferred framework, these might be Gatsby or Next for React, or Gridsome and Nuxt for Vue. For e-commerce, there are dedicated solutions, for example, Vue Storefront.
Use of static site generators
Static site generation basically means that based on the data from the API, the whole site with all its subpages is compiled into static files and deployed to a server. If there are no dynamic parts of the site, it could be then even totally disconnected from the API. This is a great advantage from the security perspective - no dynamic parts mean not much to be hacked. Also, serving static files is much faster than generating them on demand. And as a bonus, a site built on top of Vue or React would act in an app-like manner, with seamless transitions between subpages, which makes it very responsive and fast.
On the other hand, in the case of full static generation, it’s really tricky to accomplish partial updates. In default circumstances, the whole site needs to be re-compiled every time you make even the tiniest change in the CMS (and it often takes few minutes to rebuild and redeploy). So you should forget about experimenting and incremental work on the content - you quickly learn to do as much as you can before pushing that Update button. Of course, there are options to overcome these issues, but that’s loads of extra work, tools, and configuration for your devs, depending on the selected set of tools. And extra work means extra money.
Costs of using a headless CMS
Wait, did I just mention money? Yes, that’s an important part of the equation. First things first, you want experienced javascript devs to work on your project, or otherwise, you end with a pile of expensive, fancy spaghetti code. Complex and hard to maintain. Also, the build itself is typically more time-consuming, than building a regular theme for a CMS of choice. In some cases, this might be multiple times more. Last but not least, the hosting solutions dedicated for JAMStack installments require a more sophisticated toolset. So you should forget about some cheap, shared hosting account, that would do the job if you went with basic WordPress or Drupal installation. You’ll need a dynamic server for the headless CMS, a build server of some sort, a static front-end hosting, and probably a CDN. There are nice and reliable platforms that offer holistic plans to cover all of these needs. However, their costs being reasonable for a well-financed startup might still overwhelm a small business owner.
In some cases, the extra money will be an investment, not a waste. If your business deeply relies on your site’s performance, a statically generated site served by a quality hosting provider might help you win the extra milliseconds of load times required for a better conversion rate or a higher search engine rank. All of this is also possible with dynamic sites, but here you get it almost by default.
Other possible uses of a headless setup
It is also technically possible to build the front-end in any technology that can consume data from the API. So for example, you could have a WordPress instance serving as an API and the front-end app build in Python, with Django and Jinja templates. However, that’s a niche solution, so let me leave this one for now.
However, there’s a more realistic scenario, that you may consider important. If you also want to build a native mobile app that would use the same content or create orders in your e-commerce, your developers will request an API. And if you use a CMS that is running headless (or at least, is capable of doing so), the API is already there. And that’s a huge win for you, not only cost-wise but also because in such case you’re gonna be able to manage everything in one place.
Why should I choose a custom-built theme for a regular CMS?
On the opposite side, there is building a custom theme for a CMS of choice. The front-end code will live tightly bound to it. For some reasons that’s lucky to you, for others, it’s a shame.
Starting with something positive: did you ever heard of a thing called plugins? I bet you did. In the ecosystems of popular CMSes like WordPress, there are dozens of easy-to-use add ons. These plugins rely on this tight integration between the theme and the CMS. They can easily inject additional code into the site, using hooks that are part of your theme. In many cases won’t even require a developer’s help for you to install and set everything up. You should of course be cautious as too many plugins can make a site messy and slow. But if you’re a marketing manager, who has a set of trusty tools and wants to progress with the changes on the website at his own pace, you want your plugins to just work. In the case of a headless solution, you’d be able to install all the plugins, but if they require adding something to the front-end, you’re out of luck - the whole front-end is a custom app, so you’ll need a developer to introduce the required changes. And more developer means more money.
Custom theme performance optimization
Another important subject is the website’s performance. While statically generated sites are fast by design, a theme installed on top of a CMS is rendered each time a user clicks on a link. And it will never be as fast as serving an existing static file. It doesn’t mean your site is doomed then. There’s always some space in optimizing the code that pulls and processes the data. But the most used solution is caching. Depending on a site’s specifics, commonly accessed data can be stored in memory for easy access, or the whole output can be rendered into a temporary static file and then served just as it was generated by a static site generator. But it’s not something that you get by default, so you have to make sure that the developer sets it up for you. And the added complexity means that sometimes it could break, so either the site stops to perform well or the cache doesn’t get purged and the old content keeps to be served despite you did some important edits.
When describing the advantages coming from static generators build on top of modern front-end frameworks, I’ve mentioned that such a website feels very responsive, as it doesn’t reload each time you click on a link, but instead gives you a smooth, almost instant transition into the next view. For more traditional builds, you won’t get that by default. For an online store or a corporate website you probably don’t need such fluff. But for a highly animated, designer product page you’ll want the experience to be as seamless and smooth as possible. Luckily, there are libraries like Barba.js, that bring smooth transitions into these more traditional builds. But once again, that’s something that needs to be taken care of, so if you get a quote from an agency or a freelancer, you should double-check, if they understood your requirements.
Costs of using a custom theme
Now let’s talk about the costs. Building the same project as a CMS theme is faster and lacks the complexity of using headless CMS + static generator. It means less work for a developer. As a bonus, less complexity means that a less experienced developer won’t screw things up that easily. Such builds can also be typically hosted on cheap servers. It doesn’t mean I advise you to do so - if you want the best performance, availability, and support, you’d rather stick to a renowned provider, not the cheapest one. But at least you have an option there. Also if you decide to hand over the site’s maintenance to another developer, it will be easier to find someone who accepts to take over a project that is set up in a default tech stack.
Security and other concerns
What many clients fear when it comes to the popular CMSes is security. Building a theme on top of a CMS requires the whole CMS to be directly exposed together with the front-end. It doesn’t mean that there’s no way to make it secure. It’s possible if you and the developer are careful and take some extra measures. Most of the malware is designed to attack systems in their default structure and default configuration. And the headless set-ups are far from default, therefore easier to hide.
If your site’s front-end is tightly coupled with the CMS, you’ll need to stick with it until the next redesign. While the data source for a front-end integrated with headless CMS can be theoretically changed, every CMS has its way of building themes so it’s impossible to install a WordPress theme in Drupal. Realistically, such a need is uncommon for a regular website. But if you build e-commerce, it’s possible that at some point you’ll want to swap your WooCommerce with Magento, and even if it’s just a need for additional back-end features, your storefront will need to be rebuilt too.
What about no-code, cloud-based platforms?
Many popular content management and e-commerce systems are maintained as open-source projects, able to be self-hosted. Some commercial tools are also designed to be run on-prem. This way, you have a choice, where the system will run. You can choose one of the dozens of hosting platforms, or even set up a dedicated machine and put it in your company’s server room if you have one. But with the freedom comes also the responsibility, of keeping the system up to date and secure. In addition, you need to take care of backups and troubleshooting if something breaks.
As an alternative, there are excellent, cloud-based SaaS platforms. Some are proprietary systems, like Shopify, Contentful, or AirTable to name a few. Using one of these, you are free from all of these responsibilities. As a paying customer, you get a platform that is managed for you, always up to date and you can expect it to just run.
Married to a SaaS
But, as you have no control over a SaaS platform, you won’t be able to archive the old version of your site when you change it. You’ll be required to pay for as long as you want to keep it running. If you control the server with an on-prem solution, you can always zip all the files and put them somewhere on your disk.
Also, using a SaaS CMS means a vendor lockdown. If you’re no longer happy with the pricing, or the company gets sold to a larger corporation and seizes the operation, you end up with nothing. As the odds of such a situation are low, it might be still an excellent option for your business. But you should make an educated and well-thought decision there, as you’ll stick with the provider of choice for quite a long time.
Just give me a mix
It’s also worth mentioning that there are also mixed options out there, that combine both worlds. For example, you’ll easily find companies that offer you managed instances of WordPress. Another example would be Strapi, which is available both as a managed, cloud-based SaaS and a self-hosted, open-source CMS.
I still need some help to decide
I hope the read was not that technical for you. Do you feel overwhelmed by all the information? Well, I believe that now you’ll be better informed, and making the right decision will be easier for you and your team. However, if you’d rather focus on your core business - find yourself a trusty nerd. Not every company needs a full-time CTO, so you can get a CTO-as-a-service. If you enjoyed the way I described the whole thing to you, I can be the one. Below, you’ll find our contact details. I and my team will be happy to consult the difficult technicalities for you.
