The new new web

How old web technologies are being replaced by scalable and simpler new technology stacks

Over the last five years, almost everything about web development has changed. Oh, the old tech still works, your WordPress and Ruby On Rails sites still function just fine — but they’re increasingly being supplanted by radical new approaches. The contents of your browser are being sliced, diced, rendered, and processed in wholly new ways nowadays, and the state of art is currently in serious flux. What follows is a brief tour of what I like to call the New New Web:

Table of Contents

  1. Single-Page Apps
  2. Headless CMSes
  3. Static Site Generators
  4. The JAMStack
  5. Hosting and Serverlessness
  6. Summary

1. Single-Page Apps

These have become so much the norm — our web projects at HappyFunCorp are almost always single-page apps nowadays — that it’s easy to forget how new and radical they were when they first emerged, in the days of jQuery running in pages dynamically built from templates on the server.

Single-page apps, SPAs, are fundamentally different. The HTML of an SPA is rendered entirely by in-browser JavaScript (or, if you prefer pedantry, ECMAScript). They load once, and then everything happens seamlessly, with no more full-browser request/response cycles. The result is a more seamless user experience, more like a phone or tablet app.

Previously, HTML, JavaScript, and CSS were kept religiously apart — separation of concerns! Nowadays, you mix HTML and JS casually, and CSS-in-JS is a de facto new standard. Five years ago, most web developers would have no idea what you meant by “unidirectional data flow” or “virtual DOM”; now they’re the basic (albeit usually hidden) building blocks of a great deal of web development.

The Big Three SPA frameworks are React (born at Facebook), Angular (birthed at Google), and Vue (independently developed). You can build multi-page apps with all of these, but SPAs are — for better or worse — the new norm. “Or worse” is not just a placeholder there. SPAs can be needlessly complex, especially for small sites, especially when you throw heavyweight state handling like Redux into the miss.

Furthermore, since the entire app/site is loaded in the initial page request, and then dynamically rendered, they aren’t great for search engine optimization. Google can render your SPA into its index, but not every crawler can, and the initial load can be slow. There are ways around this, so-called “isomorphic” or “universal” sites which generate individual pages on the server — using a so-called front-end framework! — so that the first page load always hits a page pre-rendered on the server, and then the SPA takes over.

Needless to say, this is more complex, and if you find yourself needing to render multiple pages anyways, that does raise the pertinent question of why you’re using a so-called single-page app framework in the first place. Even without server rendering, all this dynamic page rendering, and mixing HTML with JS, makes it ever more challenging to incorporate new and/or changing content into your website. Which segues us nicely into another dramatic new development:

2. Headless CMSes

Image via Getty Images / Hero Images

Content management systems are, of course, where it all begins. “The CMS” is a charmless name for the tool which writers, editors, marketers, etc. use to enter, structure, and order the actual words, images, videos, etc. to be displayed to the fabled End User faraway across the web. They’re so important, especially to publishers, that CMSes often become competitive products in their own right: witness Vox Media’s Chorus or The Washington Post’s Arc. (It’s worth noting the impressive growth of Quintype, too, which competes in that same space.)

Traditional CMSes are a relatively tightly coupled part of the same system which ultimately rendered the pages to End Users. However, this tight coupling has become a little awkward. What happens when you want to render the same content in a desktop page, mobile page, phone app, tablet, and Apple Watch? Is one of those considered the “true” output, previewed and referred to during writing and editing, while the others are second-class citizens? That doesn’t seem right. Furthermore, if you’re building single-page apps, which pull their content as an API, why does your CMS have anything to do with that presentation layer at all?

The answer is: increasingly, it doesn’t. The last few years have seen the rise of the so-called “headless CMS,” into which Content is entered by creators/editors, and from which it is siphoned via APIs — but which are, critically, and by design, completely and entirely separate from how that almighty Content is packaged and sent to the End User.

There are certain advantages to this. Perhaps the biggest is simplicity: the CMS now does only one thing, and it’s right there in the name. Another is independence: you can add, remove, and swap out whole new presentation layers — say, change from Rails to React and/or a static site generator — without anyone on the CMS end knowing or caring. A third is consistency: instead of (say) the web client pulling directly from the same database the CMS uses, while the app clients use its API, all clients use exactly the same API protocol.

There are disadvantages, too, which we’ll get to. But this has been a popular approach, and its growth has been remarkable. There’s only space here to talk about a few of the most prominent headless CMSes out there. Contentful is perhaps the granddaddy of this all; to their credit, they saw the move to “pure content” coming before most. Ghost is probably the leading open-source example. Paid, hosted services such as DatoCMS, Forestry, and Prismic probably offer the most features. Even aging-but-mighty WordPress offers a headless CMS configuration now. And Netlify CMS is a very easy-to-use headless CMS which works with, but does not require, Netlify’s hosting and CDN.

So JavaScript of some form running in the browser. Content accessed purely via APIs. Add in just one more item, and you’ve got the newest of the new web, the catchily named “JAMStack architecture,” sufficiently bleeding-edge that the first JAMStack Conference was held just last year. That final component is:

3. Static Site Generators

Along with the rise of single-page apps has come … something of a backlash against single-page apps. “Why not do what web servers and browsers have always been good at?” goes the theory. “Sure, server-generated dynamic pages have problems, but instead of moving that complexity to the browser, why not move it the other way, into a server-side system which pre-renders a bunch of simple pages instead, once, at deploy time, so any bog-standard basic web server can then feed them to the browser, in an easily cacheable manner, via a content delivery network?”

