What is Jamstack's long-term market opportunity?

Most websites out there are dynamically generated on the server [at request time]... These [Jamstack sites] are built in advance. So all the HTML is generated in advance and they're usually delivered with a content delivery network. So the idea is that they're going to be very, very fast because all the content is sitting as close to the consumer as possible, as opposed to in some data center, maybe in AWS or wherever… A lot of people, a lot of engineers, especially front-end engineers, React developers, especially were like, "Yes. Give me the power I need as a front-end developer to be able to deliver websites and not have to worry about servers and all that complicated business." —Jamund Ferguson

And instead of pages being built on the server, then, pages would be pre-rendered and delivered to users as static assets served over CDN, using the edge network to increase speed/performance.

In a Jamstack company, there would be virtually no need for dev ops—front-end developers could be empowered to build full stack apps on their own.

Before the Jamstack, “static sites” were almost exclusively the domain of personal blogs and portfolio sites, but Jamstack’s embrace of APIs and serverless functions made dynamic websites possible within a decoupled architecture. And most importantly, it made deploying these kinds of dynamic sites faster and easier for developers.

The best way to think about Heroku is that it was the first consumer app for developers. They created this “surprise and delight” experience of typing in git push heroku master and instantly having a website be live. Like Uber, Heroku took out a number of time-consuming steps in between A and B, and delivered a magical moment.

Vercel and Netlify are out to build the next generation’s consumer app for developers.

Every company that served developers looked to Heroku for inspiration as they sought to abstract away the right kinds of complexity and enable similarly push-button experiences for their users.

“Heroku looked at of the stack and said, oh yeah, we can get rid of container config and wiring up these infrastructure services and auto provisioning things, and I think they did a great job for the era that they came up and as we've iterated as an industry, we all learned from Heroku and so every company is now focused a little bit more on, can we get a Heroku-like experience and everybody kind of did.” —Jason Lengstorf (Netlify)

In eliminating configuration and the kinds of boilerplate tasks that take up the time of developers, Vercel and Netlify take directly after Heroku and what it did for developers.

For example, Heroku hosts your apps on “dynos”, which are really processes running code on a grid of Amazon EC2 virtual machines that Heroku manages. These virtualized Linux containers drastically simplify the process of deploying an app for developers: to scale up for more users, you just add dynos!

Vercel and Netlify, on the other hand, do much the same thing but with S3 buckets for storage and Lambdas for serverless functions. You just choose the files you want to host and the functions you want to execute, and Vercel/Netlify handle the actual storage and implementation.

“[Netlify is like] can we take [Heroku’s innovation] a step further?... [Can we] make the problems that developers have into a clean set of defaults so that developers don't have to waste any cognitive energy or any time on the things that don't change?... Now these developers are spending even less time worrying about the configuration and the boiler plate and the setup and the maintenance. They can just focus on features and all that rolls downstream to customer benefits.” —Jason Lengstorf (Netlify)

But Jamstack is also a reaction to Heroku’s shortcomings. After its acquisition by Salesforce, Heroku started to drown in its own complexity—trying to serve every framework and every language, Heroku was getting bogged down in its legacy tooling and was starting to miss out on new, important developments in web development. Things like SSL and CDNs needed to be added via add-ons.

Jamstack providers like Vercel and Netlify reverted back from the “everything goes” mentality of Heroku into a more opinionated architecture, but one that was designed around these emerging web development ideas and technologies: instead of having to use an add-on or do a bunch of manual configuration to use serverless functions or a CDN, for example, you got those built-in for free.

Jamstack took the Heroku concept of abstracting away all the low-level services that help you deploy an app, but applied a set of opinionated defaults that fit this emerging paradigm of decoupled front and back-end—and also fit an emerging generation of developers that had only ever known Heroku as a Salesforce product, and were more interested in writing front-end code than configuring dynos.

Jamstack synthesizes a few big modern trends and best practices around web development, with a focus on speed and developer experience.

These include the decoupling of the front-end and back-end, pre-rendering content to be served over CDN rather than from a web server, and using APIs for back-end functions and logic instead of hosting that logic on a server.

All the dynamic functionality of Jamstack sites (what keeps them from being just a collection of static files) is written in Javascript—that’s both the basic interactivity (liking, sharing, buying) on the front-end as well as generation of new pages via static site generators and API requests.

