JAMStack Everything You Need for Lightning Fast, Highly Secure Websites

There’s a new kid on the block and he’s growing up fast while quickly gaining celebrity status. We’re not talking about blockchain technology, GraphQL or hybrid mobile applications – we can save those for another time. No, we’re talking about the JAMStack! Today we’ll be answering some specific questions you might have about JAMStack technology such as:

What is JAMStack?
How did JAMStack come to be?
What are the benefits of JAMStack?
What are the drawbacks of JAMStack?
Who is using JAMStack Technologies?
What are some popular JAMStack Platforms?

Let’s dive right in and take a look at what JAMStack is, why it’s different, the benefits and how you can leverage this emerging technology to enhance your digital presence.

What is JAMStack?

By definition JAMStack is an acronym for JavaScript, APIs and Markup Stack. But a more useful definition that clearly defines JAMStack would be:

Fast and secure sites and apps delivered by pre-rendering files and serving them directly from a CDN, removing the requirement to manage or run web servers.
jamstack.org

This paragraph says a lot, but might leave some people confused. After all, how do you serve a website or application without the complexity of managing a web server, server side languages, databases and server caching? Great question and at first this seems almost impossible, especially with how complex the requirements for websites and applications are these days. Before we get into it, we need to take a quick detour to revisit the short, but ever changing, history of the internet.

At it’s infancy the internet was used as a large encyclopedia, serving information through static web pages composed of mostly html/xhtml and mostly inline styling. Web browsers were not sophisticated and network speeds and bandwidth were not adequate for serving large web applications of today. User experience wasn’t even an afterthought, there was only one experience and every user experienced the same thing – a static web page full of mostly text and maybe a few images. As web browsers advanced, and stronger network opportunities became available to the masses, the internet evolved into a web 2.0.

Web 2.0 lead by dynamic server side scripting languages such as Java, PHP and C#, websites were able to offer more capabilities and features than the static sites of old. In parallel, web browsers made advancements in client side scripting languages such as CSS and JavaScript and the idea of User Experience was born. There were still limitations of sending massive data over the network, and web browsers (as well as web clients) were limited in their computational ability to processes and execute application logic. Most, if not all, application logic and computation was handled by the server and sent back to the browser in manageable packets. Meanwhile, Moore’s Law was in full effect and client devices evolved to bear the weight of more application logic and cost of modern web devices became affordable to almost anyone. It was quickly discovered that web browsers and clients had an advantage that traditional servers didn’t…the ability to “listen” for and take action on a user’s interaction with the website. After all, the clients were the gateway for users into the great, expansive abyss of what we consider to be the internet. Applications quickly adopted and began to transfer more and more application logic to the client. Meanwhile, asynchronous javascript and html (AJAX) transactions began to transpire behind the scenes between the web client and the server, allowing for a telecommunication mechanism in near “real time” between the browser and the server. Large, monolithic server applications were deconstructed to microservices and implementation of application programming interface (APIs) over a representational state transfer protocol (REST) blossomed.

Web 3.0 had arrived. With the capability of web clients to handle large amounts of application logic, a global network which could serve large amounts of data over the wire and the decomposition of server applications to microservices, new technologies arose. JavaScript, which previously was known as utility language, quickly evolved into front-end, client frameworks such as Angular, React and Vue.js. Engineers started rethinking website delivery methods. Could we package all the application logic into minified, “static” files on the server and distribute those to the client to unpackage? Could we deliver a full application experience in the browser, while relying on REST communication between the client and APIs microservices in the background? Yes and Yes! Welcome in JAMStack technology! Today, deep into the Web 3.0 we discover how emerging technologies such as the JAMStack can allow new capabilities for developers and internet users alike producing a more meaningful web experience.

How Did JAMStack Come To Be?

In a 2017 speech called “The Rise of the JAMStack”, the CEO of Netlify, Mathias Biilmann refered to the term describing it as “a modern development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup.” Biilmann and his company Netlify were leading the charge in JAMStack deployment software, creating a new kind of web server that would allow for developers to use static site generators (SSG) to deploy their websites/applications. He also described a number of additional benefits the JAMStack provides such as security, speed and user experience. Projects such as Hugo, Jekyll, Next.js and Nuxt.js emerged to support (and advance) the JAMStack philosophy. There was clearly a high demand from developers mainly because of the downfalls of the traditional web application stack such as LAMP (Linux, Apache, MySQL and PHP). Namely, CMS platforms that were built off of this stack such as WordPress, Drupal, Joomla and many other headful content management systems, exposed security vulnerabilities and slow load/processing time because of bloated frameworks and technical misuse. Yes, anyone could do a one click install for a WordPress website on a cheap hosting platform and install 20 plugins to “get the job” done, but did they fully understand the security and speed implications of the underlying technology stack? To make matters worse, hackers and webots took advantage of these vulnerabilities and ignorance by deploying an attack on any website using these underlying technologies. It could be argued that Web 2.0 advanced the internet but also made it less secure and problematic for internet users. The advent of the JAMStack addresses some of these issues, increasing performance, security and user experience in a Web 3.0 world.

