A Front-Ender’s Position on Static Web Apps

“Long live microservices.”

Today, I’m going to talk to you about a couple of different things, but the recurring theme throughout it all is going to be the JAM Stack.

If you’re not already familiar with the JAM Stack and what it’s all about, it stands for “JavaScript”, “APIs”, and “Markup”. But more specifically, it points to what is, for me, the most exciting glimpse of the future of web development, namely, that static is back.

Now the JAM Stack isn’t exactly new. It’s been around for a while, and a lot of strides have been made in defining a nomenclature around it which, frankly, doesn’t suck. But let’s unpack that a little bit. What’s the problem with the nomenclature as it exists today?

Well, again, the key word here is “static”. What do most people think of when they hear the phrase “static website”?

Maybe something like this (no pun intended):

But the reality of what’s at play here goes way beyond what the web was capable of in the nineties. It would be more on-point to say that what makes the JAM stack unique and uniquely performant is not a static site but rather a static payload — a static build, if you will — that belies a potentially much more complex architecture and dynamism.

And it’s all made possible by the era of microservices. From cloud computing to global CDNs to APIs, webhooks, and build automation, the layers of architecture involved in putting together a sophisticated web application have all been decoupled and refined to the point where we now see PWAs and SPAs keeping pace with full-fledged native applications.

How is it all possible? It’s beyond the scope of this article to go through every possible layer, but I will take the time to talk about certain key touch-points here.

Cloud computing has given us serverless web environments, where developers no longer have to worry about provisioning or dealing with servers, which now falls to third-party providers.

Server-side rendering has allowed for a shift towards isometric or universal javascript utilized on BOTH server- and client-sides, which has ultimately allowed static site generators like Gatsby or Jekyll to refine complex static site delivery solutions; and service workers have challenged the limits of the web application experience. (The JAMStack is actually antithetical to SSR, but more on that in a bit)

Functions as a service and build automation through providers like AWS or Netlify has even taken away much of the pain of hosting and deploying (which I personally loathe).

Then there’s middleware like GraphQL, (or even on a much more plug-and-play scale, even Axios) which has smoothed over the massive pain point of making API calls to multiple different endpoints and having to consolidate disparate data in potentially expensive client-side processes — while still allowing for SSR-based architecture and the potential for full CRUD functionality that doesn’t force users to wait on the full lifecycle of a server call or database query.

So, in a word or two, what does it all boil down to?

Collating dynamic data via APIs, content is rendered statically at build-time, and the static markup informed by this dynamic data and build process, is delivered via content-delivery network to the client (browser), which happily (and rapidly) gobbles it up and delivers a lightning-fast time-to-first-paint.

And what’s the deal with server-side rendering? As I said, the JAMStack is antithetical to isomorphic SSR. SSR utilizes universal JavaScript on both the server and client to dynamically render content as a user interacts with a web application. One of its most tangible advantages is SEO. Web crawlers have traditionally had a more difficult time where SEO is concerned, but this risk is massively mitigated by prerendering solutions (often in the form of yet another microservice).

Once again, in a word or two, what’s the real tangible benefit of static site deployment?

• Once again, more rapid load times with limited latency, as a result of the fact that most if not all of the complex business logic runs before the website markup actually hit the client. No more users leaving a site because it took more than three seconds to load.
• There are no database bottlenecks since all dynamic data is consumed via API.
• The additional complexity of an isomorphic server environment (like Node), is not required.
• Serving content over a content-delivery network is significantly cheaper than maintaining back-end servers.
• Finally, with a site being pre-rendered and only static markup being delivered to the client, the surface area for attacks is dramatically smaller. The site is safer and more secure, and the right caching strategies can even keep a minimum threshold of user experience running even if the site, or a user’s connection, goes down.

The long and short of it is this: statically-generated client sites have the potential to be as dynamic and sophisticated as nearly any dynamic server-side web application solution, and will deliver a quicker, more stable, more secure, more native-app-like experience to end users.

Long live the web. Long live microservices.

(Stay tuned for a hands-on project demo exploring this ecosystem and more of its implications!)

Evan is an illustrator, developer, designer, and animator who tells stories in any which way he can. When he’s not branding businesses or building front-end apps; he’s illustrating children’s books, painting for tabletop games, animating commercials, or developing passion projects of his own.