In the direction of a Light-weight Jamstack


Be aware: this text is an edited transcript of my speak of the identical identify on the Jamstack Berlin meetup. You possibly can watch the video here.

Jamstack is flourishing. There’s a plethora of languages, frameworks, libraries, and companies that permit you to take full benefit of static web sites whereas with the ability to leverage the JavaScript and Serverless ecosystems to construct wealthy, dynamic, and kooky experiences.

This usually comes at a price—as most Jamstack frameworks are primarily based on JavaScript frameworks (NextJS and Gatsby on React, NuxtJS, and Gridsome on Vue), the JavaScript tax takes a toll on efficiency, and, finally, in your customers.

This text goals to provide instructions to curb that JS tax—whether or not by optimizing your present JavaScript-framework-based web site or by going for another: Eleventy.

However first, let’s make a journey down reminiscence lane to know how we bought the place we’re immediately.

From Jekyll to Gatsby

The Static/Jamstack ecosystem has advanced lots over the previous decade. This evolution has had a deep affect on the way in which we conceive web sites and on the way in which our customers expertise them.

We’re going to cowl three main steps by that journey from the (fictional) standpoint of an informal dialogue between a server and a consumer.

Our consumer will try to entry a web site, and our server will give her what she must view and work together with it. These two vital steps (the consumer can see the content material, the consumer can work together with it) might be denoted with related pink badges, highlighting the second within the dialog once they develop into attainable.

Buckle up! We’re going all the way in which again to 2008.

Pure Static (e.g. Jekyll)

Jekyll, created in 2008, has lengthy been the preferred Static Website Generator. Following the “bake, don’t fry” adage, it pre-computed all of the pages of the web site to have them available for its guests.

A discussion goes like this. User: “hey could you pass me that index.html file you got there?”. Server: “sure thing here you go”. User: “thanks”

It’s simple. Easy. No shenanigans. The specified web page is served instantly to the consumer, and it’s instantly accessible to view and work together with. Ought to she navigate to a different web page, her browser would fetch it in the identical means it did the primary.

As years glided by, nonetheless, the consumer expertise this answer offered someway lagged behind what customers bought used to with cellular purposes. Transitions, offline-mode, all of the bells and whistles of the cellular revolution have been nowhere to be discovered.

JavaScript frameworks, Angular, React and Vue amongst them, supplied a brand new proposition that was to deliver native-like experiences to the online, bringing us to our subsequent cease: Shopper-Aspect Rendered web sites.

Shopper-Aspect Rendering (e.g. React, Vue)

To make web sites really feel native-like, the answer supplied by new JavaScript frameworks circa 2015 was to embed a JS-based engine that will create and replace the HTML markup and related types dynamically. The upfront value to obtain, parse, and execute that engine would supposedly be offset by sooner subsequent navigation and a richer consumer expertise.

Discussion goes like this. User: “oooh this new online publication looks cool can i see it?”. Server: “you know what why don’t you take all the raw materials and figure it out yourself”. User: “ wow rude but ok”. User computes the page for a moment. User: “ it works!”

The key shift that occurred with that evolution is that the price of constructing net pages handed from the server to the consumer’s browser. This price is indicated within the dialogue with the gear icon, throughout which the display screen is generally clean or displaying a loading indicator.

Because of this, the efficiency of Shopper-Aspect Rendered web sites rely extensively on the specs of the system of the consumer, as JavaScript is CPU-intensive. The next video, by Josh Comeau, exhibits a 28 seconds distinction (!) in load time for the Washington Publish between an iPhone and a $100 Xiaomi Redmi 8.

Server-Aspect Rendering (e.g. Subsequent.js, Nuxt.js)

A number of years after this paradigm was launched, these points lead the pendulum to swing again in direction of the server, with the introduction of Server-Aspect Rendering.

Server-Aspect Rendering was launched to repair one of the vital annoying facets of Shopper-Aspect Rendering: that the content material the consumer got here for wouldn’t be seen till after the (normally giant) JavaScript code is downloaded, parsed, and executed. These seconds might be the difference between the visitor staying or leaving the website.

Frameworks like Subsequent.js and Nuxt.js appeared to try to deliver the server again to its unique position: constructing net pages. The method could be completely different from Jekyll’s, although: within the Server-Aspect Rendering paradigm, the server acts as an online browser and renders the web page utilizing JavaScript—not Ruby.

Discussion goes like this. User: “i heard they worked on performance on this publication”. Server: “they did! here it is: i’m building the page very quicky…”. Server computes the page for a moment. Server: “and now send you the raw materials to build it yourself BUT now you have a nice picture of the finished page to look at meanwhile!”. Server: “and now send you the raw materials to build it yourself BUT now you have a nice picture of the finished page to look at meanwhile!”. User: “sweet! i can see the content first…”. User computes the page for a moment. User: “and now click around!”

This method leverages the ability of the server to point out the content material to the customer instantly. Nonetheless, as interactivity nonetheless depends on client-side JavaScript, a delay is being launched between the availability of the content material and its readiness. From the standpoint of the customer, this could induce rage clicks: clicking on a button or a hyperlink has no impact for a number of seconds, as illustrated under.

An animated gif showing two pages loading (one resembling AirBnB, the other Amazon). The pages look like they are ready, and a fictional user clicks on them for around 20 seconds until it has an effect. The fictional user gets annoyed, then angry, then despaired at the situation.

Supply: Addy Osmany, The Cost Of JavaScript in 2018

There could be rather more to say on the subject, as a number of the frameworks have further optimizations (prerendering, link-prefetching…), however we already coated sufficient floor to know that JavaScript has an affect on the consumer expertise for Jamstack web sites. This affect has been dubbed the JavaScript tax.

Curbing the JavaScript tax