The Jamstack is not about specific technologies. It’s a new way of building websites and apps that delivers better performance, higher security, lower cost of scaling, and a better developer experience.
jamstack.org

What Are the Benefits of JAMStack?

There are many benefits of the JAMStack that address the downfalls of the “traditional” LAMP/LEMP/MEAN stacks. Namely, improved security and deliverability leading to improved user experience. After all, what is your user’s experience of your site if they go on and it is hacked or if your site forces malware downloads on users’ computers? Not good I can tell you that! JAMStack websites, which rely on static site generators, are inherently secure. When a user requests a web page from a JAMStack site they are served a “static” HTML file which includes minified, obfuscated JavaScript and CSS, making it incredibly difficult for hackers to compromise. By removing parts of “the traditional stack” ie databases and server side code (or at least protecting them behind firewalls and security protocols) the “Stack” becomes a lot more secure. Reliance on fewer server software packages (at application run time) means less potential for attack, especially when compared to sites running on a traditional CMS.

According to WP White Security, “More than 70% of WordPress installations are vulnerable to hacker attacks.”
wpwhitesecurity.com

Besides security benefits, JAMStack allows for faster content delivery and greater distribution on cached network nodes that are “close” to your users. Because static site generators (SSGs) perform a lot of the legwork in making a website JAMStack compatible, websites can be distributed and cached over large networks. Moreover, SSGs provide production build commands which optimize application builds by minifying, tree-shaking, and optimizing asset size (such as inlining/compressing images/files) – lending to a performant, production ready application. SSG technologies were made specifically for this reason, and build tools such as Webpack, Gulp and pre/post processors are the underlying technologies that make this possible.

According to httparchive the average web page size in 2017 was 3 MB. This is a huge increase from the 1.6 MB average of 2014. It is predicted that the average page size will be 4 MB by 2019.
httparchive.org

As you can see the size of web pages is a growing issue. Yes, we have better network bandwith and delivery speed then we’ve historically had but we have to account for the billions of people coming online from all over the world that do not have high speed networks. Also, mobile networks are more limited than fiber optic and land line networks and charge users on a price per bandwidth model, increasing the importance of page size and payload across the network.

Netlify’s CEO, Biilmann tested a previous build of Smashing Magazine (which ran on WordPress at the time) against a SSG counterpart that he created and deployed on Netlify. Biilmann’s version loaded six times faster than the original!
medium.com

Page speed including round trip calls to the server and First Contentful Paint – The time when the first content piece from the DOM is rendered – is a growing metric in Search Engine Optimization. SEO is another intrinsic benefit of static site generators as the page size (and thus speed) is performant compared to traditional monolithic CMS frameworks. Google and other search engines also have the ability to measure user experience and accessibility of websites. Included in their ranking variables are answers to the questions: is your site slow? Can everyone access and navigate your site? Is the content accessible and legible? Are you providing a user experience that people are willing to come back to your site for? All of these UX metrics are being taken into consideration as a performance metric in your SEO ranking. Luckily, SSGs and JAMStack technologies have tools that solve a lot of these problems for us.

Infinite backups from the first line of code to the most recent deploy! Yes, you read that correct. Since JAMStack deployment utilizes version control (namely Git) your website development history is versioned all the way back to the first commit, meaning you have almost infinite backups of your website. As always, nothing is 100% secure, but I’d bank on my website backup through Github or Gitlab over any third party WordPress hosting or backup platform. Likewise, there is typically a development version of your repository on one or many local machines (be it yours or your developers) so you have decentralized backup storage inherent with JAMStack.

Not all that glitters is gold, and there are some inherent drawbacks of JAMStack that we need to consider as well.

What Are The Drawbacks of JAMStack?

