1. Headless content management systems are the future

If I were to develop a new CMS in Go I’d develop a headless CMS and a JavaScript SDK for it to ease frontend development. A headless CMS is basically a CMS that doesn’t render your actual page, instead it serves JSON data (fed into it via the administration application connected to the CMS via its API) to a client-side JavaScript application (or any application really, could even be a native one) which renders it on the client and allows for dynamic user interactions.

2. There’s no need to render on the server anymore (unless Node’s too slow)

In 2019+ the majority of client devices are powerful enough to run a JavaScript/WASM application, there’s really no need to render on the server anymore, instead, it makes much more sense to separate concerns. The server should only provide an API for data retrieval and administration. Go is an excellent fit for writing such systems.

The only real reason to keep rendering on the server might be performance under heavy load (see section #5)

3. Progressive web applications are the future

Progressive Web Apps are becoming the standard for portable (almost) platform-independent applications. They introduce new possibilities previously unseen on the web such as service-workers and more…

• PWAs allow content to be served offline from a local device cache.
• PWAs can serve asynchronous notifications even if the browser tab is closed.
• PWAs can track a user’s activity (geo-location) as far as the user allows.
• PWAs can easily integrate with operating systems like Android and be installed like regular application for overall improved user experience.
• etc.

There’d be a PWA for administrating the site and a JavaScript SDK which would allow you to integrate the CMS into any JavaScript frontend. Theoretically, you could even make a website-builder which produces a JavaScript application compiled with WebPack to an easily hostable bundle.

4. Modern SPAs/PWAs do support SEO

There’s a myth that SPAs/PWAs don’t support SEO, but that’s only partly true (it was true in the past but that problem was eventually solved with new SSR capabilities). If you develop your web application with SEO in mind then it’ll work just fine.

Currently, I’m using the Svelte JavaScript Compiler (also called a “disappearing framework”) and it comes with the Sapper framework which is very similar to Next.js (React) and Nuxt.js (Vue) which has SSR (server-side rendering) built-in.

Your web application is rendered by Node.js when it’s first requested by a client (such as a web browser or a crawler) and hydrated on the client. This way a web app works for both browsers and crawlers. It’ll feel like a server-side rendered page to a crawler but it’ll also work as a SPA inside a user’s browser.

5. If your website is under heavy load then Node might struggle to keep up

Go is usually be much faster than Node.js when it comes to rendering websites and traditional server-side rendering might therefore be better for simple content-driven sites under massive load. Node.js could struggle to pre-render the app under very heavy load and could explode your IaaS bill. As always, there’s no universal rule and headless CMS are no silver bullet but they’ll work for an estimated 80% of all content-driven websites much better than traditional server-side rendered ones in terms of user experience.

It depends who we’re building the CMS for - if it’s a mass media giant then the traditional approach might make more sense than the new headless one (or not, it depends), in any other case, I’d really prefer the former though.