JAHC
The acronym JAM stands for JavaScript, APIs, and Markup. Now, all three of these technologies are used time and time again, there is not necessarily anything new about them. However, the way these established technologies are combined provides us with an innovative and modern way to build fast and reliable websites.
The Jamstack is based on two main philosophies, that enable sites and applications to be delivered with greater confidence and resilience than ever before.
With Jamstack, the entire front end is prebuilt into highly optimized static pages and assets during a build process. This process of pre-rendering results in sites that can be served directly from CDN, reducing the cost, complexity, and risk, of dynamic servers as critical infrastructure.
With so many popular tools for generating sites, like Gatsby, Hugo, Next.js, and many more, many web developers are already familiar with the tools needed to become productive Jamstack developers.
With the markup and other user interface assets of Jamstack sites served directly from a CDN, they can be delivered very quickly and securely. On this foundation, Jamstack sites can use JavaScript and APIs to talk to backend services, allowing experiences to be enhanced and personalized.
The thriving API economy has become a significant enabler for Jamstack sites. The ability to leverage domain experts who offer their products and service via APIs has allowed teams to build far more complex applications than if they were to take on the risk and burden of such capabilities themselves. Now we can outsource things like authentication and identity, payments, content management, data services, search, and much more.
Jamstack sites might utilize such services at build time, and also at runtime directly from the browser via JavaScript. And the clean decoupling of these services allows for greater portability and flexibility, as well as significantly reduced risk.
Moreover, Jamstack is secure because it does not use a traditional server. The lack of a server or a database does not leave room for hackers to damage or exploit sensitive information.
Additionally, Jamstack is able to provide us with better performance because it does not have to wait for codes to be processed by a back-end server, rather it is available for the user directly.
Most Jamstack websites today are based on static pages that are ready to go at the touch of your fingertips. Jamstack makes it easy for web users to quickly navigate through sites.
It is important to remember that there is no limit to what you can create using Jamstack, however, there are some cases where this ‘stack’ truly shines, such as:
A Jamstack architecture can bring all sorts of benefits to the sites and to project workflows. Some of the key benefits are:
The Jamstack removes multiple moving parts and systems from the hosting infrastructure resulting in fewer servers and systems to harden against attack.
Serving pages and assets are pre-generated files allows read-only hosting reducing attack vectors even further. Meanwhile, dynamic tools and services can be provided by vendors with teams dedicated to securing their specific systems and providing high levels of service.
Popular architectures deal with heavy traffic loads by adding logic to cache popular views and resources. The Jamstack provides this by default. When sites can be served entirely from a CDN there is no complex logic or workflow to determine what assets can be cached and when.
With Jamstack sites everything can be cached in a content delivery network. With simpler deployments, built-in redundancy ,and incredible load capacity.
Page loading speeds have an impact on user experience and conversion. Jamstack sites remove the need to generate page views on a server at request time by instead generating pages ahead of time during a build.
With all the pages are already available on a CDN close to the user and ready to serve, very high performance is possible without introducing expensive or complex infrastructure.
When hosting complexity is reduced, so are maintenance tasks. A pre-generated site, being served directly from a simple host or directly from a CDN does not need a team of experts to "keep the lights on".
The work was done during the build, so now the generated site is stable and can be hosted without servers which might require patching, updating, and maintenance.
Jamstack sites are pre-generated. That means that you can host them from a wide variety of hosting services and have a greater ability to move them to your preferred host. Any simple static hosting solution should be able to serve a Jamstack site.
Bye-bye infrastructure lock-in.
Jamstack sites can be built with a wide variety of tools. They do not depend on proprietary technologies or exotic and little-known frameworks. Instead, they build on widely available tools and conventions. As a result, it's not hard to find enthusiastic and talented developers who have the right skills to build with the Jamstack. Efficiency and effectiveness can prosper.
When building Jamstack projects, you can really get the most out of the stack if you stick to a few best practices.
Because Jamstack projects don’t rely on server-side code, they can be distributed instead of living on a single server. Serving directly from a CDN unlocks speeds and performance that can’t be beat. The more of your app you can push to the edge, the better the user experience.
Take advantage of the world of modern build tools. It can be a jungle to get oriented in and it’s a fast moving space, but you’ll want to be able to use tomorrow’s web standards today without waiting for tomorrow’s browsers. And that currently means Babel, PostCSS, Webpack, and friends.
Because Jamstack markup is prebuilt, content changes won’t go live until you run another build. Automating this process will save you lots of frustration. You can do this yourself with webhooks, or use a publishing platform that includes the service automatically.
As Jamstack projects grow really large, new changes might require re-deploying hundreds of files. Uploading these one at a time can cause an inconsistent state while the process completes. You can avoid this with a system that lets you do “atomic deploys,” where no changes go live until all changed files have been uploaded.
When the build-to-deploy cycle becomes a regular occurrence, you need to know that when a deployment goes live, it really goes live. Eliminate any doubt by making sure your CDN can handle instant cache purges.
With a Jamstack project, anyone should be able to do a git clone, install any needed dependencies with a standard procedure (like npm install), and be ready to run the full project locally. No databases to clone, no complex installs. This reduces contributor friction and also simplifies staging and testing workflows.
Jamstack sites are used for real business needs. We’re always interested in what the websites you’re building are for. Are you putting together a personal site to show off your work? Making an e-commerce play? Or building an enterprise application? Our 2021 categories were a little different from the ones we used in 2020, so the results aren’t precisely comparable. But they’re still fascinating. Since people work on many sites over the course of a year, we allowed respondents to pick more than one option.
As you can see Personal websites dominate, just like last year. Whatever else you build, you’re always building your own website too!
E-commerce is a huge driver, with a surprisingly strong showing by enterprise software at 25%.
Every major industry uses Jamstack. Not just tech-forward sectors but companies that often compete in more than one industry, so respondents can pick several industries.
Advertising, marketing, media, and publishing all seem like tech-forward industries you’d expect to find on the Jamstack. Education, finance, and healthcare, on the other hand, aren’t known for being early adopters.
Jamstack isn’t all client-side, so we asked about the popularity of some major server-side technologies as well. We were particularly interested in how much adoption serverless functions are seeing compared to other server-side technologies.
Awareness was high for most techniques—over 75% in most cases—while usage was below half for each.
Containers like Kubernetes are popular, and container orchestration is only used by half as many developers.
Functions as a service, like Netlify functions, are now almost as ubiquitous a technology as containers.
We’ll keep an eye on how functions usage has grown when we ask this question next year.
Jamstack developers are taking security more seriously. All developers will agree that it’s important that your website is fast, secure, and has a high uptime. But a different question to ask is: Which of these is the most important quality?
Last year, speed of development was a higher priority than security. This year, in a statistically significant shift, those factors were reversed. Jamstack developers are taking security more seriously than they did a year ago.
Performance and uptime continue to be the top priorities for developers.
Jamstack designers love Figma. A substantial population of designers responded to our survey, so in addition to asking about development tools, we also ask about design tools. The story in 2021 is the same as last year: Everybody uses Figma, and everybody loves it.
60% of respondents use Figma. Its satisfaction score is 8.8, meaning 8 times more people want to increase their usage than want to stop using it.
It’s getting kind of embarrassing for everyone clustered over there in the bottom left…
Jamstack developers love CMS editors. This is the first year we’ve asked about the kinds of editors developers use. We were curious about the growth in popularity of web-based code editors, including products like Glitch and GitHub’s Codespace.
However, we mistakenly presented an ambiguous question. A “web-based editor” can also mean a CMS editor, like WordPress. And since CMSes are very popular, developers answering that question dominated the results: The more you use a CMS, the more likely you are to answer that you used a web-based editor.
But this in itself is a fun result! The popularity of CMSes means more people use web-based editors than traditional editors like Vim.
However, integrated development environments (IDEs) are by far the most popular option and have the highest levels of satisfaction by a long shot.
Types of editors: usage vs. satisfaction2021 was a breakout year for Sanity and Strapi. Content management systems: Can’t live with them, can’t live without them. We asked developers to tell us a lot about CMSes: Whether they were aware of them, whether they used them, and whether they wanted to use them more or less.
We turned the ratio of “people who want to use it more” vs. “people who want to use it less” into something we call our “satisfaction score,” and you’ll see us use it a few times.
A score of less than one in “satisfaction” means more people want to stop using technology than want to continue using it.
If you compare usage against satisfaction, you begin to see some clear takeaways:
TypeScript is gaining at JavaScript’s expense. JavaScript is unsurprisingly the primary language for the majority of developers at 55%. However, this is down since last year, from 63%.
Where are those points going? To TypeScript, mostly, which 15% of developers now report as their primary language, not just one they use. Python also went up, from 5% to 7%.
Separate from devs’ primary programming language, we asked about all languages. First, let’s look at their absolute usage and satisfaction:
In absolute terms, JavaScript continues to dominate. Workhorse languages like SQL, Bash, and Python remain very heavily used, with TypeScript positioned as a newcomer to the big languages for web developers, with the happiest user base by some distance.
Smaller, newer languages like Rust, Go, Swift, and Elixir are in a cluster of small but happy user communities.
The cut-off line for satisfaction is 1.0, so below that line you see languages with unhappy users: PHP, Java, Perl, Objective-C, and all the C variants, except C#.
React is most popular, and Next.js is a big deal. We asked about an enormous number of frameworks—over 30 of them. Visualizing so many frameworks at once is a challenge, so we split them into two groups: Major frameworks, where the cut-off is at least 10% usage, and then minor frameworks, where usage is less than 10% (keep in mind, developers use multiple frameworks and could mark all the frameworks they used, so these percentages add up to well over 100%).
The major frameworks have a lot of surprises. React is the most frequent choice, as it has been for a long time, and its satisfaction score remains high. Vue has higher satisfaction but roughly half the usage.
Next.js has stellar satisfaction and is really big these days, and Nuxt.js is a little smaller. If you were looking for a safe pick for a new kitchen-sink framework based on this data, Next or Nuxt are where to go.
The big legacy frameworks, jQuery and Express, aren’t going anywhere. But with a satisfaction score below 1.0, jQuery users seem to wish it would.
Relative newcomers Svelte and 11ty are doing very well, with 11ty continuing a strong showing despite relatively low awareness. Early-ish adopters, check these out.
Both flavors of Angular have scores under 1.0, despite maintaining growth.
Let’s look at the next group with under 10% usage. SvelteKit, with huge satisfaction and riding the coattails of Svelte over in the major frameworks group, looks likely to break out by next year.
Here you can see a clear trend mentioned several times. The more your usage grows, the more your satisfaction falls, as your user base expands beyond early adopters. As we saw, 11ty broke into major territory for the first time this year. It has a great satisfaction score, but it’s much lower than last year. This is true, to some degree, for all the growing frameworks. VuePress, Preact, Nest and 11ty form a straight line going down and to the right: the more users they gained, the less happy they were.
There are a few obvious exceptions. Next.js, despite growing enormously, also improved its satisfaction score.
React managed to keep its score steady. No small feat when you’re the biggest framework by a long shot.
Gatsby lost in both usage and satisfaction, an unfortunate outcome for that team.
Jamstack devs are using third-party services and CMSes to make their lives easier. Jamstack is all about APIs, and many third-party APIs exist to make life easier for developers.
The most popular third-party service is authentication, which is unsurprising—using an existing login reduces signup friction and the security challenges associated with maintaining your own authentication.
CMS services are likewise very popular. Why build a rich text editor when one already exists?
The world is changing, and the Jamstack—and the developers who use it—is changing with it. Based on what you’ve told us this year, we’ve observed shifts within our developer community. What these changes tell us paints a picture of a world in which more people are coming to our community as new developers, often as students; some of the largest websites and apps are built on the Jamstack, and more and more industries are represented in Jamstack development.
In other words, the Jamstack is touching all industries. We’ve gone mainstream as more developers learn about Jamstack. It’s the new way to build applications and websites, and it’s where the industry is going. Even more, it’s a thriving community that is growing fast as a wave of mainstream adoption continues, driven by fantastic scaling, high performance, and workflows and tooling that developers love.
A collection of terms often used when talking about Jamstack and associated web technologies.
JAHC helps small businesses go digital.