Custom CMS & Backend Frameworks Be Damned

We’ve gotten accustomed to the ease of use and functionality provided by the modern CMS.

With so many CMS platforms on the market, it’s important to understand what CMS is right for your business. It’s also important not to neglect the organisational impact of a new CMS.

We take a close look at the evolution of the CMS platform, specifically, how the management of content has changed and how platforms have been designed to cater for the changing browsers, new channels, and client needs.

What do you really need in a CMS today? In this article, you'll learn:

Download our Headless CMS guide

Find out how a headless CMS can transform how you think about web content, the difference between headless vs traditional CMS, things to consider when choosing a headless CMS, and many more.

Send me the guide

A little bit of history of custom-built CMS

In the early stages of the internet, there was no such thing as a Content Management System (CMS). In fact, they needed to be custom developed. Similarly to building websites in the early stage of the internet, knowledge of HTML was required to edit and publish content.

Tools were limited, and most people used languages like PHP, .NET, Ruby on Rails, and Python to create websites and craft experiences. However, these back-end languages were primarily designed to process large quantities of information and were not really designed for front-end experiences.

The custom-built CMS platforms were proprietary solutions created for a specific company or use case. They were centralized solutions that enabled users to manage content on a website.

However, the websites were essentially intermingled back-end code with front-end code that was limited to HTML and CSS. Also, a core problem with this approach was that back-end code needed to be modified to achieve front-end changes.

As browsers matured and dealt with more complex interactions such as dynamic websites, the custom CMS became a bottleneck for delivering unique results-driven experiences. Browsers offered new features, but the custom CMS was unable to scale to cope with these features as well.

As a result, there was a need to constantly check the CMSs capabilities against the browser, which became a time-consuming process if the initial architecture and CMS implementation didn’t align with your needs.

However, soon after this, we then saw the emergence of the Model View Controller (MVC) for back-end frameworks and JS-based front-end frameworks.

The MVC framework is an architectural pattern that divides applications into three components and separates the business logic on the server-side from the presentation layer.

The model handles application data. The view refers to the application user interface, and the controller handles input from the view and then updates the model accordingly.

Essentially, MVC began to revolutionize the way the web used to operate and also offered a friendly ecosystem to scale. But how did that lead to frameworks today?

The invention of the framework

Building web applications can be a complex process without some element of structure. A framework provides that structure, enabling developers to build programs for specific applications.

When creating digital experiences, frameworks are important because they can help streamline the application development process, making building functionality for digital experiences easier.

Frameworks are divided into two types: front-end frameworks and back-end frameworks.

Back-end frameworks

The first websites were static web pages built on flat HTML text files. These files were then sent via an FTP program to a web server directory. This was the early 90s, and it wasn’t until 1993 that the Mosaic web browser appeared to support images and provide Server Side Includes (SSI) to allow you to separate headers and footers from the main website content.

By the late 90s, mature full-stack frameworks began to appear, such as .NET and Java. Eventually, in the early 2000s, Symfony, Laravel and Ruby on Rails also joined the fray and helped developers to create more modern web pages and services.

Ruby on Rails, Symfony and Laravel

Ruby on Rails was launched in 2005, providing a default structure for databases, web pages and web services. As an open-source framework with a community of contributors, it continued to develop and eventually formed the foundation for websites we know today including Twitter and CrunchBase.

Symfony, which was also released in 2005 and followed the MVC pattern, speeds up development with the help of open-source PHP projects. Laravel is another PHP based framework that was released in 2011 and includes an elegant syntax which is meant for people who love beautiful code.

Each of these languages helped shape today’s modern web frameworks; however, they do have limitations. Many consider Ruby on Rails to be somewhat slow, Symfony has some security issues and isn’t fit for smaller-scale applications, and Laravel has a difficult learning curve.

Decoupled templating

Eventually, developers found it necessary to add a layer between what they were creating and what end-users saw; this was known as decoupled templating.

Decoupled templating allowed front-end developers to code user experiences and user interfaces for websites using templating languages that were either compiled at runtime or converted into a mix of back end code and front end code.

This divided the back-end frameworks into tools that allow for the development of back-end features and front-end experiences.

