The Pros and Cons of a Static, or ‘JAMstack’ Website.

The Gist

Ah, there you are, dear reader. Looking to start or upgrade a website, eh?

Well, you’ve found the right article, good show!

Might we interest you in a ‘static’ or ‘JAMstack’ website, instead of the usual?

You know, vendor lock-in, subscriptions adjusted for inflation, or platforms that make watching turnips grow seem more…engaging? Yes, yes, there are caveats and whatnot. Things to be mindful of, the usual gibberywhatsit.

But on the whole, it’s well worth going ‘static’. Hosting is near free of charge, performance is unmatched and security is downright ravishing if things are done right. Not to worry, we’ll help you with all that.

Care to explore further?

Out With Old, in with the Older

Out with the old? You mean hand-coded sites?

No, dear reader, out with the do-it-all-but-not-so-well, and back to hand-coded sites! But with a smidgen of automation, optimisation, and integration of course. Old ideas, new tools, and new methods. Much better, as you’ll soon see.

Back in the day, but after people stopped coding their websites by hand, the world moved towards CMS platforms. Fiddledyjibbits like WordPress, Drupal and Magento. Or platforms with even less self-determination such as Wix and Squarespace.

By default, these all generate web pages on-demand, with the help of a database. A mechanism some affectionately call ‘dynamic’. Not us, dear reader, we never much cared for them.

Enter ‘static’, or ‘JAMstack’ websites.

The long and short of it, dear reader, is that with this type of website, the pages are generated ahead of time. For the most part at least.

That’s what is meant by ‘static’ in this case. It certainly doesn’t refer to animations and little ooh’s and aah’s. Those were never actually dynamic in the first place.

Dynamic means generated on-demand, with the help of a database, whereas static refers to generated ahead of time. While great for reasons we mentioned earlier on, static sites do force us to rethink things like shopping, chatting and the like. More on that in a bit.

A Deeper Dive

As we briefly mentioned earlier, most websites are managed by a ‘do-it-all’, such as WordPress, Drupal, Magento, and others—even to this day. These offer a management panel, the ability to expand functionality with plug-ins, and a web page generator.

Thus, they aren’t actually single tools. They are frameworks. Large applications that group together functions that could exist as separate, optimised components. For sake of completeness and user-friendliness however, these are instead grouped together into a single product, and pointed towards a single central database.

The Dynamic Approach

There are a few glaring issues to this approach, or we wouldn’t bother to take our chat in this direction. For one, it breaks the rule of Keep It Simple, Stupid. Large, complex applications such as these are difficult to maintain, and difficult to secure. Indeed, security with these platforms is such a pain in the seating device, that there is a whole industry of ‘we’ll manage it for you’ out there.

Another glaring issue with most of these platforms is inefficiency. After all, we want to serve as many visitors or customers as possible per coin that we spend, don’t we? In other words, we want our data to find its way to our visitors as quickly and directly as can be.

There’s the rub, dear reader.

In the early 2000s, people cared more about getting things done quickly, than getting things done properly. High-performance programming languages were ill-equipped for web development at the time, and skilled developers were in short supply.

Thus, it became the norm to develop web applications using easy-to-learn, but slow-to-run programming languages. Development speed, and low barrier to entry for new software developers, justified this decision. Along with the assumption that hardware would become cheaper, and more efficient over time. All true to some degree, but it didn’t take a few important tidbits into account: the number of people using the internet, and the complexity of websites would increase as well.

And what languages are those, hmm?

Right, sorry dear reader, we thought we’d keep this article more approachable to readers of all technical pedigrees. Well, we mean scripting languages such as PHP, Python, Ruby, Perl and server-side JavaScript (node.js). It’s ironic in a way that the issue between dynamic and static in the realm of websites, is similar to the issues of dynamic and static in the realm of software development. Things that are generated ahead of time (pages, machine code) are more efficient and perform better, than those generated on-demand.

The second issue with dynamic websites is the use of a database for every part of the delivery process. That simply doesn’t make sense, as it slows things down considerably. Using a database for obvious things like payment transactions, user comments, and product recommendations is to be expected. But using a database to generate pages that are intended to be openly accessible by both users and search engines, is just silly.

In other words, we should only use a database if we really need to, and we should only use scripting languages where moving high volumes of data around isn’t the intended purpose. It will come as no surprise then that uncle Enterprise, again shows us the way, by bringing back static websites and focusing more and more on ‘static’ (statically typed) programming languages.