With out coming into into extra particulars, we are able to comply with the straightforward approximation that the much less JavaScript is used, the decrease the tax might be. Transport much less JavaScript then turns into a robust method to reinforce the efficiency of our web sites.

What if we might take away it altogether?

Eradicating the JavaScript of JavaScript frameworks

Next.js and Gatsby are two common Server-Aspect Rendered JavaScript frameworks used on many Jamstack web sites. They each use React because the underlying JS library to handle state and UI.

For this part, I’ll take my personal blog for instance. I selected to construct it with Gatsby, as I wished to study extra about the way it labored and will leverage my React expertise to ship it shortly.

A screenshot of my personal blog

The Developer Expertise was a delight and I’m total fairly proud of it, however one thing felt off. My weblog is fairly primary: an index of all of the articles, a web page for every, and some different pages right here and there. But it was powered by the identical know-how that powers Fb, AirBnB and plenty of different extraordinarily advanced web sites: React. Any overengineering questions put apart, I nonetheless required any reader to obtain, parse, and execute React for no advantages in any respect. There are not any good widgets or advanced UI to justify React. Solely textual content and pictures.

My (excellent) developer expertise had an affect on my reader’s consumer expertise. There is no such thing as trickle-down UX.

Nicely, it seems that there is a option to get the very best of each worlds. If, like my weblog, your Gatsby web site doesn’t require React (or another JavaScript) to run, you may disable it. The Gatsby Plugin No Javascript neighborhood plugin will allow you to benefit from the DX of Gatsby with out taking a toll on consumer expertise. A similar (experimental) plugin additionally exists for Subsequent.js.

In fact, not each web site is so simple as my weblog—that will be fairly boring. Quite a lot of Gatsby and Subsequent.js web sites on the market depend on React for his or her consumer expertise: fairly animations, purchasing carts, e-newsletter sign-ups, and the likes. Is there one thing we are able to do on these web sites to make them lighter?


When React is required for a web site to run correctly, we are able to’t simply do away with JavaScript. What we are able to do, nonetheless, is search for methods to cut back its footprint.

Preact is a substitute for React that has the identical performance, the identical fashionable API, for a tenth of its dimension. The Preact staff managed to drastically cut back the footprint by dropping assist for some previous browsers and legacy React APIs.

Though there are some slight variations (see the list), Preact can be utilized as an alternative of React for a lot of web sites with none affect on the end-user, and barely any on the builders.

We switched from React to Preact on the Orbit app with out points and shaved off half of our JavaScript footprint within the course of. If you happen to’d wish to strive, there are plugins for Gatsby and Next.js, and a guide for switching manually.

Now, say you might be in a state of affairs the place you must create a model new web site. You wish to use the Jamstack since you’re satisfied of the advantages. You wish to be conscious of the consumer expertise, additionally since you’re satisfied of the advantages. Say the web site you wish to create is much like this very one,

What would you select for a Light-weight Jamstack? What did I select for a Light-weight Jamstack?

Constructing with Tailwind, Eleventy, and Alpine.js

The Orbit web site doesn’t have a posh UI—interactivity is proscribed to a cellular nav menu, modals, and sign-ups for our e-newsletter and early entry. I knew from the get-go that reaching out to (P)react could be heavy handed, so I seemed for light-weight options.

I went for the next: TailwindCSS, for styling, Eleventy, for the static website era, and Alpine.js, for interactivity.

Eleventy is a JavaScript-based Static Website Generator that, regardless of being written in JavaScript, shares much more with Jekyll than with Gatsby. Certainly, Eleventy (also called 11ty) doesn’t ship any JavaScript by default. You’re free so as to add any, after all, however it doesn’t power you to make use of any library or framework.

Not having to make use of a JavaScript framework additionally meant that HTML, not JSX or Vue elements, is now entrance and middle within the code you write. This helped me keep away from the same old traps when writing React: the notorious div soup, inaccessible elements, or non-semantic tags.

TailwindCSS is a utility-first CSS framework, which signifies that as an alternative of writing CSS in your elements (class=”navbar__mobile”), you mix utility lessons that every do one particular factor (class=”flex flex-row justify-center w-full”).

I discover this method extremely productive when you study the grammar, and it makes for a resilient CSS structure on the admitted price of some duplication in your code. What makes it an awesome match with Eleventy is that you just not often, if ever, depart your HTML elements when writing code. It helps me concentrate on the duty at hand by avoiding context-switching.

Now, though my focus was on limiting the affect of JavaScript, it was nonetheless required to drive some elements of the web site: the cellular menu, modals and e-newsletter sign-ups.

Alpine.js appeared like a superb compromise to full-blown JavaScript frameworks. Alpine’s premise is that it augments, relatively than takes over, the HTML markup. Utilizing a syntax impressed by Vue, it may be “sprinkled” in your markup on the locations that want interactivity, leaving the remaining intact. In comparison with React (42kB minified and Gzipped), and Vue (29kB), Alpine solely weighs 8kB, successfully curbing the JavaScript tax.

The Teastack, a light-weight Jamstack

If Jamstack (JavaScript–API–Markup stack) ushered in an period of breakfast-related acronyms, I want to counsel a brand new one. The Teastack (Tailwind–Eleventy–Alpine stack) presents an incredible developer expertise, selling HTML markup again to its central place in builders’ minds, whereas being conscious of consumer expertise and net efficiency.

As Nicolas Hoizey wrote, Jamstack is fast only if you make it so. Going in direction of a light-weight Jamstack seems like a superb step in that path.

If you happen to’re inquisitive about real-world utilization of the Teastack, this very website is open source. Be happy to take a look on the code, and to achieve out on Twitter (@phacks) to begin the dialog!

Article supply :=> Read More


Please enter your comment!
Please enter your name here