The Jamstack Innovation Fund with Matt Biilmann

Episode Description

Matt Biilmann, CEO of Netlify, discusses the evolution of the Jamstack architecture, edge rendering, composable web services, and the Jamstack Innovation Fund.

Episode Summary

Matt Biilmann joins the FSJam podcast to address whether Netlify is moving away from the Jamstack, firmly asserting that the architecture is maturing rather than fading, with major enterprises like Twilio, Unilever, and DocuSign now building on it. He traces the Jamstack's core idea — decoupling the web UI from back-end services — from its origins in 2015 through the rise of serverless functions, edge rendering, and the new generation of frameworks like SvelteKit, Remix, and Qwik that are built around cloud platform primitives. The conversation explores how a streaming edge rendering layer could reshape data fetching and caching, with Biilmann arguing that globally distributed databases will remain niche and that GraphQL aggregation layers like Netlify Graph will become the practical path forward. The discussion then shifts to the Jamstack Innovation Fund, where Netlify has invested in ten early-stage companies — including Convex, Deno, Nuxt, Clerk, and others — not just for capital but to share go-to-market expertise and ecosystem connectivity. Throughout, Biilmann emphasizes the composable architecture's promise for enterprises trapped in monolithic solutions, while acknowledging that the next frontier of complexity lies in reducing the friction of integrating multiple APIs and services into a single coherent developer experience.

Speakers

Christopher Burns
Matt Biilmann
Anthony Campolo

Chapters

00:00:00 - Introduction and the State of the Jamstack

The episode opens with hosts Christopher Burns and Anthony Campolo welcoming Matt Biilmann, who they describe as both CEO and chief tech mind behind Netlify. They acknowledge the debt the Jamstack community owes to Biilmann for coining the term and giving the architecture a recognizable identity beyond static site generators.

Christopher jumps straight into the central question on listeners' minds: is Netlify dropping the Jamstack? Biilmann responds emphatically that the Jamstack is growing up, citing major enterprise deployments at Twilio, Unilever, DocuSign, and Asana as proof that this architecture has moved well beyond its indie-developer roots into mission-critical production use cases.

00:02:34 - The Core Architecture and Its Evolution

Biilmann explains the original Jamstack manifesto he wrote in 2015, centered on decoupling the web UI from a monolithic back end and composing services and APIs instead. He describes the advantages this brought — predictable deploys, global CDN distribution, strong security — and how Netlify built a cloud platform around those principles, incorporating serverless functions and eventually edge handlers as new primitives emerged.

He traces a feedback loop between cloud platforms and frameworks, noting that Gatsby, Vercel, Cloudflare Pages, and others adopted the model Netlify pioneered. A new wave of frameworks like SvelteKit, Remix, and Qwik are now being designed around these platform capabilities, though some push toward monolithic full-stack patterns that diverge from the decoupled Jamstack philosophy. The hosts and Biilmann briefly discuss how Redwood fits into this landscape as a framework that maintains decoupling while offering a full-stack experience.

00:08:59 - The Future: Edge Rendering, Caching, and GraphQL

Anthony asks what the next five years of the Jamstack will look like. Biilmann outlines three coexisting patterns: traditional prebuilt sites with reliable deploy previews, single-page applications for locked-in app experiences, and a new streaming edge rendering layer that shifts data fetching from the browser to compute running close to the user. He highlights Shopify's Hydrogen as an early production example.

The conversation turns to a critical challenge with edge rendering — data locality. Biilmann argues that running code near users only helps if data is also nearby, and that globally distributed databases will remain prohibitively expensive for most companies. Instead, he envisions GraphQL aggregation layers like Netlify Graph caching API calls at the edge, a pattern also pursued by companies like StepZen and Stellate, making the composable back end practical at scale.

00:16:20 - The Jamstack Innovation Fund

Christopher introduces the Jamstack Innovation Fund, and Biilmann explains Netlify's longstanding commitment to investing in the broader ecosystem rather than just its own platform. He describes how Netlify earmarked capital from its latest funding round to back early-stage companies building tools that complement the Jamstack architecture, offering not just money but go-to-market expertise and access to nearly three million developers on the Netlify platform.

The hosts list all ten fund recipients — Clutch, Tigris Data, Convex, Nuxt, Deno, Everfound, Clerk, ChiselStrike, TakeShape, and Snaplet — and Biilmann discusses the selection criteria. He emphasizes that Netlify participates in existing rounds rather than pricing new ones, and looks for companies building tools that fit the composable, decoupled architecture. He stresses this is only the first round and that collaboration across companies is essential to replacing monolithic solutions in the enterprise market.

00:26:37 - Composability, Developer Experience, and Looking Ahead

Anthony asks Biilmann to unpack the concept of composability. He explains it from two angles: the programming ideal of reusable, interchangeable code, and the enterprise buyer's desire to swap individual components without replacing an entire platform. This architecture lets each vendor innovate independently while delivering solutions that feel as coherent as monolithic alternatives.

The episode closes with a reflection on how far web development has come — from FTP-ing files to basement servers to dragging and dropping onto Netlify — and where the remaining friction lies. Biilmann acknowledges that while deploying has become dramatically simpler, the expectations for what developers must build have risen enormously, making API integration complexity the next major frontier the Jamstack ecosystem needs to solve.