The Static Approach

One of the major selling points of the static approach, is its directness. The files that make up the website are simply read from disk, and sent to visitors. That is just about as direct as it could ever be. All the software handling the process of reading, and sending the data, of course having been written in a static language as well. Yay, static.

What about serving files from memory?

Good idea, dear reader. We should look into that. Nice one.

Let’s have a brief exploration of the static website concept in a bit more detail, in particular why they have a second name—‘JAMstack’. We’ll keep the nitty-gritty for the next section however, ‘Static Sites in Practice’.

In all seriousness though, who came up with these naming conventions? No wonder we have issues with keeping a slim figure. JAMstack… Jam… Jam roly-poly… Hmmm.

Ahem, righto, on with the convo.

One of the key benefits with the static approach to web development, is separation of concerns. We can for instance use a content management system to store our data if we wish. But unlike the dynamic approach, the pages are taken from the database only once, and written to a content file. Content isn’t fetched over and over, unless changes have been made. We can also skip the content management system altogether and just edit the content manually. Which isn’t as hard as it sounds, dear reader, far from it.

The static site generator then reads the files, and uses a set of templates to generate all the sites pages. A nice, clean separation of content and output. The site and its data are no longer joined at the proverbial hip. That’s all well and good of course, but we still need to address the roly-poly. Let’s do that next.

As you may or may not know, dear reader, web pages are generally made up of three distinct types of layers and accompanying types of files. That is, HTML for content and the labelling of sections, CSS for the layout and presentation of said content, and lastly JavaScript to provide interactivity. We’ll get to explaining the interactivity bit in a minute, but in their basic form, these things are collectively referred to as ‘Markup’. The M in our Jam as it were.

Interactivity is where things get a bit more interesting, however.

We apologise to HTML and CSS, you are also interesting. It was just a turn of phrase. We are not, have never been, nor shall we ever be markup-ist. We respect all forms of markup, and have every intention to defend their rights to format content in perpetuity.

So, interactivity is both a deceptively simple and yet complex concept alike. At least, where its implications are concerned. JavaScript can be used to change the behaviour and appearance of a web page—in the broadest possible sense. Not only can it change the size, colour, and animations of an element, it can also remove them, or create new ones entirely.

This is the key to having the best of both worlds, dear reader. Our publicly accessible content is generated ahead of time, while JavaScript can then be used to fetch information from elsewhere and put it into our pages when necessary.

How? Through the use of APIs.

Let’s take a site that has a shopping element to it as an example. All the usual pages such as who we are, what we’re all about, the latest news, and even product descriptions are all generated in advance. Ready to be sent to both users and search engines at blistering speed. But user reviews, product recommendations and the shopping cart are anything but static. Thus with a smidgen of JavaScript, we can have these things loaded onto our page as necessary.

Someone visits our page, reads a bit here and there, is awestruck by how cheaply you offer a ‘silver-plated nose hair combing kit’, and clicks on the product page. When the page loads, a bit of JavaScript gets to work. Behind the scenes it contacts another server—by means of its API—and exchanges messages with it. It then receives user reviews, and product recommendations and loads them on to the page the visitor is looking at. Should the user decide to buy, then it will start a secure session, authenticate the user—and their method of payment—in much the same way. Thus we have achieved dynamic interactivity on our static site, as well as having explained the J and A in our Jam roly-poly.

What we have here is the nuance we’ve all been waiting for, dear reader. A static site isn’t entirely static. It’s static where it needs to be, and dynamic where it needs to be as well. But instead of having a single ‘do-it-all’, we have fine-grained control of each and every aspect of our site. From creation, and delivery, to interactivity and functionality.

Static Sites in Practice

As we alluded to before, hosting a static site can be free of charge, and its security can be nigh-impenetrable. This may very well be the most attractive selling point for most. If it is for you, dear reader, then we would like to remind you of the enhanced user experience as well. Faster is better. Happier visitors, means visitors that are more likely to return.

With a static site, the delivery of our content is no longer tied to any application or database. That means that all we need to do is to distribute files. Text files, images, perhaps a font or two, but little more than that. This greatly simplifies the hosting of our site. So much so in fact, that it is essentially free.

