Today was the first day of a two-day Jam.Dev event online. The event had a lot to offer people who are presently trying to sort out the lay of the land in the static site generator ecosystem.

The Azure Take on Static

Shmuela Jacobs, cloud developer advocate at Microsoft, walked through the Static Web App service that is currently in developer preview on the Azure platform. The introduction of the service makes perfect sense, of course, given the success of companies like Netlify and Vercel in providing production build and hosting services. The basic structure of the new service looks a lot like Netlify in terms of what it does, but doesn’t have nearly as friendly a UI, at least not at this point. Part of this no doubt lies in the higher degree of complexity that large sites on Azure tend to bring to their cloud game.

Like other options in the space, Azure basis the static service on repositories stored in github, such that when a new commit is made to the application’s repository, Azure runs the build and, assuming a successful build, deploys the application to the Azure CDN. You set up a config file that sets up things like environment variables that your app needs in the production environment.

Shmuela Jacobs, cloud developer advocate at Microsoft

By and large, this look at Azure’s entry into the jamstack ecosystem (beyond the already existent capability to host Docker images of jamstack servers) was perhaps the most interesting part of the day.

Stephanie Eckles, a software engineer at Microsoft, gave a full-throated and interesting walkthrough of the 11ty static site generator. She built a basic site as a demo that ran in 3 minutes, complete with a timer running in the screen. It definitely underscored the simplicity and direct approach of 11ty compared to static sites built with React or Vue frameworks running on client pages. A panel that followed brought together Sara Drasner, vp of developer experience at Netlify, Phil Hawksworth, developer experience engineer at Netlify, and Gift Egwuenu, frontend developer at Passionate People. These are all heavy hitters in the jamstack world, but the panel never quite gelled and thus wandered a bit.


A series of quick, ten-minute talks covered a lot of ground, including an overview of Google’s Lightspeed metrics given by freelance developer Henri Helvetica. There’s no doubt that Helvetica knows whereof he speaks—he’s a frequent speaker at events and turns up involved in lots of projects—but the lightning format didn’t serve him well when it comes to Google metrics, which get deep and detailed in a hurry.

Tamas Piros, developer advocate at Cloudinary, talked about image management (and, in particular, distributing tailored images from the edges of the net. The takeaway here was a link to a site he put together for comparing various approaches in real time. It’s at Miriam Schwab, CEO and cofounder of Strattic, talked through the basic scenarios for making WordPress a backend for various kinds of static site, as well as making a compelling argument for why this is important in a world that has become very accustomed to WordPress and capable of using it to turn out tailored sites very quickly.

Miriam Schwab, CEO and cofounder of Strattic

The final two talks of the day focused on jamstack approaches to ecommerce, though largely it was a matter of showing that it was indeed possible to do. Flor Antara of Zipwhip worked through four approaches to selling on static-based sites.

Option one, Antara said, was the non-jamstack Shopify-like third-party service. This part of the talk had me looking for the option to turn the playback speed to 1.5x. This can be a problem with live events. Option two was integration with an API, which she pointed out could be fairly time consuming to set up. Option 3 was what Antara called “Add-on” ecommerce.

Snipcart, etc

In a quick demo, she demonstrated the Square “Buy Link”, the second the PayPal equivalent, the third was Shopify buy button, and the final was SnipCart, which is, not to split hairs, actually an API approach, just one that happens to use GraphQL. These are all good ways to handle basic sales capabilities, but somewhat glossed over in the presentation was the fact that if you go with, say, a PayPal buy button, then you have to handle anything that would typically fall into tasks that collectively we call a shopping cart. In other words, you have to have static pages that describe the products. You don’t get any integration with inventory data unless you code it yourself. If you want to offer, say, three for the price of two bundling, you’ve got to track how many things have been ordered and whether the relevant items quality for the discount.

It _is_ possible to support some shopping cart options into a PayPal scenario, but basically you are handing off to PayPal, just like you might hand off to any other third-party ecommerce store, as per Antara’s Option One. But SnipCart is a different animal in that it supports GraphQL. As a technicality, this is an API interface, too, but it’s particularly well geared to jamstack frameworks that use GraphQL. Antara gave a walkthrough of how this could be added to her flat HTML product pages, but arguably what’s valuable here is the ability to use templated product pages that query SnipCart for data elements that are dropped into the page.

The conclusion of the talk, that SnipCart is the clean, jam-savvy way to do this, is spot on. Since this was a demo-based talk, SnipCart was the only vendor discussed as a headless eCommerce vendor, but needless to say, there are others, such as commercetools, and even a headless variant of Shopify.

We’ll cover day two of Jam.Dev in a separate article.