When doing web development, it can be super difficult to find a stack that fits your needs. With CMS, Headless CMS, full stack frameworks, backend frameworks, frontend frameworks etc. it is very hard for folks not familiar with web development to know what to use or even what they need. As someone with a background in software, it was hard for me to understand how things like CMS and Headless CMS fit into the larger picture. Here we seek to provide a roadmap that demystifies all this and gives folks an idea what the relative advantages of each are.
To go through this analysis, we will focus on three dimensions of these options: complexity, capability and performance.
For folks getting into web development this is often the most important factor. Being able to pick up a framework and become proficient in it is the foremost goal. The time it takes to learn these skills can vary widely based on the option you choose. Balancing this against your business goals is of great concern.
The lowest barrier to entry would be WordPress or other full fledged CMS frameworks. Why? Because they require no code, and there is abundant learning material to understand this kind of CMS. Additionally, things like WordPress offer tools that allow developers to go deeper and write CSS, HTML and even JavaScript. For those looking to get started CMS is a fantastic way to get a site up and running quickly, and allows the opportunity to understand more deeply how CSS, HTML and JavaScript all work together. CMS also provides the benefit that you can readily train your clients to update their sites themselves if there is something basic they need done like adding pictures, blog posts or info.
Headless CMS is all that CMS normally does without the frontend. Yes that is confusing, yes it is hard to understand, please bear with me. Basically Headless CMS functions to provide an interface that you can visually interact with that allows you to manage content. So you could write a blog post in the headless CMS interface, add pictures or modify products you have in a store. The one thing you will not do in headless CMS is build your web pages. These will be built with some other frontend framework. Headless CMS can be difficult to learn because the frontend is completely separated, so you may choose to combine a Headless CMS with a frontend that does not have a lot of learning material describing the combo. Depending on the front end you choose, it may not really be that much more complex than traditional CMS, but making those design decisions and deciding which frontend will work well with a given Headless CMS is something that has a learning curve of its own.
The advantage of Headless CMS is that it allows you to continue to maintain the ability for non-technical folks to add content like blogs, photos etc. while giving you more room to build the frontend.
Fully code frameworks like .Net or Django can serve the same role as headless CMS, and similarly allow you to divorce the front and backend logic. The big difference here is that you now are managing things on the web server more directly without the layer of separation the UI for Headless CMS provides. This means you not only need to define your data models, but also write logic that will manipulate/serve them. This adds another layer of complexity to learning, but can widely be reused once you have it down. So you would not really need to rewrite the logic once you have it for a single site, but only the logic that is not common between sites.
Decisions based on complexity need to take into account the relative ease of learning these approaches with the long term goals. If you need to pump out sites for businesses which are mostly static, maybe its not worth the time to learn .Net and go that route. If you are building software practice that plans to expand its reach into more complex wed apps then I would advise working towards at least the Headless CMS paradigm or better yet a full stack solution like .Net. It really depends on your needs so it is important to understand also the capabilities.
What can these different frameworks do? If they all have the same capability we would never use the more complex options, however that is not that case. Lets dive into what they can do.
All different frameworks can handles our most basic use case: A website with static content. We could do this in WordPress, a Headless CMS + some frontend, ASP.NET etc. Any of these can create static web pages. Static web pages do not do much in the browser itself, they just display HTML. Assets are stored on the server and retrieved and this can be done with HTML alone in most cases. If this is all you need to do, you may just stick with CMS, as it can do this well.
If we need to connect with services/APIs we run into some trouble with CMS. A lot of CMS services don't make it super easy to connect with arbitrary APIs. If we wanted to do this in WP it would be tricky and you would need to find a plugin that does what you want or write some code yourself. At this point, you are not getting much benefit from CMS and might prefer a headless CMS or a fully code option.
The final level of capability is what we might describe as app like capabilities. Consider something like Gmail. It functions more like an application than a simple website. Building something like that in WordPress would be really difficult and unwieldy. In a headless CMS framework it would still be clunky to build the logic that would run an app like that because of the complexity of the data manipulation going on there. This is where fully code solutions really become the clear winner. Something like .Net or Django would allow you to create something like Gmail with as little friction as possible. Of course it would still be a large development task but you would be using the right tool for the task. Think of it like this: If you wanted to create a plastic figurine from a 3D model on your computer, you could whittle a large chunk of plastic with a knife and if you got really good at that make a pretty exact copy. That is your CMS and Headless CMS approach to web apps. If it were me I would just use a 3D printer, that is analogous to our full code approach here.
Performance to us means both speed and security. For traditional CMS, this is often the stumbling block. WordPress is just not that fast and not that secure. For static pages again this is not dispositive because there is little security concern and little performance demand. None the less, if you are hosting a static page for a giant law firm with a huge budget, you better make sure that page loads super fast if you want your client to be happy. You also don't want their site to get taken over by adverse actors and used to run a phishing campaign so if you use WordPress you may end up speaking with your own lawyers when things get compromised.
WordPress has two characteristics that make it a security wimp. First it is hugely popular, so much effort is put into trying to find vulnerabilities by hackers. Hackers want to be efficient too. They spend their time looking for flaws that are widely applicable. Second, WordPress often will put you in a situation where you are relying on plugins. These plugins could be created maliciously or carelessly and later exploited by malicious hackers. This means you need to be super careful with plugins, as the cool weather plugin you found for your ski resort website may contain bad code that a hacker uses to turn your website into a bitcoin mine behind the scenes.
Other CMS platforms like MODX are faster and more secure, but come at the cost of ease of use. They may be suitable if you plan to put out a high volume of static pages, and want to be able to offer enhanced security and speed. They still fall short in functionality though as they are not as robust as Headless CMS or fully code frameworks.
Headless CMS can perform as well or potentially better than some full code frameworks for the tasks they function well in. However if you are pushing them to their limit you may struggle to get acceptable performance. Security can also be very good here just like it can be for other standard CMS frameworks, but it will never be first in class. The issue is again you are relying on someone else to provide you with securely written software. If you do not know a lot about the folks making a certain CMS (headless or not), you should not trust it when security is a concern.
Finally we have our full code frameworks. These are the fastest and most secure for most use cases. This comes with a HUGE caveat though: Fully code solutions are only faster and more secure when the developer does things correctly. You could create a web app that is far slower and less secure than a WordPress site if you do not write your code properly. So this approach is a double edged sword. If you are worried about speed or security and use a full code approach, you better stick very close to best practices and do your homework so you can be sure you did things properly.
Deciding what framework to use is a challenge, especially when getting into web development from a different background. You need to consider the requirements of the sites you plan to build as well as your long term direction as a developer/company. If you want to make static web pages and focus on aesthetics, use WordPress or MODX and get to work. If you want to make web pages for folks who need more than just animations and logos on their site, keep that in mind and start working towards a fully code workflow by using Headless CMS. If you have the technical background and want to work on bigger web apps, skip it all and go to a full stack framework like .NET/ASP.NET.
It really comes down to your goals. At Golden Bay Industries, we decided early on we would like to build cutting edge web logic for clients with complex needs, so we decided against using introductory types of frameworks like MODX. We want to bring our clients the fastest, most secure and best looking sites. The decision to ignore our competition and focus on quality and not quantity has lead us down this path. From a business standpoint it is a waste of the talent we have at GBI to just pump out endless CMS built static web pages when we could be solving larger business problems for our clients.
