← Blog

Some thoughts on Jamstack Conf 2021

#Jamstack #JavaScript

Jamstack Conf 2021 was last week (October 6-7, 2021). While I wasn’t able to participate in this virtual conference live, many of the recorded talks were made available on YouTube. Thank you, Jamstack Conf!

I was never planning on binging all the videos—even though most of them are less than 20 minutes, including a few less-than-3-minutes lightning talks. But I managed to watch several that piqued my interest. Here are some thoughts.

Jamstack no longer means JAMstack

What is now Jamstack was originally JAMstack, where JAM stood for JavaScript, API, and Markup. I don’t intend to dig too deep into how the term has evolved since it was originally coined by Netlify’s co-founders in 2015. That said, it’s worth noting the original notion of JAMstack was likely Netlify’s attempt to capture the the rise of static site generation (SSG) tools then.1

Interestingly, JAMstack became Jamstack in March 2020.2 Certainly, SSG and, more generally, serving pre-rendered pages are still its big focus today.3 However, even the official Jamstack website no longer explicitly refers to the JAM acronym. What’s changed?

If I may speculate, this subtle re-branding seems to be motivated by the continuing rise of server-side rendering (SSR)—and more concretely, growing adoption of Next.js and Vercel. Put differently, the move from JAMstack to Jamstack signals an effort to expand beyond SSG and bring SSR under its brand. It’s notable that, shortly after, Netlify introduced next-on-netlify to enabled SSR on its platform, powered by AWS Lambda-style serverless computing. Similarly, but from the opposite direction, Next.js has been adding improved SSG features (e.g. getInitialProps(), getStaticProps(), getStaticPaths(), etc.) in its 9.x releases (Next.js 9 was released in July 2019).

Anyhow, it seems that Jamstack today seeks to encompass web apps and sites that are static, dynamic, and everything in between. The only thing they have in common at this point is that most of them, if not all, are built using/on top of JavaScript UI frameworks—React, Vue, Svelte, etc.—in addition to Eleventy being somewhat of an oddball.4

All that being said, I find it particularly interesting that in his keynote speeach, Netlify’s Matt Billmann openly and rather strongly expressed his skepticism toward React Server Component:

Server components […] will probably make it really hard to reason about, like, where does the state live? Again, does the state live in the browser or in the server? What happens as it’s moving back and forth? […] To a certain degree, it can feel a bit like moving back to the old model of the web. […] The idea of React Server Component sort of feels a bit like rolling back to that architectural model for the web where every user interaction needs a server to tell the UI what to do.

Phrases like “moving back” and “rolling back” insinuate that React Server Component is a sort of regression. I get that provisining full servers is not Netlify’s business model, but I still find it curious that he felt the need to make such a forceful remark.

Rise of static-first MPA frameworks?

One of the stars of the Jamstack Conf 2021 was Astro, which won the Jamstack Ecosystem Innovation Award. The main value proposition of Astro is to enable developers to use their favorite JavaScript UI frameworks to generate apps that are static by default and performant. In my view, Astro receiving such recognition marks the emerging shift in the frontend web development landscape toward Multi-Page Apps (as opposed to the now dominant Single-Page Apps). In fact, more than one Jamstack Conf talk explicitly discuss this transition:

It seems to me that these two talks are coming from opposing viewpoints. Rich, the original author of Svelte, seeks to push forward the web development by improving the SPA model. From what I can gather, what he proposes as a solution, Transitional Apps, hinges on streamlining the pre-rendering (at either runtime or build time) of static contents for the initial load followed by hydration for dynamic parts. If that’s the case, there is nothing new about the approach, and the result is ultimately a SPA, where, after the initial load, the whole application is hydrated at once and routing/state management is handled in a top-down fashion by the framework that oversees it.

On the other hand, Yang introduces existing and upcoming solutions that are created from a different orientation and directly address the limitations of the standard hydration techniques. These include:

  • Marko: streaming server-rendered HTML and (upcoming sub-)component level hydration
  • Astro: pre-rendering static HTML and lazily loaded component-level hydration
  • React 18 SSR: streaming server-rendered HTML and component-level hydration
  • React Server Component (release TBD)

Notably, Astro is the only one here that outputs an app to be deployed to and fully hosted on CDN. The rest requires a running Node.js server to handle requests.

And more

Of course, Jamstack Conf 2021 was jam-packed😏 with a lot more interesting topics. For this blog post, I will just briefly list a few more thought pieces:

Footnotes

  1. You can find that the main subject of early posts on Netlify blog was various static site generators. For instance, Netlify’s CEO highlights in this article (predates the term “JAMstack” and also shared on Netlify blog) how static site generators would be “the next big thing.” ↩

  2. That is, based on the first appearance of the updated term on Netlify blog. The first post to call it Jamstack instead of JAMstack was published on March 19, 2020. ↩

  3. An excerpt from the “What is Jamstack?” page: “The core principles of pre-rendering, and decoupling, enable sites and applications to be delivered with greater confidence and resilience than ever before.” ↩

  4. But wait, you can use components built with these UI frameworks on Eleventy! See this entertaining talk by Ben Holmes. ↩