JavaScript, APIs and Markup – InApps Technology 2022

The JAMstack approach to web development has been emerging for several years, but really took off in 2017. More a design philosophy than an explicit framework, JAMstack takes the concept of static, database-free websites to the next level via an architecture advocates are calling “the future of the internet.”

Which only makes sense. Browsers themselves have essentially become mini operating systems capable of running complex client-side applications while interacting with myriad APIs. Meanwhile, with the help of with Node.js and npm, JavaScript has leaped the divide between front and back end for real-time, two-way communication between client and server. JAMstack is simply harnessing these factors in a logical and effective way.

(A word on static vs. dynamic site architecture: static in this context refers to how websites are built, powered and served, which in no way means that a static site lacks interactivity.)

What JAMstack Is

The term itself was coined by Netlify co-founder Mathias Biilmann to refer to the solution stack of JavaScript, APIs, and markup. JAMstack focuses on the front end build, eschewing server-side functions as much as possible. The three elements are:

• JavaScript: JAMstack JS resides on the client-side, handling responses and requests. Because this approach involves a style of build over specific technologies, the “J” in JAMstck can take many forms: pure JavaScript, a library like Vue.js, or even front-end frameworks like React.
• APIs: Server-side processes and database commands are implemented vis API, which is accessed by JS-driven HTTP calls. JAMstack is API agnostic in that it simply does not care where yours comes from. You can use any of the bazillion pre-packaged APIs out there or custom-build your own.
• Markup: This is the part users actually see when they access your site or app. These days there are all kinds of open source build tools (Grunt, Webpack, Gulp) — not to mention static site generators (Jekyll, Spike, Hugo) aggregating them into convenient platforms — to make creating templated markup stupid easy.

Once you’ve actually built that JAMstack-based opus, you, of course, want to place it at the very front edge of the internet event horizon. There are fantastic git-centric hosting services that allow continuous deployment — meaning that you can simply push your app, and any subsequent changes, to GitHub, and the service will automatically build the site from source and deploy it. This is essentially how GitHub Pages works. And, since JAMstack architecture also couples beautifully with high-availability, high-performance nature of content delivery network distribution, be sure to shop for a provider that gives good CDN.

I happen to be a huge fan of Netlify because it’s open source, supports pretty much every static site generator out there, and offers a wicked fast global CDN. And all for free, for small individual projects, with paid plans for enterprise users.

How JAMstack Works

It is easy to forget about the sheer number of steps required to render a typical dynamic website and the complexity of the server-side operations required to present the final version in the user’s browser. A common example of how this works on the vast majority of the current web: you request a page. Your server queries a database, which uses an interpreter — combined with data from the page’s markup and plugins — to knit together and serve up a fresh new HTML document to your browser. For example, LAMPstack — the popular open source stack commonly used to build dynamic websites — includes Linux, Apache, MySQL/MongoDB, and PHP/Python/Perl. Under this setup, pages are reconstructed from a database on request; nearly all the work is done on the server side, and you have to wait for that work to be done.

First off, the absence of a database makes a static site incredibly secure.

JAMstack essentially subverts this entire paradigm. All the browser work is done upfront and offline: the browser markup is generated using SSGs, and then pushed to Git as a collection of pre-built pages. Instead of running on the server and generating content anew for each call, JAMstack pages run locally as part of the development process. Then, when a user requests content, the HTML — now a collection of easily-cached static files — is sent to the browser with no further processing required.

A core principle of the JAMstack development approach is that everything lives in a Git repository. EVERYTHING: all your site’s components, generator config files, CSS and JavaScript as well as content. Once pushed to GitHub, the entire website resides in one centralized location protected by robust version control — which opens the door for gloriously easy continuous deployment.

What JAMstack Can Do for You

The vast majority of sites on the net today total fewer than a dozen pages and do not require frequent updating. For these sites, the JAMstack approach has major advantages over the traditional dynamic application server model: it’s faster, cheaper, easier to build and maintain, and offers baked-in security.

• Faster Performance: JAMstack involves very little server-side work: there’s no need to query a database, and the code has already been compiled. Every user gets the same page. (If you need dynamic elements, those too get handled client-side through third-party tools like Disqus). All of which means pages can be returned up to six times faster.
• Vastly Simplified Updating: Since everything from JavaScript to markdown is stored in a git repository, it’s dead easy to set up continuous deployment so your site is updated every time new content gets pushed.
• Built-in Reliability and User Scalability: On a CDN, with the load distributed across the entire network, if there is a sudden unexpected user surge (like when your app goes viral!) or a partial network fail, the CDN seamlessly compensates.
• Greater Security: First off, the absence of a database makes a static site incredibly secure — practically a fortress, even. For example, it’s immune to SQL injection; also, fewer server interactions equal fewer targets for malicious hijacks. And, since by design JAMstack greatly cuts the number of moving parts involved in project development, devs can much more easily catch and fix any potential vulnerabilities that do arise.
• Less Cost: We know why you’re really here: the overall expense of building, maintaining, and deploying a JAMstack site is lower. Thanks to keeping the focus on the front end, the development team can be smaller and swifter. With no database required, fewer servers are needed and hosting is also drastically cheaper.

What JAMstack Can’t Do for You (Yet)

All great stuff! That said, however, JAMstack is not the one stack to rule them all. There are all kinds of scenarios that are simply not suited to this approach, though the rapidly developing open source community around this model is busily addressing pretty much every one of these issues.

• Complexity conundrum: JAMstack scales beautifully in terms of users, but not so much in terms of project size and/or complexity. This approach, unfortunately, just does not work for projects with lots of interactive features, or that require real-time updates and/or frequent new pages.
• A steep learning curve for non-techies: There is a reason why WordPress powers such a vast proportion of the net, despite its bloat: it’s easy and intuitive to use. Your average content provider, however, is likely to be flummoxed (“I have to write in markdown just to write a blog post, whuuut?”). Also, since said content resides in the same repo as the code, it’s probably safer for developers to make the updates. Which inevitably adds to the developer’s workload, post-launch, no matter how much JAMstack was able to accelerate the initial build and deploy.
• Dynamic features require client-side add-ons. You want a log-in or a paywall? Comment section, forum, or polling? Retail sales storefront? All of these types of dynamic features are possible through third-party solutions (Livefyre, Disqus, lunr for search, etc). Cool to not need to write these ourselves, but it can also get cumbersome and start to defeat the whole purpose of going JAMstack in the first place. It sincerely pains me to say this, but if there’s a huge amount of dynamic content and features involved, you’re probably better off with WordPress — at least for now.

JAMming Forward

Things are evolving very quickly in the JAMstackiverse. The exploding popularity of static site architecture is giving rise to terrific new solutions and services, even for those who once upon a time would have automatically embraced the homey comforts of WordPress. For example:

• eCommerce: For small retailers, anyway, a static JAMstack delivered site is now totally an option. There are now JavaScript driven shopping cart and checkout services (like Snipcart and Foxycart) that bolt on seamlessly and provide API integration with inventory management, shipping and invoicing systems.
• Theme work: There are now all kinds of pre-built themes for static generator-created sites. Hugo and Hexo both have sweet directories of gorgeous, static-friendly themes, minus the pointless plugins.

The possibilities are expanding literally every day. As the ecosystem surrounding JAMstack web development proliferates, particularly among open source solution providers, there has never been a better time to try ditching the database and giving content delivery network-driven static development a try!

Feature image by Jonathan Pielmayer from Unsplash.

InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Spike.