JamStack refers to a static website without using the word static. “Static Website” is often used to explain a simple website with little to no interactivity.
Mathias Biillman and Christen Bach (the Netlify founders) coined the term “JamStack.” The Jam in JamStack stands for JavaScript, APIs, and Markup. This name went against the established naming trend.
It is customary to name the technology stack after the individual technologies involved. This new naming scheme implied a type of transcendence over other established techniques.
What came before the JamStack? ¶
The JamStack has had a long history. This way of creating websites is a call-back to the early days of the Internet.
In 1995, free web hosts were everywhere. They allowed ordinary people to have a small space to call their own online. One of the largest free web hosts was Geocities.
It allowed people to create HTML pages and upload them to the server for the world to see. These websites were all hand-coded and had very little interactivity.
JavaScript was in its infancy, and CSS was almost non-existent. These were the original static websites, and this is where the term became a dirty word.
People created websites with little to no technical skill, and it showed. The websites often had loud colour schemes, bad typography, and low professional quality.
In 1999 all that changed with Internet Explorer 5. Microsoft added a module that changed the way the web worked.
The XmlHttpRequest module. It was an ActiveX module that allowed a webpage to request data from other domains.
People started using this to begin experimenting with new ways to deliver content. They would create basic static web applications that used data from many sources. They would then show them on the screen in a visual way.
Websites like Mashable sprung up. They started reporting on these trends that helped fuel the growth.
Released on February 25, 2005, Google Maps allowed mashups to enter the world of GIS. Google Maps didn’t need an exact address to work. People could use the map to display data at a country, province/state, city and even a street address.
The number of mashups using Google Maps alone numbered in the hundreds. The new focus on data ended the Web 1.0 era, and we entered the golden age of Web 2.0.
Shortly after we declared this golden age, the web started to stagnate.
A short-lived dark age of the Internet started not long after. The browser wars heated up, and Internet Explorer 6 dominated the landscape.
Web standards became almost non-existent because browser vendors couldn’t agree.
Internet Explorer was finally upset by Google’s Chrome. The World Wide Web had fractured. It was common for websites to only work with some browsers.
With all browser vendors only having a small share of the web surfers, they had to cooperate.
The W3C was relevant again, and the ECMA loosened its grip on JavaScript.
Browser vendors formed the WHATWG in an attempt to reunite. The renaissance of web-applications was born.
The rallying cry for this new world standard was the Service Worker. It allowed offline caching to cache any static data that came across the wire at least once.
The engineers at Google came up with a new way of delivering these apps, the App Shell. It is a static set of resources (HTML, CSS, and JavaScript).
The static nature enabled the application to load fast. It then made JavaScript fetch calls to bring in the dynamic data it needed to operate.
It was a throw-back to the original mashup days of Web 2.0, and developers everywhere embraced it. Static websites were back under the new banner Progressive Web Apps.
Netlify was trying to differentiate itself from the competition. It wanted to remove the negative connotation from static websites.
The two founders Mathias Biillman and Christen Bach coined a new term; the “JamStack” was born.
The naming was similar to how other stacks were named: LAMP (Linux, Apache, MySql, PHP), MEAN (Mongo, Express.js, AngularJs, Node.js), etc… But it didn’t name the underlying technologies in use.
Instead, it took a much more abstract approach and used the basic concepts. JavaScript, APIs, and Markup; that was the new stack.
It was like the web of past years but looked forward. The web applications needed to be static assets.
Because of this, they could use web storage and remove the need for a web server. Because of the static nature of the web applications, Web APIs and cloud functions did the work of a server.
How does the JamStack work in practice? ¶
The JamStack, as a concept, is not complicated. Setting up a basic JamStack service on any of the public cloud providers is easy and cheap.
There are three parts: a DNS service, a web storage container (bucket), and a CDN deployment. Cloud functions can also provide a way to interact with other backend services.
Are there alternatives to setting up JamStack hosting myself? ¶
If setting up the proper cloud infrastructure seems too daunting, you are not alone. There are some static website hosts that you may consider.
In the last few years, quite a few have popped up.
Github Pages ¶
Github Pages is a free static website host that you can use with your Github repositories. You need to create a branch named “gh-pages” and push to it. Then all the content will become available on a unique repository URL.
The setup is easy if you are familiar with git, and you can get running in very little time. Github pages do have some severe limitations, though.
They may not be suitable for larger projects. Github pages may also not be the best solution if your website is not about a software product.
Gitlab Pages ¶
Gitlab Pages is a service that is like Github pages.
It is harder to set up because it does support more features.
It is a good alternative for a small static website. Gitlab pages have built-in support for build-pipelines to create HTML, CSS, and JavaScript.
Netlify ¶
Netlify is the originator of the JamStack term and a competent static website host.
It provides many services, such as functions, form submissions, and identity. The free tier is very generous and enables medium-sized websites to operate at little to no cost.
Also, I would like to add that Netlify is the host of this website.
Do I have to hand-code a JamStack website? ¶
Although you can hand-code a JamStack website, it is not necessary.
There are a lot of tools out there that make creating static websites much more accessible.
Static-Site Generators (SSGs) enable you to create a website with full templating support. These tools run when deploying the site.
They use the data and templates to generate HTML, CSS, and JavaScript.
Jekyll ¶
Jekyll was one of the first static-site generators. One of Github’s co-founders created Jekyll for their Github Pages platform.
Jekyll uses the Ruby language. If you are not familiar with Ruby, then it may have a steep learning curve.
Hugo ¶
Hugo is another well known static-site generator. It is famous for being fast and written in Go.
If you have a lot of files to generate, this may be the way to go. It does have its hiccups since it uses Go.
It tends to try and build everything in, so the usage of Sass and other ported modules may be a bit awkward.
Eleventy ¶
Another static-site generator that is gaining traction is Eleventy. Eleventy is my personal choice, and I used it to create this website.
It has all the features of a static website generator but built-in JavaScript. That saves me a lot of time and effort, trying to learn a new language.
It also lets me use JavaScript libraries in both production and the build process.
What are the main benefits of the JamStack? ¶
The main benefits of the JamStack are two-fold.
First, there are security implications. A static website doesn’t need a full web server to run, but only a minimal setup to serve out static files. The smallest installation reduces the surface an attacker has to try and find a weakness.
Scripting modules are the most likely places for vulnerabilities. Regular static file serving is generally considered a mature and safe task.
The second and most natural point to rationalize is the meagre cost of running a static site. Most websites would only cost about $2-$4 per month if they had about a million visits in a month. Less than keeping a server up and running 24/7.
We still haven’t included the other servers in the case of a spike in usage. High demand is something that static websites can tolerate. Files go from the filesystem to the network.
The third benefit can be challenging to achieve with a dynamic website. Static websites often find performance concerns trivial.
Caching the needed files on the edge CDN Network can reduce load times. Almost guarantee near-infinite uptimes and Failover. If one edge node goes down, then we use the next closest instead.
What are some drawbacks of the JamStack? ¶
Like anything else in life, there are always trade-offs to consider.
The JamStack relies on the pre-compilation of resources. It trades processing power for storage.
In some scenarios, this may be a limiting factor. For instance, if you are on a private cloud with limited resources.
JamStack websites use a more complex logical architecture. Simplifying the physical architecture means that the software must be more complicated.
Some may not like the reliance on third-party software. But it seems like a natural evolution to the single responsibility principle.
People who have worked with micro-services should feel at home in this environment.
Many people will be ill-prepared the first time they encounter this last drawback.
JamStack websites rely on many APIs and third-party services. One of those services may go down and make only a part of the web application inaccessible.
The inconsistencies in the outages can be frustrating, but the code will need to handle them.
Feature detection for both browser features and website features is a necessity.
Conclusion ¶
First coined in 2015, JamStack the term is new, but the concepts are as old as the Internet itself.
The JamStack reminds us of where the Internet came from and guides us on where we should be going.
The JamStack can lead to lowered costs, excellent security and unparalleled network resiliency.