Jamstack sites aren’t limited to any Javascript front-end framework, though Next.js (a lightweight framework built on top of React) has emerged as the dominant framework for Jamstack sites.

“What we're trying to do with JAMStack is get away from the more kind of enterprisey, really cumbersome process of building for the web…You pre-compile as much of that as you can. So you have a build step that'll pull in data that doesn't change between page loads and compile that into static assets instead of trying to load it on every page request, and this helps increase your cacheability, lowers your overhead, it reduces risk, it improves security… and then you push that out to the edge on a CDN and using various other methods of just delivering that content as close as you can to your end users. So this is sort of the default that we want people to start adopting for the web.” —Jason Lengstorf (Netlify)

Next.js’s core innovation was bringing the idea of server-side rendering into accordance with the Jamstack philosophy of decoupled front and back-end and the delivery of pre-rendered content to users via CDN, making it possible to build more fully-featured applications within the simple and performant architecture of the Jamstack.

Instead of hosting your own CMS on your own web server (ala Wordpress), writing your own authentication code or managing your own user database, key backend services within a Jamstack architecture are accessed via external APIs, hence “headless” payments or “headless” ecommerce.

Serverless functions are another important trend in APIs for Jamstack. Today, every major cloud provider makes it possible for developers to write functions that can be run without a server, via services like Amazon Lambda. Netlify and Vercel bundle up these cloud providers’ services and include them inside their platforms, allowing users to write their application logic and run it without having to worry about maintaining an actual server.

Fundamental to the idea of Jamstack is that the HTML that will be delivered to the user when they request a site should be prebuilt at deployment time (including making any calls to external APIs) and then served via CDN rather than from a centralized web server.

Because pages are pre-built, “time to first byte” is minimized and pages can load for users much faster. With modern browsers like Chrome, functionalities that previously had to be processed on the web server can now be run in-browser with much lower performance penalties.

Markup is often generated via a static site generator like Next.js or Gatsby, which takes a series of templated files and uses them as instructions to generate the site at build time.

For folks who are looking to build a website, Jamstack sits somewhere in between no-code/low-code web development options on the low end and fully DIY with AWS/Heroku on the high end.

The key to understanding why developers build with Jamstack is understanding that even launching a website used to involve a lot of capex because of on-premise servers. That meant there weren’t many websites, but there also wasn’t a lot of demand. As cloud has proliferated thanks largely to AWS and Heroku, it has become incredibly easy to launch websites.

Today, there are various large platforms that folks can use to launch websites. Within the no-code/low-code web development options in ecommerce specifically, there are:

In a Jamstack approach, however, instead of being locked into an app store, developers can harness the extensibility of the entire open web via headless 3rd party APIs. That helps merchants differentiate based on product.

One easy way to think about what Netlify and Vercel are is that they’re resellers of AWS with a UX layer wrapped around it. That both creates challenges with pricing and how it scales within organizations—breakpoints that can cause teams to move off Vercel/Netlify onto AWS as it becomes prohibitively expensive and/or lacking in customizability and fine-grained control.

“[Netlify/Vercel] are based on AWS and existing cloud providers. But what they've done is they've figured out way better user experience or developer experience. And they're essentially making that developer experience an add-on that's worth paying for, and it's worth paying a lot of money for. I don't think there's anything super proprietary in the technology from any of these providers.” —Jamund Ferguson

What’s included in the bundle is storage (S3/GCS), compute (EC2), CDN (Cloudflare / Amazon CloudFront/Fastly/Akamai), routing, and serverless functions (Lambda).

By abstracting all of the above services into a clean UX wrapper, Netlify and Vercel make it possible for primarily front-end developers to harness the power of these many cloud services and deliver fully-featured apps with a working back-end over a CDN without really understanding anything the underlying cloud services they’re using.

That value prop is reflected in Vercel/Netlify’s core base of customers, which is roughly individual developers, early-stage startups and teams of developers within larger companies. These kinds of customers prioritize getting up and running as quickly as possible and don’t want to go through the laborious process of getting set up on AWS just to launch a new feature, marketing site, or small prototype product.