(Headless CMS: The Definitive Guide) 

Where we are today

These frameworks grew and matured, and we eventually saw the emergence of SaaS platforms that not only provided ready-made back-end functionality but also allowed the developer to configure and modify the front end using a templating language.

This innovation gave developers alternatives to the existing .NET and PHP-specific frameworks that initially provided a blank canvas where everything was developed from scratch.

Today, those .NET and PHP-based frameworks see decreased adoption as developers look to ready-made features and spend their time designing experiences for conversions. However, while back-end logic is still necessary, it has some limitations in creating end-to-end digital experiences.

For example, there are only a certain number of ways to build a blog. However, what differentiates one blog from another is its presentation layer and how you capture information, which can all be achieved using front-end frameworks.

Front-end frameworks

Eventually, the limitations mentioned above, further development of web browsers, and the need to simplify code gave rise to front-end frameworks.

Front-end frameworks provide a base to build while still enabling flexibility in front-end design. They are relatively recent developments, and the primary reason for their creation was the need to interact much more closely with the browser than was historically available.

jQuery was one of the original front-end frameworks. It was developed in 2006 so that developers could manipulate the Document Object Model (DOM), a tree structure that represents all the elements of a webpage.

What it was able to do was simplify the syntax required to manipulate the DOM elements. For example, finding and manipulating a tag (DIV, H1) and changing attributes like color and visibility.

It also provided a way for events to be handled and manipulated. Finally, it allowed the developer to separate JavaScript and HTML, making it simpler to manage the interactions between the framework and the website. jQuery had been a popular JavaScript library, but handling data consistently across shared views was difficult.

More recently, front-end frameworks have developed tremendously, thanks to the work of modern tech companies. Some of the more popular frameworks include Angular, Vue and React.

Angular, Vue and React

Angular was first developed by Google in 2009 and is still maintained by them. Despite a steep learning curve, it enables developers to create highly complex web applications.

Since code is well structured and easy to modify, Angular removes the tight coupling between application components.

An open-source project created by Facebook, React provides an ideal user experience. It can be rendered on the server or client-side. It features reusable components, which mean developers don’t have to rewrite code constantly.

Vue was created as a fork of Angular and is a framework used for building user interfaces. Vue took elements from both React and Angular and gained popularity due to excellent documentation and the fact that it is a small framework that is easy to learn.

Source

Gatsby

Gatsby is an open-source static site generator (SSG) based on the React framework. It is used to build static sites, Progressive Web Apps (PWA) and plays a critical role in the popularity of Jamstack.

New age frameworks like React, Vue, Angular, Gatsby, and so on have been created to take advantage of the browser functionality because back-end frameworks cannot talk to the browser.

The next generation frameworks: Stencil.js, Svelte, Polymer.

We’re increasingly seeing the adoption of web component frameworks. These are frameworks that use a set of platform APIs to create new custom and reusable HTML tags that can be called within web pages and web applications. These frameworks adopt the web component standard which allows them to work on all modern browsers and can be used within any JavaScript library or frameworks that work with HTML.

These frameworks overcome a large issue with existing frameworks, being the size of the run time and the speed and the compute required. The new frameworks compile into highly efficient JavaScript that is small in size and quick to run. As an example, Stencil.js is a compiler that generates web components and custom elements that are interoperable that work across frameworks. In the same way, Svelte compiles your code into tiny, framework-less vanilla JavaScript that makes your application start quickly and run quickly.

Why use a front-end framework?

Front-end frameworks give you the ability to make the system much more maintainable. Without front-end frameworks, then web applications might fall victim to spaghetti code which can be challenging to maintain.

Back-end frameworks and languages are not designed to work across modules, and you want to keep them modular, so they encourage maintainability. Modular architecture allows front-end developers to focus on what they do best, taking the data and displaying it.

Component-based architecture vs Model View Controller (MVC)?

MVC frameworks like Laravel and Symphony have developed to have back-end technology and front-end capabilities through templating and similar features. They didn’t just build back-end capabilities because they understood the need to be able to provide user experiences.

However, component-based architectures arose because with MVC architecture, some things were hard to reuse. Component-based architectures made it easier to separate concerns and provide this usability.