Resources and Links

Transcript

00:00:00 - Christopher Burns

Okay. Matt Biilmann, welcome to the show.

00:00:12 - Matt Biilmann

Thank you. Good to be here.

00:00:14 - Christopher Burns

You are the CEO, and you would say the biggest tech head of Netlify, aren't you?

00:00:20 - Matt Biilmann

That's a pretty good description. I should probably put that in my official title. I think what I normally have is the Chief Instigator at Netlify.

00:00:29 - Christopher Burns

Very much so. And when I met you, we just instantly hit it off. Speaking about frameworks, what's happening in the industry? Maybe some hot topics not to discuss on air.

00:00:39 - Matt Biilmann

I'm always happy to discuss anything.

00:00:42 - Anthony Campolo

Honored to have you here. People who know anything about the Jamstack know that Netlify, and you specifically, are the ones who really made this term something developers were aware of and made it an architecture that had a name beyond just saying, "I'm using a static site generator." This is the full stack Jamstack podcast. We owe you a huge debt for it existing, and for this ecosystem existing. We're so happy to have you here, and we have a lot of really cool topics to talk about.

00:01:09 - Christopher Burns

Yeah. And I think it's great to jump straight into a question that I know some of our listeners are dying to ask: What is happening to the Jamstack, and is Netlify dropping the Jamstack?

00:01:23 - Matt Biilmann

No, no. We're big proponents of the Jamstack, and I think the Jamstack, more than ever, is growing up. You can see that from people on Netlify building with a Jamstack approach, right? By now, that's very real, very deep, mission-critical enterprise use cases. If you log into Twilio today, that whole SaaS application is built with a clear Jamstack approach, and it's running on Netlify. Go to Unilever.com, that's running on Netlify with a clear Jamstack approach. DocuSign, Asana, Flexport, so many others. We've really seen this become a major architecture, both from the developer bottom-up groundswell that Netlify started riding and encouraging, but also for really large, mature enterprise companies.

[00:02:34] The core thing we tried to capture when we coined the phrase Jamstack, and when I put up the first little manifesto that we started sharing with people in the industry and getting buy-in around, was the idea that we would move from a world where every website, web application, and web store was one monolithic thing that bundled together templates, web UI, plugins, business logic, and data access into one thing, to a world where you would decouple the web UI and have the back-end layer split from that monolithic thing into different APIs and services you can compose together. Typically, some of those are your own, and some run on third-party services like Auth0, Contentful, and so on. That was the core architectural shift we were trying to capture when we started talking about Jamstack. Obviously, in the time since we coined the term back in 2015, the platform landscape, the technological landscape, and the framework landscape have all evolved. Of course, that also means the Jamstack architecture and how people think about it needs to evolve as well.

[00:03:42] It gave a lot of advantages. If you did that, you get a predictable release management process and rollback process. You can distribute that UI on a global CDN. You get amazing performance, reliability, and security benefits. People would then either talk to the API and service layer during the build stage or directly from the client as a single-page application. At Netlify, we always had a lot of different combinations of those use cases. Netlify itself was based around the idea that if this decoupling is going to happen, we have an opportunity to build an end-to-end cloud platform for the web UI layer of this stack, including release management, operations, hosting, everything that goes into building, deploying, and operating that web UI layer. We can make developers much more efficient there, and we can make the end results much faster.

[00:04:40] Our product philosophy was always looking at the real-world things that people at scale were doing when they were building projects with this architecture. Early projects were things like the original Obama campaign getting built with Jekyll and so on. There were a bunch of Google projects. It was the stuff that Instrument in Portland were building for a lot of different enterprises with Middleman and so on. We really took the best practices from that and baked it into the platform so you would get them out of the box with a click. As we started seeing new primitives get introduced, like AWS Lambda starting to be a thing, we spent a lot of time looking at how this was actually getting used within this architecture. We came up with the concept of baking in serverless functions to this kind of cloud platform for the web, and saying, "Hey, you can just have a folder with serverless functions."

[00:05:35] They'll roll out together with your static files, and everything will be deployed together. Everything will take the same release management procedure and so on. Later on, we started pioneering what we at the time called edge handlers, which has now turned into edge functions. We started seeing that we're going to have a runtime layer at the edge sitting behind the browser. That will change a lot of what people can do in terms of personalization and on-the-fly rewriting of the script and so on. As the industry has evolved, we've seen that layer also become a streaming rendering layer, talking to different APIs and services. We've baked that into the platform as well. The interesting thing that happened was that as we put Netlify into the world and suggested this is what a cloud platform for the web should look like, that started becoming an accepted concept that a lot of other companies started copying.

[00:06:28] Gatsby built one just for Gatsby. Vercel started building one around Next. Cloudflare Pages, AWS Amplify Console, Azure Static Web Apps. Now we are really in a world where it's become an accepted standard that this is what a cloud platform for the web should look like. The interesting thing is that there's a feedback loop happening where we're seeing a whole new generation of frameworks built around this concept of a cloud platform for the web. Frameworks like SvelteKit, SolidJS, Remix, Qwik, or Marko and so on. They will play into the loop of what the next evolutionary path for this kind of decoupled architecture will look like. Some will take approaches that are very different from what I would describe as a Jamstack approach. Some are looking to build monolithic full-stack applications with serverless functions and edge functions, grouping together templates, data access, plugins, all of that in one package.

