Towards a Lightweight Jamstack
For it to be fast, Jamstack needs to be lightweight.
November 9, 2020
Note: this article is an edited transcript of my talk of the same name at the Jamstack Berlin meetup. You can watch the video here.
But first, let’s take a trip down memory lane to understand how we got where we are today.
From Jekyll to Gatsby
The Static/Jamstack ecosystem has evolved a lot over the past decade. This evolution has had a deep impact on the way we conceive websites and on the way our users experience them.
We’re going to cover three major steps through that journey from the (fictional) point of view of a casual discussion between a server and a user.
Our user will try and access a website, and our server will give her what she needs to view and interact with it. Those two important steps (the user can see the content, the user can interact with it) will be denoted with associated red badges, highlighting the moment in the conversation when they become possible.
Buckle up! We’re going all the way back to 2008.
Pure Static (e.g. Jekyll)
Jekyll, created in 2008, has long been the most popular Static Site Generator. Following the “bake, don’t fry” adage, it pre-computed all the pages of the website to have them readily available for its visitors.
It’s straightforward. Simple. No shenanigans. The desired page is served immediately to the user, and it is immediately available to view and interact with. Should she navigate to another page, her browser would fetch it in the same way it did the first.
As years went by, however, the user experience this solution provided somehow lagged behind what users got used to with mobile applications. Transitions, offline-mode, all the bells and whistles of the mobile revolution were nowhere to be found.
Client-Side Rendering (e.g. React, Vue)
The major shift that happened with that evolution is that the cost of building web pages passed from the server to the user’s browser. This cost is indicated in the discussion with the gear icon, during which the screen is mostly blank or showing a loading indicator.
Server-Side Rendering (e.g. Next.js, Nuxt.js)
A few years after this paradigm was introduced, these issues lead the pendulum to swing back towards the server, with the introduction of Server-Side Rendering.
What if we could remove it altogether?
For this section, I’ll take my personal blog as an example. I chose to build it with Gatsby, as I wanted to learn more about how it worked and could leverage my React experience to ship it quickly.
The Developer Experience was a delight and I’m overall pretty happy with it, but something felt off. My blog is pretty basic: an index of all the articles, a page for each, and a few other pages here and there. Yet it was powered by the same technology that powers Facebook, AirBnB and many other extremely complex websites: React. Any overengineering questions put aside, I still required any reader to download, parse, and execute React for no benefits at all. There are no smart widgets or complex UI to justify React. Only text and images.
My (outstanding) developer experience had an impact on my reader’s user experience. There is no such thing as trickle-down UX.
Of course, not every website is as simple as my blog—that would be pretty boring. A lot of Gatsby and Next.js websites out there rely on React for their user experience: pretty animations, shopping carts, newsletter sign-ups, and the likes. Is there something we can do on those websites to make them lighter?
Preact is an alternative to React that has the same functionality, the same modern API, for a tenth of its size. The Preact team managed to drastically reduce the footprint by dropping support for some old browsers and legacy React APIs.
Although there are some slight differences (see the list), Preact can be used instead of React for many websites without any impact on the end-user, and barely any on the developers.
Now, say you are in a situation where you have to create a brand new website. You want to use the Jamstack because you’re convinced of the benefits. You want to be mindful of the user experience, also because you’re convinced of the benefits. Say the website you want to create is similar to this very one, orbit.love.
What would you choose for a Lightweight Jamstack? What did I choose for a Lightweight Jamstack?
Building orbit.love with Tailwind, Eleventy, and Alpine.js
The Orbit website does not have a complex UI—interactivity is limited to a mobile nav menu, modals, and sign-ups for our newsletter and early access. I knew from the get-go that reaching out to (P)react would be heavy handed, so I looked for lightweight alternatives.
I went for the following: TailwindCSS, for styling, Eleventy, for the static site generation, and Alpine.js, for interactivity.
TailwindCSS is a utility-first CSS framework, which means that instead of writing CSS for your components (class="navbar__mobile"), you combine utility classes that each do one specific thing (class="flex flex-row justify-center w-full").
I find this approach incredibly productive once you learn the grammar, and it makes for a resilient CSS architecture at the admitted cost of some duplication in your code. What makes it a great match with Eleventy is that you rarely, if ever, leave your HTML components when writing code. It helps me focus on the task at hand by avoiding context-switching.
The Teastack, a lightweight Jamstack
As Nicolas Hoizey wrote, Jamstack is fast only if you make it so. Going towards a lightweight Jamstack looks like a good step in that direction.
You might also like:
- Why Orbit is Better Than Funnel for Developer Relations
- DevRel teams need tools and models created specifically for our discipline, and not just those adopted from other fields.
- Slack vs Discord vs Discourse: The best tool for your community
- An in-depth comparison of 3 top community platforms across dozens of factors.
- How we use Orbit to build Orbit
- A guide to how we use our product to build our community.