Component-based architecture has provided frameworks like jQuery, which allowed you to create more interactivity on a browser and create interactions that weren’t otherwise possible. And that’s now expanded into Vue, Angular, and others that approach the problem from a design perspective rather than a back-end perspective.

While back-end and front-end frameworks seem like competing forces, the future of a CMS is always going to need a bit of both.

Back-end frameworks are necessary to create business logic, processing information, and storing information. Front-end frameworks are required to create the ability to capture data from the back-end or any other system and deliver it to the user as seamlessly and intuitively as possible.

How headless architecture is changing the world of the framework

Headless architecture decouples the front-end presentation layer from the back-end logic. With the innovation of the headless platform, it would seem that the back-end frameworks are making a comeback.

A headless platform is made up of a series of back-end APIs that make all the admin features accessible to the developers. In this way, developers can now construct UXs based on whatever framework they choose and seamlessly integrate applications into existing systems.

Also, it allows for a consistent approach across multiple channels. The platform can now deliver the same experience across any technology and any device using a consistent approach.

For example, if someone wants to code .NET and build systems on Azure, they use the same API calls to a REST API or a GraphQL as a front-end developer using Vue JS. They then process that information in any infrastructure subsystem, any application they want, and then deliver it to a presentation layer, using whatever framework they want.

For example, one of our clients, Standard Process has a website that is 100% headless. This headless approach enables agency developers to create web applications outside of the CMS that can read, search, manipulate, write, update and delete that content from that external system, no matter which external system they use.

With Core dna’s APIs they can access all Core dna features from outside the platform, enabling them to create new components, edit a post, delete an input type and more all externally.

Essentially, headless allows you to transport all of the features of your CMS into your own technology stack. Thinking of it in terms of Lego, the marketer is able to create a set of structures from the Lego blocks that can be incorporated into any other Lego project without the need to customize.

In the same way, Standard Process was able to integrate content and CMS features from Core dna into their existing ecosystem without a major infrastructural change.

Download our Headless CMS guide

Find out how a headless CMS can transform how you think about web content, the difference between headless vs traditional CMS, things to consider when choosing a headless CMS, and many more.

Send me the guide

Key benefits that headless brings to building websites

But what are the benefits that headless architecture provides?

1. Consistent access to information from back-end system

Since a headless system connects to the front-end using APIs, this means access to content data is consistent, and content can be delivered to the website front-end without interruption.

2. Flexibility in the types and format you receive

Content doesn’t have to be limited to one format type such as a blog, nor does it have to be limited to a particular format of image, video file or another content type. A headless system can manage various file types and formats and present data in the most appropriate way.

3. The ability for front and back-end developers to work in parallel

When a system is tightly coupled together, front-end and back-end developers can end up getting in each other’s way at times or stepping on each other’s toes waiting for approval with something on the front-end that could affect something on the back-end.

With a headless system, they can work in parallel without affecting each other negatively.

4. The ability to integrate with 3rd party systems easily

For most businesses, content management is only one aspect of their tech stack. They need to include a CRM, manage assets using a Digital Asset Manager (DAM), and connect eCommerce platforms and 3rd party analytics systems. A headless system streamlines this process by using APIs.

5. Future-proof the solutions by separating back and front-end layer

As we’ve shown, front-end frameworks will continue to change and evolve as advancements are made.

Also, the potential channels where content can be displayed will continue to develop in the future.

A headless system is prepared for this due to an API-first approach that separates back-end and front-end layers from each other to provide added flexibility.

6. Consistent delivery across multiple channels

Omnichannel content delivery is a requirement for the modern digital environment. Enterprises and consumers alike are fans of this seamless approach to content, commerce, and marketing. A headless CMS enables this by connecting each system through APIs.

7. Componentization of code and re-use

Componentization breaks down software into identifiable pieces that can be independently written and deployed.

A headless system is built on a microservices architecture that facilitates this componentization that allows code to be easily broken down and re-used, saving developers time when building applications.

8. Improve performance (Caching, controlled the number of requests)

Data is stored in a cache for a specific amount of time to be quickly accessed and used again in the future. With a headless system, content data can be cached, saving time and reducing the amount of traffic that servers have to handle.