[00:07:31] But I think at scale, when we look at the kind of customers we're addressing at the upper end of the market, the enterprise customers, most of these frameworks will still be used in a Jamstack approach, where you build a self-standing web UI that talks to the different APIs and services that make up your back end. That's separated from the web UI layer. What I think we're starting to see shifting is that when we started out, the only points where you would talk to those different APIs and services were either during the build step, as you prebuilt as much of the front end as you could with a more static approach, or directly from the client if you built a single-page application and you talked to the different APIs and services directly from the browser. Now we are seeing a new middle layer where you can build with an approach that is architecturally very similar to a single-page application, but where most of the communication to the APIs and services you rely on happens from a streaming rendering layer at the edge, right behind the browser.

[00:08:35] And when used with a Jamstack architectural approach of decoupling the web UI from the back end, I see it as an evolution of the architecture. As I said, there are other takes trying to use it to go back to a monolithic approach and group everything together. You can build and deploy that on Netlify, but that isn't in line with the idea of decoupling that's inherent to the Jamstack approach.

00:08:59 - Anthony Campolo

Yeah, that's why I've always found Redwood to be so interesting and why it inspired the idea of this podcast in the first place. If viewers want to nerd out on FSJam, you can go listen to our very first episode, episode zero. So many of the things you just said are things we were trying to capture: How do we think of the Jamstack? How do we explain the Jamstack to people? How do we talk about why we want it to reach more in a full-stack way? The decoupling thing was a really big part of it, because something doesn't have to be monolithic to be full stack. That's what I found really interesting about Redwood. It gave you the front end and the back end in a single application, but they were decoupled. Your database is in a separate area, and your front end is in a separate area. I'd be curious, have you ever actually used Redwood?

[00:09:42] What's your take on Redwood?

00:09:44 - Matt Biilmann

I haven't had a production use case for it. I've only had the chance to play around with it for prototyping and ideating. One of the things I always liked in the Redwood vision was that there was a clear idea of, okay, let's take something that for the startup segment is really easy to spin up a whole new application from scratch, but guide people from the framework to keep this idea of decoupling. So your APIs are actually separate from your web UI layer. I think over time, if you grow a company at scale and become successful, you want to be able to instrument teams to work on those different APIs independently, and to have those APIs consumed not just by a web UI, but maybe also from a mobile application or different variations of the UI for internal tools and so on. I've always liked that Redwood bakes that decoupling into the framework rather than trying to go back to saying, "If it's full stack, let's build a monolithic app where everything lives together."

00:10:51 - Anthony Campolo

Awesome. Yeah. We'd love to hear your thoughts on what you think the next five years of the Jamstack are going to look like. You've already talked a lot about edge stuff, so I think we know that's going to be a big part of the future. If you want to talk more about that, or if there's anything else you think is also going to be important.

00:11:05 - Matt Biilmann

I think the edge layer is a really interesting aspect, and it's still very early to know exactly how the real-world use cases will be built out. I think the first production framework using the idea of a streaming edge rendering layer, talking to different APIs, is really Hydrogen from Shopify. It's very early days for that, so it'll be interesting to follow. First of all, I think we'll keep seeing very traditional Jamstack applications prebuilding as much as they can for a lot of different types of projects. You can't underestimate the reliable release process you get when you have a build that gives you a deploy preview. You know that when you roll it into master, that's exactly what goes live, and you know that if you roll back, that's exactly what you roll back to. That segment will keep growing, and we'll be better at doing the builds faster and so on.

[00:12:00] Then I think we'll still have a lot of traditional single-page applications. There are a lot of use cases for locked-in application experiences where, if you build them right, they are typically a very good architecture. Netlify's own admin UI, when you log into app.netlify.com, is a great example of how a single-page application can be a great user experience and feel performant and responsive. But then I think we'll start seeing these use cases where, in many ways, the mentality is very similar to a single-page application, but you shift a lot of the rendering logic and data-fetching logic from happening in the browser into happening in the edge runtime layer. That's a really interesting architecture. Again, some people think that architecture will lead us to building full-stack applications on top of distributed, globally distributed databases. The dilemma you have is that if you run the code close to the user, unless you can get the data close to the user, the end result will probably be slower.

[00:13:04] Normally, if you have a more complex page, you need several round trips to your data source. If you make the latency from the code to the data source higher, then each round trip gets slower, and the end result is a much slower load time. So you need to bring the data closer to that streaming runtime layer as well. I think the use case of doing that through having all your data in a globally distributed database will be for relatively small or niche applications. I know that if I took Netlify's core production database and wanted to put that in even just eight regions all over the world, that would be prohibitively expensive. We'll most likely see that rendering layer talk to different APIs and services, and then we'll figure out patterns to cache those API calls and service calls at the same edge layer as the edge rendering runs too.