No CMS? No database? No server logic? You might ask “What kind of website is this anyways?” And you bring up a valid question. It’s not that SSGs don’t use content management systems, they just separate the concerns of content publishing from website generation and front-end experience. Most SSGs hydrate the content at build time before the “static” files are served to the CDN. However, this typically leads to a workflow that content editors are not used to. In a traditional CMS content workflow you login to the backend, select your content type, produce your content and click “Publish” and the content is live. In an SSG workflow you typically have to access the backend of the CMS from a secure network or behind a firewall, create the content, publish the content and then rebuild your entire website before the content is live. Depending on the size of your site this could take anywhere from a couple seconds to 10+ minutes. And if you need to edit the content you have to go through the same steps. If you are only producing new content a couple times a week, this might not be such a big issue but if you are a large media producer that publishes multiple articles a day, this could really damper your workflow. Luckily, since APIs is an important acronym in the JAMStack definition, most SSGs have the ability to hydrate content on the client by making a RESTful API call to the content source before dynamic pages (such as blog articles) are rendered. This allows for “immediate” publication (if JavaScript is enabled on the client), meanwhile the SSG can queue the article for server side rendering (SSR) during the next build cycle (perhaps at 2 a.m. every night).

Another drawback of SSGs is that the technology typically requires a higher level of understanding of the development and deploy process than a traditional CMS. Since traditional CMSs have been around quite awhile (in the context of the internet), publishing tools, plugins and hosting/deployment strategy has been made available to the layman, extracting the complexities of website development. This is both good and bad. The “good” means more people can participate in owning their own little slice of the internet. “Bad” could be considered in the sense that with great power comes great responsibility. If more people are contributing to the big WWW (world wide web), while not understanding the technologies they are enforcing upon their users, they could just be building a WWW that is less secure, less performant and vulnerable. However, JAMStack technology has not advances in so far as to being as available and user centric as traditional CMSs, thus relying on developers who understand JAMStack process. This of course could come at more cost to the site producer/owner.

All in all, the pros of the JAMStack likely outweigh the drawbacks and as the technology advances more and more websites will move toward the trend of using JAMStack tech.

Who Is Using JAMStack Technologies?

As the popularity and apparent performance benefits of JAMStack garnish attention, companies all over the world are rapidly adopting the JAMStack approach. In fact, Netlify (which is just one of many JAMStack hosts) has on-boarded more than half a million online businesses, and are building and serving millions of web projects daily around the globe. Companies like Nike are deploying campaigns such as their “Just Do It!” campaign on the JAMStack platform. Other notable companies include the travel booking site hopper.com and the popular flamingo razor are featuring some of the true capabilities of the JAMStack. Others to note:

There are many other websites (and more coming online each day) that rely on the JAMStack model and that number is expected to rapidly increase as companies realize the benefits gained moving to a static site generator platform.

What are some popular JAMStack Platforms?

There are many static site generators, single page app (SPA) platforms, and server side render (SSR) technologies that bode well for JAMStack deployment. With all of these acronyms it can get confusing as to what is the best technology of choice when it comes to JAMStack. Although I do not have the answer for you (as all project requirements are different an thus require different technologies), I can offer some popular frameworks used in the JAMStack ecosystem. There’s a flavor of SSGs (static site generators) and SSR (server side rendered) frameworks for all flavors and languages but here are some popular, proven platforms that you can use in your JAMStack workflow.

Hugo

Hugo is one of the most popular open-source static site generators written in Go (aka Golang). With its amazing speed and flexibility, Hugo makes building websites fun again.
https://gohugo.io/

Gatsby

Gatsby is a free and open source framework based on React that helps developers build blazing fast websites and apps.
https://www.gatsbyjs.org/

Nuxt JS

The Progressive Vue.js Framework. Build your next Vue.js application with confidence using NuxtJS. An open source framework making web development simple and powerful.
https://nuxtjs.org/

Jekyll

Jekyll is a static site generator. You give it text written in your favorite markup language and it uses layouts to create a static website. Jekyll depends on Ruby.
https://jekyllrb.com/

Next JS

With Next.js, server rendering React applications has never been easier, no matter where your data is coming from. Optimized for a smaller build size, faster dev compilation and dozens of other improvements.
https://nextjs.org/

Gridsome

Gridsome is a free & open source Vue.js-powered framework for building websites & apps that are fast by default.
https://gridsome.org/

We’ve explored what the JAMStack is, how it came to be, we weighed the pros and cons and took a look at some companies and platforms that are utilizing this emerging technology. We compared how JAMStack technologies stack up against the traditional CMS model and discussed some barriers to entry when using the JAMStack. Hopefully after this article you are inspired to learn more and are excited to take your stack to JavaScript, APIs and Markup! Until next time, stay curious, stay creative!