Key considerations when choosing frameworks for your CMS

When deciding on the types of frameworks, you’re going to use for your website, you need to consider a few things:

1. What type of resources do you have?

If your business consists of mainly back-end developers, then you’re going to have to use some back-end frameworks to build your solutions.

Also, be aware that back-end developers are generally more expensive because they’re used not simply to create the experience, but also the business logic.

2. Can you handle APIs?

Using a headless system can provide several benefits, but you need to choose the right frameworks to get the most out of it.

Ensure that the back-end framework you use can allow you to connect to other systems to capture information.

3. What are you trying to solve?

Are you trying to solve a business logic problem or a UX issue? Does the framework you’re choosing work best for that scenario?

While using a new framework might seem exciting, you need to remember that it might not solve the problem you’re having, and that’s where your focus should be.

4. Is it modular and can be easily understood?

You don’t necessarily need all of the code that’s included in a framework. With a modular framework, you can choose the functionalities you require for your particular project.

5. Is there a lot of processing involved?

Depending on the type of websites you’re building, such as a sizable B2B marketplace or eCommerce store, you might find yourself processing lots of data or running high volume searches. In a situation like that, you might end up choosing a back-end framework since they are well designed for handling such significant data processing.

6. Is UX really important?

Do you require sliders and drop down menus? Who will be looking at your site, and what might they be doing when they get on it?

Just as back-end frameworks are ideal for processing large volumes of data, front-end frameworks are perfect when it comes to building websites with a beautiful user experience.

7. Is performance an important factor?

If your website will be handling large volumes of traffic and you need it to be consistently up and running fast, then performance might be an essential factor for you.

In this case, you should pick a framework that facilitates high performance and fast loading times.

8. Are you able to maintain the code?

When code is hard to maintain, you can run into issues with spaghetti code that makes it harder for other developers to comb through and fix any bugs or issues. Ideally, it would help if you chose a framework where the code is easy to maintain.

(Spaghetti vs structured sample: Source)

9. Are you going across platforms?

Not every framework is meant for every device. Some frameworks function better on one device compared to another.

Depending on where your content will be displayed, you will need to choose a framework that fits that particular device, whether mobile, desktop, IoT or another channel.

10. Do you have the time and resources to learn the framework?

Each framework is different, with different naming conventions and structure. Choosing a framework with a shallow learning curve can potentially save you and your development team a lot of time.

11. What type of support does the framework offer?

The type of community support available can determine how successful you will be with a framework.

If there’s a solid community, it becomes easier to get answers to your problems. On the other hand, if the community is small, inactive or unfriendly, then you may want to choose another framework instead.

12. Does it have any documentation?

Detailed documentation is a critical component for any web framework. The better the documentation, the easier it is for new developers to start using it, and the faster community growth can be.

On the other hand, poor documentation may leave you confused and scrambling to find an alternative framework very quickly.

Different frameworks serve a different purpose

Since the invention of the internet, frameworks have helped streamline development time and make things easier for developers.

While back-end frameworks were the only options at one point, the introduction of front-end frameworks has been essential for the continued development of web applications.

There’s clearly a widespread move to front-end frameworks, but the back-end frameworks still have a purpose when it comes to performance and number-crunching.

However, it’s difficult to see how back-end frameworks will compete with the front-end as UX becomes more sophisticated.

Yet, the reality is you need both because they have different strengths and weaknesses that you can’t find in either one.

Choosing a framework-agnostic CMS

Nowadays, you don’t need to custom-build your CMS to fit a particular use case. You do, however, need to choose one that provides the most functionality and flexibility for your business.

With so many frameworks to choose from, you also need to pick a CMS that can meet your needs no matter which framework your developers decide to build with. Core dna supports all your favorite front-end frameworks, removing any limitations that might stop you from creating new digital experiences and enabling you to get the most out of more recent frameworks such as Vue and Gatsby.

As a headless CMS platform, you can connect to any front-end using APIs and deliver content to the device of your choice while enabling your developers to work in parallel without getting in each other’s way.

Want to learn more about how Core dna uses APIs? Read: What is GraphQL: And why it might be your secret weapon.