[00:14:02] That has the advantage that it works equally well whether that edge rendering is happening in the user's browser or at that edge compute layer. They will still talk to APIs and services, but we'll find better ways to accelerate them. I think one of the patterns that will become common for that is this idea we're pushing with Netlify Graph. That's the idea of saying, "Can we put all the different APIs and services you're talking to behind one specific GraphQL endpoint that serves as an aggregator for all of them?" TakeShape is working on that as well. StepZen is working on that as well.

00:14:42 - Anthony Campolo

I actually worked at StepZen for a year.

00:14:45 - Matt Biilmann

Yeah. Awesome. And GraphCDN, I'm blanking right now on their new name. They rebranded it.

00:14:51 - Anthony Campolo

Yes. Stellate, something like that.

00:14:53 - Matt Biilmann

Yeah. Stellate. Yeah. They're tackling the same problem. I think that's because it starts becoming an approach that really makes sense. If you can talk through one GraphQL layer, then you can start having enough knowledge in that GraphQL layer of your query patterns and your mutations and so on to be able to cache the relevant API calls close to the edge. Then you can take advantage of this streaming edge layer. My guess is that will become a common part of the Jamstack architecture over time, and something more people will use.

00:15:29 - Anthony Campolo

That makes me happy to hear you say that, because I tried pitching StepZen to Jamstack people for like a year and it didn't go very well.

00:15:36 - Matt Biilmann

I think it's also why some of these solutions will be tightly integrated or built into the kind of cloud platform that we've been pioneering at Netlify.

00:15:45 - Anthony Campolo

I love Netlify Graph. I think it's a super cool idea to have that baked into the thing, instead of making it a whole separate thing to bring into your thing. It makes a lot of sense.

00:15:54 - Matt Biilmann

Yeah. And I think especially once, as a developer, you start connecting to the first couple of data sources at that step, the barrier to entry gets very high if you have to bring in a new tool plus a new API. But if it's already built into the platform you use to build the web UI, it becomes a logical step to say, "Let me just activate this API and start querying it."

00:16:20 - Christopher Burns

We've just spoken about what the Jamstack looks like now, where it's been, and where it's going. A big component of where it is going is, in my eyes, the Jamstack Innovation Fund. Can you tell us a little bit more about that?

00:16:32 - Matt Biilmann

At Netlify, we've always seen that the inherent way the Jamstack works is that any specific project a larger company builds, or any solution you're building, is never built with one thing. We're replacing monoliths with a set of different services, APIs, frameworks, and solutions. We've always seen it as incredibly important to invest not just in Netlify's own platform, but in the whole ecosystem around us, and to focus on how we can make that whole ecosystem evolve and grow so we can tackle more complex problems together. We've done that in many ways throughout our existence by sponsoring a lot of open source projects. Today, we have a whole open source team at Netlify that works with different frameworks and communities in that space to make them better and to make the ecosystem more mature. Then when we did our last round back at the end of last year, we earmarked some of the money from that round to start doing investments into early-stage companies in the tech field that we thought were working on interesting solutions in the space, both to give them more funds.

[00:17:48] But that's typically the smallest part. The majority of their rounds tends to come from professional VCs and so on. Netlify is not a professional VC, but we think we can add to those founders and those companies a ton of insight into the process of building this kind of developer-first company, and how you actually sell into companies through developers. We can help them get exposure to our whole user base of developers building with Netlify. We're close to 3 million developers on the platform now, so it's a large segment of the front-end community. We think we can create connections between these new startups in the Jamstack ecosystem and help everybody feel more like they're part of a community making the web better to build for.

00:18:37 - Christopher Burns

This is actually really important as this episode is going out after the announcement. Everfound is one of the companies in the fund.

00:18:46 - Matt Biilmann

Yeah.

00:18:48 - Christopher Burns

I do know the other companies in the fund, and I do have a few questions about the trends that we're seeing. A lot of them are focused on back-end services and abstraction of that data layer. How important do you think that is, and how much of that area do you think we have worked out as a JavaScript community?

00:19:13 - Matt Biilmann

I think that's one of the areas where there's a lot of excitement now. If we look historically at the Jamstack as it grew up, when we started Netlify, the ecosystem around us was mainly unfunded open source projects like Jekyll, Grunt, Gulp, Hugo, Ember, and the like. The main commercial player in the space was pretty much Contentful, and then us. We started getting to a point where the first framework got funded and we started having Gatsby, Contentful, and Netlify as an enterprise-ready stack and so on. Then we started seeing an explosion around that in the headless content API space, with all the different headless infrastructures for content: Sanity, Agility, Strapi, Cosmic, Storyblok. There's a massive amount of choice in that area now, and it's a very dynamic field. We started seeing first Next.js get funded as the next framework, and now we have Astro, SvelteKit, Remix, Qwik, and so on.

[00:20:15] So that open source landscape has been really vibrant over the last two and a half years. I think we started seeing what happened to content initially starting to happen to e-commerce, and we saw all of these new players in the headless commerce space as well. There's a ton of players there. I should be better at naming all of them, but it's such a rich landscape now with so much choice and innovation. I think right now we're around the same cycle in the application space of all these different back-end API pieces that fit into that. That's typically around how you build the back-end APIs and services on top of custom data sources. Companies like Convex are reimagining how global state can look and how subscriptions and real-time and all of that can be handled in a seamless manner from JavaScript. Companies like ChiselStrike are taking your TypeScript code, deriving your infrastructure, deploying that for you, and handling all of that for you.

