History of the Jamstack
Welcome to the Jamstack. This completely new web development paradigm has excited the information technology industry and is becoming steadily more popular, with new companies constantly forming around it. This book is one of the first of a few tutorials available focused on practical and hands-on experience with the Jamstack.
A technology stack represents a specific collection of languages, databases, and operating systems, such as the LAMP stack. The acronym LAMP stands for Linux, an operating system; Apache, a web server; MySQL, a database; and PHP, a programming language. The Jamstack is actually not a stack in this sense, but rather a new methodology and toolset to produce websites and web applications.
In this chapter, we're going to first look at the history of the web, introduce the Jamstack, and discuss its advantages. To understand how the Jamstack evolved into what it is today, we need to look back at the more-than-two-decade history of the World Wide Web. Web design and web development, the two main industries that evolved from the World Wide Web, developed into two very popular and lucrative occupations, but it wasn't always that way.
These are the main topics that we will cover in this chapter:
- The evolution of the Jamstack
- The rise of the Jamstack
- Our Jamstack
- Getting started with the Jamstack
The evolution of the Jamstack
The evolution of the Jamstack can be easily explained by looking at how the World Wide Web evolved, starting with its most central component, HyperText Markup Language (HTML).
The very first web pages were simply comprised of text with HTML tags, providing markup instructions with the ability to link pages together. In fact, HTML is often mistaken by the average person as a programming language, but it was, at the most fundamental level, a series of symbols that represented formatting instructions. It still gets included in programming language lists, together with actual programming languages such as C and Java. It is merely a markup language, though, despite having evolved rapidly to now include accessibility and semantic features. This means that it is not much more than markup. In its earliest versions, however, it simply provided general formatting instructions.
For example, we could use an h1 tag to represent the header of a page, which would make the text appear larger, or a bold tag to make the text bold. Each page would consist of text, links, and HTML tags.
The following code snippet provides an example of this:
<html><head><title>My Webpage</title></head><body><h1>Welcome to my webpage.</h1></body><html>
As the number of web pages on websites grew, weekly—or even daily—tasks involved updating up to 50 pages manually. Every time a change was needed in a shared part of a web page (such as the header, footer, or navigation pane), these repeated actions proved to be quite tedious.
Let's investigate some solutions that were devised for this problem.
One attempt to remedy this repeated manual work was called a server-side include, or SSI. This markup element was created to allow web designers to include pieces of pages (for example, the header) without having to repeat content and markup. Then, when the page was generated, the tag would be replaced with the resultant HTML output.
For example, three links on a web page, Home, About Us, and Contact Us, would have the following markup:
<a href="home.html">Home</a><a href="about_us.html">About Us</a><a href="contact_us.html">Contact Us</a>
This HTML could be placed inside a file called navigation.ssi. The include would be called as follows:
<!--#include virtual="navigation.ssi" -->
After the web server processed this, the result shown on the page would be the same as that shown in the preceding example. Next, another similar approach was used to allow for dynamic content to be produced.
The Common Gateway Interface
The Common Gateway Interface or CGI, allowed programs written in languages such as Perl to be included in a web page, providing added functionality such as a page counter. The actual place in the HTML page that called this code would again be replaced with the resulting HTML output.
A Perl script that counted the number of page visitors was placed into the cgi-bin directory and called as follows:
<p>This page has been visited<!--#exec cgi="/cgi-bin/counter.pl"--> times.</p>
This would produce the following result on the web page:
<p>This page has been visited 5349 times.</p>
The number 5349 was produced by this code and displayed on the page.
Another important part of the history of web development was forms. Forms allowed a simple web page to transform itself into an actual web application. Web forms replicated the functionality of traditional forms found in desktop applications. Web forms also enabled end users, as opposed to the webmaster, to add content—for example, in forums, submission forms were used.
On the public-facing portion of a website, submissions from these forms added even more content as websites grew quickly in size. Sites soon effectively became software applications, more than just a collection of files with markup. Soon, more than just serving simple pages, web server modules were created to preprocess entire pages as programs.
Web page preprocessors
Another interesting part of the evolution of modern web development was the ability to use whole page preprocessors, such as PHP. In fact, this language, recursively called PHP: Hypertext Preprocessor, explains exactly what it does. These files had a different file extension, and the web server (such as Apache) could process the entire page as an actual program and output the result as HTML tags and content.
Next, let's move into the modern era: Content Management Systems (CMS).
Content Management Systems
Soon, databases such as MySQL were included in affordable web hosting plans so that webmasters could easily use them. Database tables could be queried, and the results would enrich and add meaning to many dynamically generated pages. This laid the groundwork for the first CMS.
By allowing website administrators and webmasters, as they were historically called, to manage content in databases, dashboards or control panels were created. A web-based software application entirely separate from the actual website, these administration tools allowed website content to be easily created, edited, and deleted from the website itself.
Again, this caused websites to grow both in size and complexity very rapidly.
WordPress quickly rose as the most widely used CMS. Extending the functionality of WordPress, a collection of plugins was developed whereby anybody could develop and install a plugin. This meant that at any one time, a WordPress website could potentially have hundreds of different plugins installed all at the same time.
Most of these were maintained by ambitious volunteers, and new functionality was quickly added. This phenomenon led to rapid release cycles and many different versions of each plugin in use at the same time.
The rise of the cloud
As the web grew in popularity, web hosting costs decreased. The availability of very low-cost web hosting increased rapidly as many companies entered into the market. Website hosting companies and cloud providers saw an opportunity in this, putting the ability to create a website within reach of almost anybody with very little technical skill, at a very low cost.
As history would show, as with the automobile, sometimes the best inventions also foster many problems. Just as the invention and evolution of the automobile has led to crashes, traffic jams, and safety and security issues—so did websites! Since the majority of websites on the internet were created by amateurs and hosted on servers that were not adequately secured, vulnerabilities on the server were soon discovered and then taken advantage of.
However, the overhead of having to make sure that all of a website's plugins were up to date soon became overwhelming. Situations such as version 3.12.26 of a particular plugin not working with version 6.8.14 of another became commonplace. The web slowly became the Wild West!
Also, the pages required multiple steps to actually be dynamically generated. Live-running code and database queries needed to be interpreted on each and every request. Page time slowed down because of all of the steps needed to deliver a single web page. As history has shown, a new solution will always arise to address new problems. This solution is called the Jamstack.
Let's begin to dissect what it is.
The rise of the Jamstack
The Jamstack represents all that was good about the initial days of web design, together with all of the things that are good about modern web development. Static site generation, as it's sometimes referred to, means simply generating a website comprised of pages that are literally files and nothing more. There is no backend preprocessor and no database, and all of the server complexity is abstracted away.
The Jamstack acronym explained
Finally, Markup represents the page itself. As mentioned, HTML is a language that it used to create web pages. Sometimes, Markdown is incorrectly used in the place of Markup. Markdown is actually one of the notations used to produce markup; however, there are many different ways to produce markup.
Now, let's learn about the advantages of the Jamstack.
As mentioned before, one of the advantages of static pages is that each page is actually a file on the filesystem. As in the early days of web design, each file is loaded through a web server. The only bottleneck is the speed of accessing the file, reading it, and then sending its contents through the web server.
A Content Delivery Network (CDN) is a network of many servers placed all over the world. This means that the pages will be optimally served from the nearest server to the website user, reducing network latency. This represents an overall faster and better experience for the end user.
Using the safe HyperText Transfer Protocol Secure (HTTPS) instead of the older HyperText Transfer Protocol (HTTP) means that all information transmitted will be secure, as it is encrypted from end to end.
Also, since static pages are served through serverless hosting services, there is no chance that any backend systems or databases could be compromised. No longer is there a need to spend valuable time keeping the server, libraries, login access, and mail services secure and always on the latest version, or even worrying about conflicts between the various versions.
As should be clear by now, the Jamstack is not a stack, but rather a web development paradigm. Any combination of the various components of the Jamstack ecosystem may be used. For this book, we will use three of the most popular software applications and services to produce a Jamstack website: GatsbyJS, Sanity.io, and Netlify. We will also provide several examples, using other Jamstack tools for comparison.
One of the most popular parts of the Jamstack that is actually a static site generator is GatsbyJS.
Since the Jamstack way of doing web development eschews a single, monolithic CMS, the actual content that a website needs is separate from the tools that will format it and deliver it.
Sanity.io (referred to as Sanity) is a platform for structured content. There is an open source CMS called Sanity Studio, which enables content producers such as writers, editors, and photographers to easily create rich content that is flexible and modular, without the need to understand programming and markup languages.
The actual hosting of the website will be done on a serverless system.
Netlify is a service that enables a developer to enjoy fully automated compilation and deployment onto Netlify's CDN, pushing content out quickly and safely to servers throughout the world.
Getting started with the Jamstack
Now that we have learned about the history of the Jamstack and its advantages, we will next look at the tools necessary to use the Jamstack in the context of this book.
Installing all of the pieces of a Jamstack development environment and configuring everything to work properly will be daunting for developers who are new to the technology, so the best approach is to refer to each of the components' websites for up-to-date installation and configuration documentation.
This book has an accompanying GitHub repository with all of the code necessary to perform all of the examples. Therefore, the first tool that needs to be installed will be the Git version control system. Users who are new to Git will find a vast amount of information, cheat sheets, and help forums for its usage, but most of the basic operations are performed with only four or five commands. Many code editors, such as WebStorm, have the commands built into the user interface.
To ensure that the installation process is up to date, the README.md file in the provided repository will provide installation instructions and links to each project's current documentation.
Several web development tools are necessary to work with the examples in this book, and these are listed here:
- Node.js and node package manager (npm)
- An Integrated Development Environment (IDE) or text editor
A Terminal environment will be needed to execute commands. Which Terminal application should be used will vary depending on the operating system used.
The Git command-line version control system is essential for the installation of Gatsby and also to download the examples in this book.
Finally, an IDE that provides code syntax highlighting and linting, which continually analyzes the code for correctness, is needed. If this is not possible, a text editor is needed to modify the source code files. As of this writing, Visual Studio Code and WebStorm are two popular IDE choices.
Optionally, Yarn may be used for the examples in this book. Yarn is an npm-compatible replacement for npm and while it is suggested, it is not required.
In this chapter, we learned about how the World Wide Web grew from simple pages with markup and links, to become massively slow and insecure web applications. We learned how the Jamstack combines various aspects of the past and present to form a truly modern, decoupled, and enjoyable paradigm to work with for web developers and web designers wishing to learn more.
In the next chapter, we'll begin our journey into the construction of a real, working Jamstack application. We'll become familiar with Sanity and a web-based tool to quickly create a sample application, using one of several templates.
We will introduce Sanity and its features and show how to modify its schemas. We will show how to use Sanity to design and build the structured content needed to create a website with news and events.