Voila: the static site generator. SSGs take the content from headless CMSes (look, I apologize for all the TLAs in this post, but it’s an inescapable occupational hazard) and use template files to spit out a large number of web pages. Now, these pages can in turn include arbitrary JavaScript, of course. They can even be SPA pages; it’s not at all unusual to generate React pages from an SSG.

But the point is that most of the work is done by the static site generator. This gives you speed: your pages are pre-built, and generally pretty simple and cacheable. This gives you security: no more worrying about a bug in your server code, there is no server code, there’s just a collection of pages. This gives you reliability: for the same reason, the chances of a 500 Internal Server Error are vastly reduced. This gives you simplicity: did I mention there is no server code? (Aside from the SSG itself, that is.)

The advantages are obvious and people have flocked to them. And so there are a huge number of static site generators. The most prominent: Gatsby, based on React. Hugo, built with Go and therefore lightning-fast. Jekyll, integrated into GitHub Pages. Middleman, intended as “Rails for static websites.” Next.js, which interestingly was built to render “isomorphic” React sites, and then expanded to include static site generation as well.

Put these all together, and what do you have? Yes, that’s right —

4. The JAMStack

Image via Getty Images / Caiaimage / Robert Daly

What is a JAMStack site? J is for JavaScript: any and all dynamic programming for a JAMstack site is handled by JS in the browser. A is for APIs: all server-side actions and data are accessed via API. M is for Markup: the M in HTML should be pre-built when a site is deployed, rather than at runtime.

More interesting are the definitional examples of when a site is not JAMstack. Built on a traditional CMS like Drupal or WordPress? Nope. Pages dynamically generated on the server by Rails or Node or some PHP framework? Nope. A single-page app, even if isomorphic? Nope.

I’ve listed the advantages in individual paragraphs above, but I think the key one comes down to: simplicity. (And separation of concerns, but its benefits too come in the form of simplicity.) Simplicity, in turn, breeds speed, security, reliability, comprehensibility, and so many other good things.

That said, the JAMstack is not a panacea. A pure decoupled pipeline with perfect separation of concerns and individual focuses and responsibility is all well and good … but in the real world, writers and editors still want to see previews of how their work is going to look. This is (currently) surprisingly tricky in the JAMstack world. Even Gatsby, perhaps the pre-eminent SSG, has only just launched Gatsby Preview into beta, one which only works with a Contentful CMS, and with no clear actual release date.

At HappyFunCorp we favor Next.js for just that reason (though we’re always open to whatever tool best fits the problem): since Next can be used to render a site as an SPA as well as generate its pages as a static site generator, you can use the former for previews and the latter for deployment.

But the downsides don’t end there. With old-fashioned “headed” CMSes, it was fairly straightforward for non-developers, with a little training and experience in, say, Drupal and WordPress, to create wholly new pages, page elements, and reusable components. In the JAMstack world, this is … much more challenging. By which I mean, almost nonexistent. Static site generators run off templates, and templates are either built by developers or a one-off, bespoke, custom-built admin interface.

There are very limited exceptions: Prismic and DatoCMS, for instance, support some notion of “modular components” which content editors can use to dictate dynamic page content … but they’re still pretty crude. I predict that in the future, more user-friendly interfaces will be built atop SSGs, which look at the content coming from their headless CMSes and automatically turn those into droppable content within a template UX accessible to non-developers.

But we’re years away from that. In the interim, if every new page is different, and/or your page content changes frequently and drastically, a more traditional CMS may be for you.

5. Hosting and Serverlessness

It would be remiss of me to mention a couple more aspects of the new new web. One is the rise of hosting-as-a-service providers, which take your pages, serve them to the world, and handle all manner of administration, configuration, exception handling, versioning, etc. on top of that. Notable players in this area of Netlify, GitHub Pages, and Firebase Hosting.

The other is the ride of “serverlessness” — code which Just Runs Somewhere, without you having to worry about provisioning, maintaining, configuring, or (much in the way of) authenticating to those servers. Yes, this sort of kind of used to be known as “Platform-as-a-Service”, when PaaS was a thing. AWS Lambda and Google Firebase (also widely used for authentication, which it’s exceptionally good at) are fighting this out, and it’s also worth noting Zeit, the creators of Next.js.

6. In Summary

What we are seeing is the intersection of two main trends, both driven by the increasing complexity of web technologies. One is to make the business of web publishing simpler, and therefore faster and more effective, by breaking down that complexity into its constituent parts, decoupling them, and simplifying them as much as possible. The other is to deal with it by offloading it into the browser — a complex React SPA talking to a headless CMS’s API, which is not at all uncommon, is not unlike bundling a static site generator into a browser — and using ever more sophisticated front-end frameworks.

Either way, we’re seeing a significant decline in traditional server-side templated web-page generation via Rails, Drupal, Node, WordPress, etc etc etc. Is this purely because SPAs and the JAMstack are the hot new thing? … I won’t lie: that’s a factor. There are loads of projects for which a Rails app continues to be simplest and most viable solution. But at the same time there are real benefits to the new approaches: in particular, the user experience of an SPA, and the speed/simplicity of the end product of a static site generator.

Which is the best solution? My answer to that is: context is king. It really depends on the specifics of your problem. (And you can conceivably waste more time choosing the right path than you gain from following it.) But as a rule of thumb, if it’s a complex site for which user experience is key, favor an SPA. (There’s a reason that two of the big three SPA frameworks came out of Facebook and Google.) If you want to decouple content and presentation, especially if you’re reusing content across many presentation interfaces, favor the JAMstack. And if you’re just building a straightforward site … then you’ll still probably save time and money sticking to the tried-tested-and-true old ways.