[00:21:26] So you can write your API code, deploy it, push it, and the rest happens from there.

00:21:33 - Anthony Campolo

For fairness to all the companies we're talking about, we should list them all off right now so people know what they are.

00:21:40 - Matt Biilmann

Yeah. Give them all the shout-outs.

00:21:42 - Anthony Campolo

From top to bottom, the way you've got them written down here, there's: Clutch.io, Tigris Data, Convex, Nuxt.js, Deno, Everfound, Clerk, ChiselStrike, TakeShape, and Snaplet. When I saw this list, I was already aware of seven of these and knew them or was familiar with them because they were either a framework I'd already used, or a company's product I'd already used, or someone who's been on this podcast already, like Snaplet. It's an awesome list. It's a great set and very diverse, even though it has a lot of back-end stuff. It has some front-end stuff, Nuxt is on there, and it's got some e-commerce kind of stuff, some things based around payments, some things based around GraphQL with TakeShape, and things based around databases. It's a really cool set of projects and companies.

00:22:30 - Matt Biilmann

I'm very excited to work with all of these founders. This is not some exclusive list of us trying to pick favorites. These are all founders we feel are independently building things that are going to be massively valuable to the ecosystem.

00:22:46 - Anthony Campolo

Could you talk a little bit about the process of how they were selected? What was the criteria? If someone was looking at this and wants to get on maybe the next round or thing, like, "Hey, this seems cool," what should they know?

00:22:59 - Matt Biilmann

Some of it is timing. Since Netlify is not a VC, we don't go in and price a whole new round or start a whole new fundraising process. We typically talk to companies that are ready to fundraise from a structural perspective, that have a company set up and are ready to go raise money in one form or the other. They're in the process where they're close to closing their first or second round, and there's room for Netlify to participate in that round without coming in and pricing it. That's some of the practicalities. Then, of course, we're looking for companies building tools that fit in with the Jamstack architectural approach, with this idea of a composable back-end layer and a decoupled web UI layer, and all the abilities that gives us to build vertically across different back-end use cases and horizontally on the front-end layer, across things like Deno.

[00:24:04] That's the first truly open runtime for that layer, or Clutch, which is one of the companies in the space working on how designers and developers can collaborate with less friction if that web UI layer is really self-standing and we are adopting component systems, or companies like Nuxt that are investing in the framework space, tooling space, and the admin space of what tools developers use to build those web UIs. Any companies that fit into that landscape, we are very interested to talk with.

00:24:43 - Christopher Burns

Yeah. And I think it's really important to know that this is only the first round. There are going to be more rounds. It really is about when we look at that previous monolithic structure: one company would build everything, and every single component would necessarily be subpar. But when we look at this decoupled approach, we allow each company to excel in that area. When they're all connected together, a much better experience is given to customers and developers.

00:25:13 - Matt Biilmann

But it also means we have to start becoming much better at collaborating as companies, because often when we go into customers, our customer base is really building anything web-facing, from marketing sites to full application use cases to many different types of e-commerce, from luxury brand e-commerce with a small set of SKUs that needs a very high production value, to massive e-commerce stores, or companies like Spring publishing 10 million custom storefronts through the Netlify API. In each of the different use cases, we are typically replacing some monolithic solution, whether that's a traditional monolithic CMS, a monolithic experience management system, a monolithic e-commerce platform, or a monolithic application platform. That also means that as we go into enterprises that are used to having one vendor they buy their whole monolithic solution from, we have to be good at collaborating in those sales processes and in making it easy for developers to use the whole package together versus just the individual pieces.

[00:26:27] Because for each of us, that's often the friction between us and developer adoption. How do developers get the whole thing done, and not just our piece of it?

00:26:37 - Anthony Campolo

Could you talk a little bit about this term composability that's going around a lot? I think you've started using that as composable commerce. Could you talk a bit about that and how it fits into all this decoupled web stuff?

00:26:48 - Matt Biilmann

I think the composable term comes from two sides. On one hand, it's a frequently used term in programming, often an ideal for functional programming. How can we make our code composable, so if we write a bit of code that does something in one context, we can reuse it in all the contexts where we want it? But it's also a term that's coming from the enterprise buyer segment, where a lot of companies have bought monolithic solutions from a vendor, and pieces of that solution get more and more out of date. They're stuck in a world where it's either they replace their whole solution and move to something new with all the trade-offs and massive migration costs that involves, or they accept pieces of their solution being subpar for what they could get. That's the promise of the composable architecture for all these companies.

[00:27:45] If you have clear contracts between the different pieces, then upgrading parts of them, changing parts, or adding new parts is never an either-or situation. It's not, "I have to throw everything away and upgrade to a new system just to fix this one piece." It's, "Okay, I just swap out this piece for the new thing." That's a powerful value proposition for this architectural approach. Each of us can innovate in our different spaces, and if we collaborate well, we'll work incredibly well together. We'll give people solutions that feel as coherent as one monolithic solution, but they can evolve individual parts independently.

00:28:31 - Christopher Burns

I think one of the biggest things about the decoupled web is the introduction to new people, people that have never coded a website before. Before, when we looked at the LAMP stack, they would have to build their WordPress website, host a MySQL database, run a whole service, deploy a whole service.

