The Jamstack Innovation Fund with Matt Biilmann
Matt Biilmann, CEO of Netlify, discusses the evolution of the Jamstack architecture, edge rendering, composable web services, and the Jamstack Innovation Fund.
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.
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.
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, Next.js, 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 Netlify, 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 Jamstack, 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
Zencaster, for anyone who's curious what he's talking about.
00:31:43 - Matt Biilmann
I'm talking about Zencaster, 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.