Static Websites are dead, long live Static Websites

With recent developments in cloud technologies and programming languages (such as Node, Go and Rust), we commemorate a new age of static websites. In this article, we shall bust some common misconceptions about static websites and we take a closer look at how a business can leverage from the growing ecosystem of tools and frameworks supporting the development of scalable, fast and secure static websites.

Static websites, a closer look…

The definition of a static website has been consistent over its history since the conception of the World Wide Web in 1990 by Tim Berners-Lee. A static website contains of web pages with static (non-changing) content. Each page is coded in the Hypertext Markup Language (HTML) and displays the same information to every visitor. Static websites are the most basic type of website and are the easiest to construct. Unlike a dynamic page, they do not require a backend or database design. Only infrastructure to host the static content is needed. A static site can thus be built by simply creating a few HTML pages and publishing them to a Web server / host. Static sites that contain a lot of pages such as blogs are often designed using templates. This makes it possible to update several pages at once, and also helps provide a consistent layout throughout the site.

Since static Web pages contain fixed code, the content of each page does not change unless it is manually updated. This works well for small websites, but it can make large sites with hundreds or thousands of pages difficult to maintain. Therefore, larger websites typically use dynamic pages, which can be kept up to date through the use of a database. Such websites dynamically generate the static content that you end up seeing in your browser by asking a database on a server for information. So every time you visit a dynamic website, it needs to “build” the static files before your browser can download them. When you visit a static website, on the other hand, you can skip that step entirely. The website has already been built, and your browser can immediately start the webpage.

Take for example the early days, before the WWW was born. Protocols such as the File Transfer Protocol (FTP) and the gopher were used to retrieve individual files from a server. It was nothing different from navigating in your local directory and choosing the files you want to open. Nothing had to be generated on the spot, you clicked on a file and it was downloaded at a couple kbps to your computer. It were exactly these unforgiving modem speeds that stimulated the adoption of static websites. Oracle however, did a fine job in hyping its databases and promoted the adoption of dynamic websites using them. Such database backed websites were often business class and very expensive as there were no cheap alternatives at first. For better or worse Java and PHP were regarded as the go-to language in order to construct a good dynamic webpage. From the very start PHP was rigged with operator madness and integer overflow, with arrays being the only data structure until the coming of age of PHP 4 . In general performance of dynamic websites dropped significantly (if they were working properly at all) in comparison with its static counterparts. PHP may now rest in peace, as the community is gradually moving on to more robust alternatives.

Arise, arise, writers of Javascript

Static websites were, in the beginning, quite boring. HTML webpages styled with CSS were no different from just a Microsoft Word document in terms of looks and feel. However Javascript gradually became faster and faster, and the exponential evolution of our processors and RAM gave rise to beefier browsers such as Firefox and Chrome. Eventually giving birth to browser multithreading which solved the biggest performance concerns. Other technologies such as Git, NoSQL and in-memory databases enabled programmers to step up their game. A common misconception that dwells in the mind of those who build dynamic websites is that Javascript is a dynamic website perk. Javascript adds dynamic things onto something which can be in itself static. In fact using Javascript does not mean your website is suddenly dynamic, as it is just another file which gets downloaded and interpreted by the browser. When Javascript is used in this way we call it client side processing. Static website developers can therefore add cool things to their otherwise uncool website. In recent years, Node.js (which is often confused with Javascript itself) is often used as a non-browser runtime engine. This means that it can be used to run code in a virtual machine or container, without the need of a browser. Node took over the server-side processing which originally fell in the domain of PHP and Java. In fact Javascript has become the de-facto standard in building dynamic websites and static websites alike. There is a distinct similarity between the two which translates into the term isomorphic application. We will discuss this in a future article. For now we shall focus on a new challenge which was the arrival of mobile phones. Just like the modems of the early internet, mobile phones restrict the CPU capacity and therefore impose stricter performance requirements. For many customers of online shopping it often comes down to the very few seconds in which a certain page loads. The all-round browsing experience of such a website on their mobile phone may lead to an increase in profits. We can observe the crossing point in 2017 on the chart below. This clearly marks a new era of static website development.

The admirable attributes of a static webpage

Dynamic websites cannot always be replaced by their static counterparts. But in 80% of the cases they can, and so they should. Why is that exactly? Because static websites offer a wide range of benefits one might favour:

Lower (development) costs: A static website can simply be written in a (colourful) text editor, hot-reloaded in a browser and deployed on a Content Delivery Network or simple Blob storage. The only thing you need is a domain. And the grand total of these tools and services will cost you almost nothing.

Reliability: Since HTML on itself is pretty reliable, and does a good job in masking Javascript errors. You are certain that your visitors will see the same as what your own browser shows you. There is no “server” which can be prone to failure and thus bring your site down.

Horizontal Scalability: A CDN or Cloud Storage takes care of handling the load for you.

Performance: Since nothing needs to be generated on the server side, static websites offer superior performance and are on average 10x faster then PHP alternatives.

Less Maintenance: There is no running code that needs to be monitored. New pages can easily be added just by writing them in your local website directory and uploaded afterwards.

GitOps: Git opens up a whole new way of keeping our content up to date, while maintaining a history of edits. Sites like Github can even be regarded as a low-level CMS where you can alter the website through an online text editor.

Welcoming a new era

How can the sudden interest in static websites be explained? The growing ecosystem of static website generators plays a significant role in the adoption of a static website. Combine this with a headless CMS, and a serverless API and you suddenly obtain a flexible toolset which offers you a way to build a scalable, performant, secure, cost-effective and easily maintained static website with dynamic features. With the arrival of Rust and Go, these generators became so efficient they could parse very large quantities of webpages.

A headless CMS is any type of content management system where the content repository “body” is separated or decoupled from the presentation layer head. The content is served through a (GraphQL) API and feeds content to the static website. Templates are built with a static website generator which generates a (themed) representional layer. A headless CMS which functions as WYSIWYG editor for your articles together with a themed static website which displays your published content enables even non-technical employees to add content to your website/blog. A CMS can vary in easy of use, but there are many options out there. The combination of Javascript with Markup and API’s is what is called the JAMStack. As a software engineer I support its design philosophy and I use it for this blog and in many other projects. For a more detailed overview of the JAMStack you can visit the following website: https://jamstack.wtf/. With the JAMStack as a hammer, a lot of your website concerns will look like nails. Whether it is a commercial website, a blog, a campaign (funding) website or the landing page of your startup.

When your business is in need of a JAMStack, feel free to consult me by sending a PM on LinkedIn.