00:28:49 - Anthony Campolo

They would need to install an operating system to host a website.

00:28:53 - Christopher Burns

Open cPanel, upload the documents through FTP. Do you remember those days, FTP?

00:28:58 - Matt Biilmann

Oh yeah, I remember very well.

00:29:01 - Christopher Burns

Exactly. And to get to the point where we are now.

00:29:04 - Matt Biilmann

The first company I worked for in the web space had an actual room in their basement with their servers. If something broke there, we had to go fix it.

00:29:15 - Anthony Campolo

Like Guilfoyle.

00:29:17 - Matt Biilmann

And we would FTP into those servers with Dreamweaver to edit templates directly on the server. It was a very different world.

00:29:26 - Christopher Burns

Exactly. Today, the simplest way to upload a website to the internet is by dragging and dropping the HTML onto Netlify. We've already come so far. But when we're building blogs, we can use something like Markdown traditionally. That's when we've started going into these third-party services. I really find that this is the next step of the Jamstack. As you said earlier, it growing up is: how does it communicate with those APIs, and how does it do it well enough that it's not a massive jigsaw puzzle to glue together?

00:29:59 - Matt Biilmann

Yeah, I think that's where we see the next frontier of complexity. We often have the sense that every web project now requires you to glue together three, four, or five different APIs and services, manage different auth token secrets for each of them, understand each SDK, and remember what conventions each API uses versus the others. That's for sure one of the areas where, obviously, I mentioned Netlify Graph as one of our techniques, and how we can reduce the complexity and friction for developers and make it intuitive to build with. I think in general we'll see a lot of changes in the modern Jamstack space in how we make that process of working across services much simpler. While we've made massive strides in how easy it is to get something online today and push something out, the demands on what you have to build as a developer today are much higher.

[00:31:03] Back when my company had servers in the basement, there was no such thing as responsive web design. The UIs we were expected to build were very non-interactive and straightforward. Browser technologies were pretty horrible, so we still had to build them. But today, the level of user experience people expect to get in the browser is a completely different level. Right now, as we're recording this podcast, we're doing it in an app running completely in the browser with integrated video stream, real-time audio processing, chat, and all of that.

00:31:40 - Anthony Campolo

Zencastr, for anyone who's curious what he's talking about.

00:31:43 - Matt Biilmann

I'm talking about Zencastr, right? But it's just an example. It's easy to take for granted, but it's a pretty recent thing in some ways that these kinds of applications would be the things we were expected to build as front-end developers in the browser. Today, that's what we have to build. Unless we can help remove the friction and complexity for all the other layers of the stack, it'll be an insurmountable challenge to build the kind of user experiences people want today.

00:32:13 - Christopher Burns

And with that, there's still a lot of learning and advocacy to be done. I see this quite often right now in the world of Shopify. Shopify has just released Hydrogen — that's like the next generation of Jamstack frameworks. So many Shopify developers that I know of don't even know what Netlify is as a whole. That's going to be a giant leap for them to move over to developing in JavaScript, React, and all these other technologies that go with it. One thing I really did want to speak about is your thoughts on the hyperactivity we're seeing around JavaScript. We saw a lot of hyperactivity around frameworks, and now we're seeing it a lot around computing at the edge. Do you think it will all settle down and mature, or do you think we'll jump onto something else?

00:33:02 - Matt Biilmann

This is the interesting part around especially the front-end framework space — it kind of inherently has to keep evolving, because what we're building with front-end frameworks are user experiences. Today, most of us probably have the vast majority of our interactions with the companies we buy things from and subscribe to through the web. So their main way of differentiating who they are to us is through their online presences and their web UIs. That means there's just a certain point where, to differentiate, someone will invent something original — something that everybody else isn't doing right now that feels different. That'll set a company apart for a while, and then the market will start trying to figure out how they did that and how to do it themselves. A lot of other people will start cloning it, and at some point someone will turn that kind of experience — the best way to build it — into a framework. Then everybody will start adopting that framework because it's the best way to build a user experience that's now starting to be what you expect, what modern looks like, what recent feels like.

[00:34:08] Then you'll get to a certain point of saturation where that's just the standard, and if you do that, you're no longer standing out — you're just one of many. Then the cycle has to restart. Someone has to come up with something different. On top of that, the devices we're targeting in UIs keep changing too — the screen sizes, the kinds of browsers, everything has evolved tremendously over the last ten years, and there's no reason to believe that will stop as we start having AI and VR devices. So I think there's just a natural level of constant — I wouldn't even call it constant churn, I would call it constant innovation — in that layer that needs to keep happening. As frustrating as it can sometimes be that it's constantly changing and we have to keep up, it's also the fun part: we're actually continuously building more and more advanced and exciting things in browsers.

00:35:08 - Christopher Burns

I think there are always so many lessons to be taken from people who take different paths. Laravel is pretty popular. Ruby is still pretty popular. What we've seen with Redwood is they took all the best parts of Ruby and put them in JavaScript, and people love it. So there's still so much innovation to be made. That really brings me to my next question: how do you think the open-source environment is going to change? Will we see it predominantly taken over by closed-source products pushing open source forward, instead of individual contributors?