One of the more interesting additions to the World Wide Web in recent years, is that of the Content Delivery Network, or CDN. Sounds fancy, doesn’t it? Well, in fairness, because it is! What it means is that a CDN provider, with locations all over the world, keeps copies of your website’s files. Visitors then get the copies sent to them, from a location nearest to them. This not only makes things even faster, it also reduces the workload of the server that holds the original files, the so-called ‘origin’ server.

Because of this, many online service providers are willing to act as your origin server for free. Services such as Github, Gitlab, Bitbucket, Codeberg and others offer such a service. Call it fear of missing out, but whatever the case, they all offer it for free—and they are unlikely to discontinue the service unless they all decide to do so.

Combine that with a free CDN such as Cloudflare, and you’ll have a website that is highly secure, and high-performance, for free. Okay, not entirely for free as you’ll still need to pay for ‘myamazingbiscuits.com’, but that is a given anyway.

Now you may be raring to get started, dear reader, but we still have a few important issues to discuss. This is after all an informative article, not a tutorial or guide. Fret not, we are developing a detailed guide on all that you need to get started, along with a few bits of useless information for good measure. We’ll publish that as soon as we can, but let’s focus on the other practical aspects first.

To recap: We can choose a static site generator, choose an existing theme for it, or make one from scratch. We provide it with content that we either edit manually, or with the help of a content management system. We can then upload the whole thing to a Git service, such as one of those we mentioned earlier, and set up an automation process that re-generates pages when necessary. Lastly, we can use a free CDN service to optimise the delivery of our pages. That about sums up the static, or ‘Markup’ part of our website project.

Let’s have a look at the practical side of the dynamic parts of a JAMstack site next.

As is tradition, let’s look at some caveats first, lest we boil over with too much excitement. It’s good to keep things in perspective. Or not. Who are we to judge, suggest, or guess?

The first issue with the dynamic part is that if we opt to self-host our dynamic components, is that we run into many of the same issues as when we use a ‘do-it-all’. While our pages can indeed be copied and distributed around the world, our databases can’t. At least not very easily. To do so requires either highly customised software, or expensive proprietary solutions.

So, while we do have the option available to us, they don’t come easy. Or cheap.

In practice, it is therefore more common to subscribe to third party providers for dynamic components, such as shopping, contact forms, user comments, customer support and the like.

If we aren’t careful, this can get pretty expensive, pretty fast. But then again, these things (shopping in particular) are never cheap, and certainly not free. Adding these features to Wix or Squarespace ramps up the monthly subscription considerably, as does the use of commercial plug-ins on WordPress and others. With a static site, our options are at least considerably more flexible, with the added bonus of having saved money on the hosting of our core website.

But we won’t lie, it is more complex to set up. Hosted platforms like Wix, Squarespace and WordPress.com make things easier, no doubt about that. But they also charge a premium for it, along with offering lower performance and efficiency.

Self-hosted platforms like WordPress.org, Drupal, Magento, Typo 3 and others also make things a little easier. But at this point they are so financially and technically inefficient, that they really should be retired. Yes, yes, these days they can also emulate static site functionality and all that, but it’s not the same, not as efficient, and still more expensive.

Setting up a static site, and adding dynamic components to it in particular, requires us to roll up our sleeves and do more involved work. But there are two beams of light at the end of that tunnel, dear reader. For one, 3rd party providers provide better and better documentation and examples. For the other, you have us. We will publish guides and tutorials galore, until the job is done. By that we mean, all of us having a static website, a Jam roly-poly, and a satisfied smile—while we hit the treadmill and wonder why we gave in to the urge to snack.

The Takeaway

So, there we have it, dear reader. The benefits and caveats of a ‘static’ or ‘JAMstack’ website. More efficient, higher performance, more secure, and cheaper—but more complicated. But we won’t let a little thing like complexity get in the way of genuine savings, will we?

More and more enterprises and smaller businesses alike are migrating to the static approach. With them, more and more service providers are ramping up their offerings and guidance, as well.

As promised, we are developing a comprehensive guide on getting started with JAMstack, focusing on our framework of choice: HUGO. It’s fast, efficient, mature, and well documented. But it could do with a bit more of the latter, so we aim to fill in the missing bits.

See you there.

Yours,

Digerty

P.S. Although for staunch reasons we don’t engage with commercial platforms ourselves, please do share this article wherever you can, if you liked it. It will help us grow, and spread the word. Links are right there. Have a click, or long-press/touch for you fancy folk.