[T]hey're just nailing that development experience. And developers are just thinking, "When I'm doing something hard, when there's an easy way to do it, I'm just going to flock to the easier way to do it." —Jamund Ferguson

As you start to move into the enterprise level, there are more breakpoints where the Netlify/Vercel model of abstraction might break down, forcing teams to migrate their spend over to AWS or another traditional cloud provider directly:

“I think Enterprise adoption of Jamstack is actually tough… It turns out at Amazon and a lot of places, we do a lot of dynamic stuff... instead of having a static site where you just immediately get the data, because it's at a local CDN to you, every single person, we deliver them a static outline of a page. And then we hit an API trying to get content. So you just got a lot of loading spinners… I ended up focusing a lot of my time [on] how to get rid of these loading spinners and make stuff faster. And in many cases that meant trying to nudge people away from that Jamstack approach toward a more traditional server rendered approach.” —Jamund Ferguson

While it’s unlikely that many enterprise companies would move their entire stack over to Vercel/Netlify, what’s more likely is that Vercel/Netlify could sit alongside traditional cloud providers inside organizations and serve as a testbed for new products, a front-end-only sandbox, and a place for developers to run experiments.

“What we see, in our case, is big companies like enterprise companies, in order to try Jamstack, they have some kind of pivot project, so okay, let's do something small and just try and test how it works… [W]e don't really see big immigration, okay, let's do everything on Vercel, I think the approach is, okay, let's try it, let's try how it works, and maybe we'll create new projects on this platform… We see a lot of enterprise deals. But yeah, I wouldn't say it's like, okay, we have to move from Amazon in this year.” —Thom Krupa

Additionally, as projects get more complex, involving things like real-time streaming or containerization, teams will hit the limits of tools like Vercel/Netlify—these kinds of projects will be a better fit for tools like Render/Kintohub that are designed to help deploy with e.g. managed containers.

APIs (the A in Jamstack) capture both the back-end services that provide ‘server-side’ logic within Jamstack both via serverless functions and headless APIs (see: Amazon Lambda, Auth0, Algolia, etc.).

These are what enable Jamstack sites to go beyond personal portfolios and blog sites and become fully-functioning dynamic sites that would have required server-side logic as of 2007~.

The inverse of this is that the Jamstack approach also is a tailwind for APIs in general because by making it easy to hook up to 3rd party APIs, Vercel/Netlify enable their interoperability and can drive distribution through their integration marketplaces.

That said, APIs and headless products have the advantage that they are not dependent on Jamstack. Jamstack couldn’t work without APIs, but APIs can fit just as cleanly into a MEAN or other approach to web development. Their core value proposition is that they solve tasks that web developers both don’t want to do and aren’t qualified to do, like search and authentication.

As of 2022, we’re far from the original static sites like portfolios and blogs that marked the early era of the Jamstack.

An expressly hybrid language that supports both static sites and server-side rendering has now become the #1 “Jamstack” framework. To write server side code, some companies will use a combination of Vercel or Netlify and Heroku.

And “Jamstack” itself as a term is already notably on the decline.

What’s clear is that the principle ideas of the Jamstack, which is the consumerization of the developer experience, is here to stay—and the big trend over the coming years will be solving for that increasing hybridization in the developer experience.

“Traditionally, a JAMStack site was one where we used the static site generator and took some content and some templates and married them and output the entire site into essentially a folder, and threw that folder online so that when a visitor came to see the site, they were just loading that HTML. There was no logic on the server... Over the last year or so, we've gotten more of a hybrid approach, say Next.js and that sort of thing where you can have some static and some server rendered and dynamic rendering of some pages and that sort of thing. It's muddied the waters.” —Bud Parr

As consumer products for developers, tools like Netlify and Vercel have a few primary mechanics they can use to keep strengthening their value proposition: collaboration (via network effects and better team features), integrations (to extend the features of the platform), and app stores (to grow the 3rd party ecosystem alongside their own).

The flip side is that as Heroku fell out of favor, all “consumer” apps can fall out of favor. One interesting source of potential competition lies in PaaS solutions like Replit and Glitch, which drastically simplify the whole process of writing and deploying apps by allowing code to be typed directly into the browser and have used their embrace of these more consumer kinds of mechanics to build strong adoption with the younger generation of up and coming developers.