00:35:46 - Matt Biilmann

It's a hard question. That's for sure been a trend in recent years, and probably an even bigger trend while interest rates were near zero and money was cheap to raise. I think sustainable open-source monetization is one of the big unsolved problems of open source. I spend a lot of time thinking about it, but I can't say we have a great solution. At Netlify, we've set aside a significant amount of capital to invest in open source outside of Netlify without claiming ownership of any of those projects — just trying to be good citizens. But it's a real risk that as you build an open-source framework, you look for a way to make it sustainable and have a whole group of people working on it. There's a lot of value in raising money around an open-source project and being able to really invest in it, but it does also inherently change the nature of the project. Typically, to monetize that open-source project, the company forming around it has to build something else — something they can sell — and they eventually have to make money by making the open-source project a go-to-market tool rather than an objective in itself.

[00:37:04] It's probably still a better model than something like OpenSSL sitting around forever where all of us rely on it but no one funds it. But it still doesn't feel like we've found the best long-term sustainable model to make open source fundamentally work as a true community model.

00:37:23 - Christopher Burns

I think this conversation is really important. When you say we don't know all the answers, we're seeing people take different paths. I bring up Zach Leatherman — he was recently on Changelog speaking about how he was working at Netlify as an engineer, and then the opportunity came to just work on Eleventy full-time, and he took it as the best thing ever. But then we see folks like Tanner Linsley who are building this massive base of supporters to push that software forward. And then we see the other camp working inside a company like Vercel. There's so much to do there, and I think there's still so much surface area we need to figure out as a community on how to support these projects that are necessarily fundamental cornerstones of all of our apps.

00:38:16 - Matt Biilmann

The best we've been able to do so far is just hiring a full-time team that works full-time on open source. Zach Leatherman is one of them. Ryan Carniato joined. Matt Kane is on that team working a lot with different communities — from Next to Gatsby and so on.

00:38:31 - Anthony Campolo

Yeah. Brittany Postma for the Svelte community.

00:38:34 - Matt Biilmann

Yeah. So we've really tried to just say, regardless of whether these open-source projects are commercial entities or pure open-source community entities, let's do our part to be good citizens and provide value to all of those communities.

00:38:50 - Christopher Burns

Do you want to speak about Deno a bit?

00:38:52 - Matt Biilmann

I can speak a little bit about Deno. We took a long time to really decide on our path for the edge compute layer. We initially built a prototype based on Wasm, but felt that for the front-end community, the toolchains around that were still not mature enough — the developer experience we could offer wasn't in line with what we'd been doing. Then we prototyped our own isolate-based JavaScript runtime. We took it to beta under the name of Edge Handlers and had customers build with it, and they pushed us hard to take it to production.

[00:39:24] But we still felt that as I looked at the whole evolution of the landscape, this edge compute layer is now starting to be something a lot of frameworks are building around and expect to be one of the building blocks of the modern web. I couldn't just imagine a version of Netlify building its own proprietary runtime. To me, the beautiful thing of the web has always been its open nature — the fact that we're building around standards that don't have a specific owner, that we can take from one company to the other, that we as an industry have all agreed upon and worked on together. I felt like having Netlify's own proprietary runtime — where if you build on it, you could only run it on Netlify — wasn't philosophically aligned with the way we've been building for the open web.

[00:40:21] So I spent a lot of time looking into what the best option would be to lean into something fundamentally open and non-proprietary. That's where Deno came to the right level of maturity at the right time for us to really say, "Okay, let's lean in." They've actually built a true open-source runtime. You can go look at the source code yourself. You can download the Deno CLI and run exactly the same runtime on your local machine as you'll have in Netlify's edge functions. You can open a pull request to the runtime if you have ideas for how it could evolve. That's why we really leaned into Deno and rebuilt our edge functions around Deno as the first major runtime we support there.

00:40:54 - Anthony Campolo

Why did you pick Deno instead of Cloudflare Workers?

00:40:58 - Matt Biilmann

Cloudflare Workers is a fully proprietary runtime.

00:41:01 - Anthony Campolo

That didn't stop Vercel, though. Vercel is building on Cloudflare Workers. So you would only build on something open-source — you would never integrate with anything proprietary?

00:41:09 - Matt Biilmann

We have a lot of proprietary platform pieces, but I don't want the runtime itself to be proprietary. If AWS Lambda back in the day had been a proprietary compute runtime with its own JavaScript implementation, I'm sure we wouldn't have launched serverless functions on top of it. AWS Lambda — the whole environment they run it in is a very proprietary cloud environment, but it just runs Node. Anything you run in a Node-based Lambda function, you can take and put on a DigitalOcean instance and run the same. We've always felt that was a pretty core piece of our runtime layer, which is why we didn't go with Cloudflare Workers. You can't today take a Cloudflare Worker and just run it somewhere else. I know they've announced their intention — maybe not coincidentally, in the wake of our announcement of building edge functions on top of Deno — to open-source the runtime behind Cloudflare Workers, which is great. I'm happy that we can incentivize them to do that. But as of today, you can't — there's no source code you can actually go access.

00:42:15 - Anthony Campolo

Yeah. I've never actually thought about that before, and I would have assumed it was open-source. I agree with you — if they're going to really push the web forward, you have to open-source that.

00:42:27 - Matt Biilmann

Yeah. And they've announced their intention to open-source it, but as of today, the Cloudflare Workers runtime is a completely proprietary runtime.

00:42:35 - Anthony Campolo

Thank you. That's super, super interesting. You want to talk about Jamstack Conf?

00:42:38 - Matt Biilmann

Yeah, absolutely. Really excited to be able to put on an in-person Jamstack Conf again after so long. We've had some very fun digital events over the last couple of years, but nothing is the same as actually getting the whole community together in person. The last in-person event we had was at the end of 2019 in San Francisco, and it was just so energizing to see — especially because this whole landscape is built of all these composable tools and frameworks and different companies that are always used in combinations together. It was such a good feeling to actually have all the core people of that ecosystem in a venue at the same time and see all the interactions, discussions, and connections being built at those events. So I'm very excited to put on the next real-world Jamstack event in November. It'll be November 7th and 8th, if I'm remembering my dates.

00:43:42 - Anthony Campolo

Yeah, that sounds right. Both Chris and I plan on being there. So for any listeners who want to come hang out, or any other guests who want to record some cool in-person podcasts like we did at Remix Conf, we'll probably be doing some of that at Jamstack Conf.

00:43:54 - Christopher Burns

I think the Jamstack Conf is a great place to just get people who would not necessarily speak to each other on the internet into a room, because you never know what might come out of it — new partnerships, even new technology.

00:44:07 - Anthony Campolo

In-person shitposting.

00:44:10 - Christopher Burns

Maybe so. And hot taking, for sure. One of the things I can say is you can currently put in your email address on the website, jamstackconf.com, and you'll get a 20% discount on the ticket. And secondly is the Jamstack — the Jamstack questionnaire.

00:44:28 - Matt Biilmann

That's not the real one. The Jamstack survey. The Jamstack survey.

00:44:30 - Anthony Campolo

The Jamstack survey. Yes.

00:44:31 - Matt Biilmann

Yeah, you should absolutely go fill that one out. We want as many people from the whole community to participate. It's always super interesting to be able to see how the whole ecosystem evolves.

00:44:42 - Christopher Burns

Do you find that when the survey results are compiled and released, you find yourself thinking over the year, "This is going to be a big deal," and then the survey comes out and you're like, "I was right," or "I was wrong"?

00:44:58 - Matt Biilmann

There will always be tidbits where you're like, "Okay, yeah, I thought that, and it totally happened," and then there'll always be pieces where you're like, "Oh, this is really interesting to see." One of the things that was interesting in the last surveys was — not unexpectedly — that pretty much everybody had used WordPress at some point. Most used tool, but also the most disliked tool in the whole ecosystem in terms of satisfaction rating. But then it was really interesting to see that there was a small subset that had been using headless WordPress, and they were actually pretty happy. That was just one of those interesting tidbits — interesting to see that shift happening.

00:45:35 - Christopher Burns

This year you focus a lot on where we work from. Why is that important to the Jamstack?

00:45:40 - Matt Biilmann

That's more in general about insight into the whole modern web ecosystem. I think when you ask why it's important to the Jamstack, a lot of the way we thought about this architecture is that it's also very inherently related to how people work. This idea of being able to decouple different services and have a self-standing web UI — that's not just a programming-model-centric thing, it's also an organization-centric thing. It makes it easier for a web team to execute at their own speed without a hard dependency on every deployment depending on the back-end team. It means the web team gets to choose their own tooling instead of getting it dictated by someone who chose WordPress for the back end, meaning now you have to write PHP. A lot of these architectural pieces link to the organizational piece. And I think it will be really interesting to see the ways we collaborate and work together in companies shift as companies embrace remote working more and more. The places the Jamstack community is driven from, and will get together, will also evolve as we probably get more and more global participation in the community. So very interested to see the survey reflect all these changes in how we work together and where people are able to work from.

00:47:00 - Christopher Burns

Yeah. And I think it'll be really interesting to see what correlations can be made — whether people who work from home constantly are more edge-driven with the latest technologies, or more relaxed with taking everything three years behind the bleeding edge. And I think that's about it for today's episode. Would you agree, Anthony? Is there any more questions you'd like to ask?

00:47:22 - Anthony Campolo

No, that was awesome. Thank you so much for being here, Matt. Why don't you let our listeners know where they can find you on Twitter?

00:47:28 - Matt Biilmann

I'm on the Twitter handle @biilmann, which is my hard-to-spell surname, B-I-I-L-M-A-N-N. So do follow me there, or just search for Netlify CEO and you'll probably find a usable link somewhere.

00:47:42 - Christopher Burns

Great. And thank you so much for coming on here today. I think that's all for now.

00:47:47 - Matt Biilmann

Yeah, thank you. This was a lot of fun.

00:48:19 - Anthony Campolo

Cool. That's good. That'll be a cut.

Composability with Ishan Anand and Scott Steinlage (Podcast)
Snaplet with Peter Pistorius (Podcast)
Astro with Fred Schott (Podcast)
RedwoodJS with Peter Pistorius (Podcast)
Remix with Kent C. Dodds (Podcast)