Console

David Mytton [00:00:04]: Welcome to another episode of the Console DevTools Podcast. I'm David Mytton, CEO of Console.dev, a free weekly email digest to the best tools and beta releases for experienced developers.

Jean Yang [00:00:15]: And I'm Jean Yang, CEO of Akita Software, the fastest and easiest way to understand your APIs.

David Mytton [00:00:23]: In this episode, Jean and I speak with Matt Biilmann, CEO of Netlify. We discuss what it was like deploying code before Netlify, whether there is about to be a fragmentation in the JavaScript ecosystem as React gets more opinionated, where state and data fit into the Jamstack model, and how you might reach developers with a new project today. We're keeping this to 30 minutes. So let's get started.

David Mytton [00:00:48]: We're here with Matt Biilmann. Let's start with a brief background. Tell us a little bit about what you're currently doing and how you got here.

Matt Biilmann [00:00:55]: Thanks for having me here. I’m Matt Biilmann, CEO and Co-Founder of Netlify. I’ve been at it for a while now. We launched our private beta back in March 2015. By now, we've onboarded about three and a half million developers through our platform and we are reaching around a billion unique visitors to sites and apps running a Netlify every month. So currently keeping busy or managing all of that.

Jean Yang [00:01:23]: Great, thank you. So most of us here may have heard of Netlify. We're Netlify users at my company. But for people who aren't familiar, could you just give the audience a quick description of what Netlify is?

[00:01:36] Matt Biilmann: Yes, of course. We're a cloud platform that helps teams build, deploy, and operate websites, web applications, web stores, really focusing on reducing all of the friction around actually building valuable experiences for end users and leading developers to just focus on building the front-end code. We'll handle all of the release, management, and infrastructure, and instrumentation, and so on, and help you build successful projects.

David Mytton [00:02:05]: It sounds like it's really easy these days. Developers who have only started in the last couple of years are probably used to amazing experiences of getting code into production really quickly but that's not really how it always was, right? Can you go back a little bit in the past and describe what it was like before Netlify and whether you think this would have been inevitable, whether you were there or not, and why you think you really changed the game?

Matt Biilmann [00:02:29]: It has been pretty amazing to see how this way of building has really become the default now, right? Early on, when we started, the world we were in, were generally people building every single website, a web store, a web application as one big monolithic application.

If you looked at the dominating tool sets at the time, if you're building websites, you're probably using WordPress or Drupal, or Joomla. If you were building, I mean, a large enterprise, you might be using Adobe Experience Manager, and Sitecore, and Episerver. Or if you're building e-commerce, you're probably either writing liquid templates for Shopify or working with Magento. Or if you're building applications, typically, you’re at full stack web applications, in the Ruby on Rails for more forward startups, and typically Java or .NET or so on for larger enterprises, right?

That meant that, often, almost all of the front-end technology was basically decided by the backend platform. Typically, the backend developers would have more organizational pull and heavier weight. So very often, that meant that the actual front-end toolset that people were building web experiences with was sort of like a set of tools almost chosen from them and very constrained by how they fit into some larger backend that needed to handle data access and business logic and all of that.

What I saw early on was that I really believed that we would move away from that model and move to a model where we would decouple the actual web experience layer into its own layer that web teams can build and deploy independently and, hopefully, much faster. But I also saw at the time that there wasn't sort of any tooling or infrastructure or workflows around that.

So early on, when we started Netlify, there wasn't even a name for this web building. We had to come up with the term ‘Jamstack’ to describe this idea of building the web experience layer on its own and typically seeing the backend split into all these different APIs and services, all the headless CMSs that it's really become mainstream now, right? All their headless commerce platforms that now are also starting to become mainstream. Even the big players like Shopify are starting to think how do we become a headless commerce platform, right?

That was what we supported. But we also saw when we got started, that this seemed like inherently a better way of building for the web, but people were not able to do it because every project meant setting up with object stories, and release management, and CDN management, and figuring out where the bits and pieces that you do need to run in the servers, should run. Then separate release management processes for those. Then figuring out how does your front-end know when there's content changes, setting up complex webhooks systems, and so on, right? There were teams doing it. But it was not a lot of teams, and it was really hard to do, right?

So we really, before we started Netlify, made a roadmap around what would it take to make it really easy to do. What would it require to make this a really simple way to go for the web? That became the first roadmap for Netlify, right? Now, it feels like in the landscape of early adopters and technologists and startups and so on, that approach have really become mainstream, right? I think very few people in that segment will go start a new project on top of WordPress. Or pick Ruby on Rails and write their front-end, just instead of like pick templates inside of a Rails app or stuff like that, right?

But on the other hand, it's important to remember that most of the world is still building in the old way, right? I think we had just now sort of hit that tipping point, where we're starting to see this really move from the early adopters that are fully on board and the interest of the early majority of all the large mid-market to enterprise companies out there that are trying to figure out, okay, this, obviously, works better, and we can see the results companies are getting from it. But how do we get there?

Jean Yang [00:06:33]: Great. Thanks, Matt. So related is the question about the original vision of Netlify. Would you say that you've realized it, and now it's a matter of spreading it around the world? Or are you still partway along the entire path to realizing the full vision?

Matt Biilmann [00:06:51]: There's still ways to go, I think. I think we've realized part of the vision, right? I think this kind of front-end cloud layer that we pioneered and where we really built the first one, right? That's even now becoming a competitive space, which is a healthy sign, right? It’s a sign that now it's a real thing. It's not just Netlify. There's a lot of them out there by now with Gatsby Cloud, Vercel, Amplify, Console, Azure Static Web Apps, Cloudflare Pages], and so on, right? It’s starting to become real categories that we've really, from the beginning, been the leaders of.

But I think, especially as you're thinking about these larger companies adopting this, there's still a lot of work to do in terms of figuring out the interfaces between all these different APIs and services that they have both internally and that they buy it externally and how that fits into an architecture. How do we actually make the data from all of those available through web teams in a simple way? How do you not end up feeling that every single project starts with a lot of blue code to just get data in and out and get services connected? How do you handle the right layers of permissions and authentication on that layer? There's a lot of areas in that interface layer between more the architects and the people responsible for how do we think about this not as a single web project here and there, but as an architecture for our company?

Then, I think there's also still some work to do on the other hand, especially when we're more in the landscape of marketing sites or e-commerce, but even applications as well, right? I think as we're retooling this whole landscape, some of the tools you would get from a https://wordpress.com/or Drupal in the old world or from some of the full stack frameworks in the old world, giving your marketing people easy ways to go and do visual editing on landing pages and so on, or giving product managers simple ways to set up experiments inside your app and so on. I think as we've decoupled the data sources and the UI and so on, we have some work to do in terms of building architectural patterns, pulling those things together again, and giving everybody, not just the developers, the sense that they have a better world to develop in than the one they moved away from.

David Mytton [00:09:10]: How much of that do you think is tied to language and framework? I suppose you've talked about WordPress and Drupal which are PHP and still very popular. But I just suppose the more modern way of building things from scratch now is TypeScript. You've got Gatsby, which I think you've acquired recently. There's Next.js and all sorts of other frameworks.

Matt Biilmann [00:09:30]: SvelteKit, Solid, Knox, to VitePress, Astro, right? There’s a really wide landscape. I think the way it's really coupled is that now all of those web developers have frameworks that are really built for them to build UIs with. Where before, they were working inside frameworks that were built for getting data out of a database, defining business logic around it, running server-side workloads and so on with some front-end stuff bolted on through it, right?

Again, I think that's a big difference in this but also the challenge, right? As we start decoupling these pieces, that’s in sort of the recoupling. Okay, how do we still make it as intuitive as it was in a WordPress setting to actually get your product and commerce data into that front-end framework and make them feel like they know each other? And how do we make it as easy to build tooling for the other stakeholders on top of that in a world where you know that that front-end framework layer is really flexible and it can shift around a lot?

But for us, it's all about enabling their ability to build those frameworks and move fast in that framework space, right? We've never believed in – like other companies in our space build way more of a strategy of building a whole stack around a framework, which has some clear advantages, right? But we've always believed more in that, especially at larger companies, you inherently start having many different frameworks, especially as time progresses. We are sort of more thinking if we know that that is like a shifting landscape, how do we be good at supporting each of them, but also be good at building tooling that works across all of them?

Jean Yang [00:11:15]: Yes. I think that's really insightful. Software is just inherently heterogeneous, and I believe that any company that's trying to homogenize is fighting too much.

Matt Biilmann [00:11:25]: Yes, yes. Especially the larger the company gets, right? You start doing acquisitions that come through their own tech stack. You start just having, like I said, projects that you don't have the resources to migrate to something new, right? It’s just the reality of any large company. It's different for early-stage startups or even grow startups that might be more simpler in the tech stack, right? But once you have a really large company that's been around for a while, it's also going to have a really large tech stack with a lot of heterogeneous elements in it.

Jean Yang [00:11:57]: Exactly. And the hot tool, the useful tool, that all changes over time. So any company that's older than 10 years old, you can't expect to use anything the same anymore. Yeah, I think that's very, very smart.

David Mytton [00:12:09]: Yes, especially in the JavaScript framework ecosystem. There's always something new and shiny. But React seems to have been basically the popular framework for a very long time. Do you think that is because of the way it's been designed? It's just so popular. Or because I suppose it's easier to understand, bringing in the components or that kind of stuff? Why do you think that's been able to maintain its position?

Matt Biilmann [00:12:30]: So ironically, I think it might be a little bit about to change because, to some degree, I think it's maintained that position because it had a relatively small surface area and it was relatively similar for a very long time, right? The team has been working on making some really big changes, but they've also taken a very long time. So in reality, the surface area has been relatively simple.

I think the key value there was really the ability to think about UI as a set of components that you could work on in isolation. I think it was also very unopinionated frameworks. If you look at some of the largest React, if you look at the presence on the React in the web, it's easy to think that it's all about Next and Gatsby. But a large point is Wix, right? They adopted React for their component system, right? It’s all over. If you read tutorials on WordPress, and if you just look at React and Gutenberg, you'll see lots of tutorials on how to use React components for the visual page builder of WordPress sites and so on, right?

So I think people maybe underestimate how it also got to that level of market penetration by existing in a very heterogeneous world, all over the place. I think now some interesting things are happening. I think the React team is taking a more opinionated approach now and, obviously, collaborating a lot with the Next team. I think that gives them some really cool opportunities of building an end-to-end framework that has a stronger view of the world. But I think it might also mean that some other tools might start flooding into that more pictures. We just need components. Don't throw in a whole opinion of how the Internet world should look like, and we might start seeing some more fluctuation in that whole space.

David Mytton [00:14:17]: Yes, very interesting. I suppose where would you go today— If you're launching something new, say competing with React, how would you get developer adoption? I suppose the question is if Netlify was starting today, how would you go about reaching the right audience?

Matt Biilmann [00:14:34]: From us from Netlify, again, we really just try to give you the best tooling, regardless of what front-end framework you're picking, right? We have a runtime layer specifically adapting to Next. They'll give you middleware features that are only available in our platform and so on, right? But if I were to start a new project today, I mean, I would look a lot on what kind of project I'm building, right?

For example, at Netlify, since the beginning, we always use pretty different technologies for our main marketing site and our app, right? So our app is a pure React app, not using any framework, right? It’s actually like React Redux single-page application. It makes a lot of sense for all of our users, basically, desktop users or on fast devices. It’s all a logged-in experience, right? I think that makes sense.

Then our marketing side was always very light JavaScript, originally built with Google within [inaudible 00:15:32]. Today, I might start with something like Astro for that, right? I think that's one of the things that I would look to. I think each of these different frameworks have the opportunity of getting really great at some use cases. But if they try to be great at all of them, there will just naturally be some more specialized frameworks that gets good at some of them.

I think Astro is looking like it's building a really great developer experience around the concept of let’s build content-driven websites with no JavaScript and few islands of interactivity. There's a lot of websites out there that are really best realized in that format. SolidJS is starting to look really interesting for, “Hey, I'm actually looking to build an application.” I think it's getting a lot of the advantages that the React team is sort of starting to realize through – we have server components in Suspense [inaudible 00:16:32] and all of that. But while adding a very complex mental model, I think Solid is starting to show a way to get a lot of those benefits but with a very simple mental model, where you just have a few core primitives, and everything is sort of just side effects of those.

But, again, I think there's a little bit of fragmentation about to happen in the landscape, just because as the reaction gets more opinionated, there's a lot more opportunities to resimplify for specific use cases and build tools with simpler mental models.

Then long term, we'll probably see some much more drastic changes. Right now, what we're seeing happening around generative AI is probably going to change a lot of how we interface with computers over time, right? It’s already sort of almost at the edge where you can imagine stitching a few tools together, and you would be having this kind of conversation with a program, rather than with a human. I think as that starts to happen, that will start to massively redefine how we consume content and commerce and so on. And it will probably change a lot of what it means to build a website. So I wouldn't be surprised if 5, 10 years from now, the distinction between React and Solid or Next and Gatsby and Astro is just almost not a relevant thing anymore.

Jean Yang [00:17:52]: Thank you, Matt. The one thing I wanted to touch on was I know in the early days of Netlify, you developed this idea that every developer should be able to very quickly build their own blog on Netlify. This was something you obsessively stuck with. That was an experience that you told the team they could never break. I love this idea. And I would love to hear more about how did you come up with that as the one interaction to focus around. Has that evolved as Netlify has progressed?

Matt Biilmann [00:18:26]: Our whole model has evolved a lot over time and will keep evolving, especially as we're now, I think, about to shift from this early majority to figuring out how do we really get this into the hands of the early majority and like only sort of next-generation adopters. But early on, as we started Netlify as a new product, first of all, we really thought from the beginning, and played out well, right? We really thought about our journey as moving in concentric circles, right?

First, we had to meet the sort of core innovators in the space. We really sought out people that were, at the time, building static site generators. So building single-page application frameworks and working in specific places where those were the toolsets and so on to get in front of the people that had already sort of halfway tried to build their own internal Netlify project by project and make themselves first adopters, first evangelists, right?

Then next were sort of the real early adopter crowd, the ones that are always out there, spending their weekends looking for new technologies to learn and adopt, and driven by constant curiosity, and given their competitive value in the marketplace as being the ones that always knows what's coming and what the hot thing is and so on, right? So the next question was how do we reach them? I think it was a lot about thinking through that kind of developer.

When they are starting a weekend project, what are they going to build? What are some of the things that they want to build that we can make really easy for them to actually realize? What's the thing that without us, they might just not build it, right? We saw an opportunity early on when a lot of the space around this way of building was around static site generators and so on, right? They’re a great way for a developer to build a blog.

As a developer, you often want everything to happen in the file system and in GitHub, right? You don't necessarily like the idea of writing your blog post in some content UI and so on, versus just writing them in visual code and being close to the middle. So we saw that as a great starting point, right? Especially every one of these developers, they’re also very keen on sharing what they learned over the weekend, and you need a blog for that.

But let's be fair, a lot of us are also very bad at actually getting any blog post written. So there's a certain tendency that I've done myself up, like re-architecting your blog over the weekend and writing a blog post about how you built your blog, then maybe you never get around to writing a lot more blog posts, but you write that one, right? So we saw that as one of these key things that could connect to the imagination of a developer and help them actually get something out in the world.

Something that was also representative of the “Aha!” moment you would get from Netlify, right? Once you build that, you would get that sense of, “Wow, I just pushed to get in and my changes are live instantly, right? It took me 30 seconds to go from finding a site generator to having something live on a URL that I can share with others, right?” That was such a step change from how the world looked before that I think anyone that tried that experience also got a sense of, “Wait, this feels really powerful in general,” right?

Then we could connect that with when that developer is then at work and thinking through, “Oh, wow. We have a new campaign coming up, right? We need to build a new website around it. It needs to be ready to handle traffic. We don't know how much budget the CMO will throw at it, and so on. I've just tried building this side project, and it was such a superior experience to anything I would get if I tried building this campaign site with the standard tooling of our company. Maybe I can get permission from my engineering manager to use Netlify to build this.” Then we started getting in the company. Then we can start building in relation, right?

So early on, that was very much the motion. Now, of course, as we are scaling and going more and more into larger enterprise companies, some of those motions start changing a bit, and so on, right? But we still want to keep true to our core of delivering a great experience to any excited weekend adopter that wanted to go, maybe today not just write a blog, but maybe try out SolidJS and PlanetScale and build something cool with Deno running at the edge and so on, right? I can give them a sense of like, “Wait, what? I could set all of that up in a few seconds and write a globally distributed edge application talking to your database without doing anything but writing code and pushing it together?”

David Mytton [00:23:08]: What do you think the data and state story is there? Is it connecting over, essentially, the internet over HTTPS to something like PlanetScale or I suppose Neon if you want to use Postgres? But essentially having the data live somewhere else because that was always a very odd thing when I was building applications a while ago. We'd have a separate backend with the database located as close as possible to the application for latency.

Matt Biilmann [00:23:33]: Yeah. So I think, again, I'm still a pretty big believer in that at scale, if you go to larger companies and you look at how they are going to be building stuff, I think, for lack of a better word, this Jamstack architecture is probably what they're going to go with. The web developers will be working on the web UI, but they'll probably not be working— I don't think if you go to those larger companies, if you take some of our customers like Twilio or DocuSign or Unilever or something, I don't think they'll suddenly throw their core business data into a globally distributed database and have their front-end developers access that data directly through SQL and the edge, right? They’re probably still going to have core API teams that will probably be working more in languages like Go or Java or C#. In some cases, maybe Rust, and in some cases, Ruby on Rails and Python and so on, depending on where they sit, right?

That builds APIs and then they'll probably have teams built around digital experiences that built applications and websites and e-commerce and mobile applications that fetches those, right? I think the use case where you will see web teams building directly on the edge, directly with Neon or PlanetScale or Cockroach or Fauna, and so on, they’re probably more the use case around early-stage startups, Greenfield projects, and so on, right?

The larger the company, the more you will start really decoupling that data layer behind an API that gates access, that makes it feel a lot safer for an architect to say, “Now, you can just go build mobile apps and web apps and so on, on top of it. You can’t mess with the data.” So in those cases, I think we'll probably end up becoming more of a caching story in reality, right? How do you take data from those APIs and get real edge-caching benefits around it and make it available to the teams building the web applications in a way that's also really fast when they're building edge applications? But I don't think it will be so much of a question of, we're going to move all of our business data to an edge database.

David Mytton [00:25:48]: Interesting. So the APIs, I suppose, are what's talking to the edge and you're still building all the front-end and the applications using this approach, but the APIs will be there with centralized data.

Matt Biilmann [00:26:00]: I think that will be the typical approach. I think we have seen some of that from Shopify in their Remix acquisition and their strategy around that, where a lot of projects naively trying to use Remix will just run into that problem, that data is not at the edge, so they're not like– So building at the edge then often makes things a lot slower because now you have like– you're trying to do a bunch of round trips to a database somewhere else, and it just takes you a long time to really get something real in front of your users.

But for the Shopify use case, if all you're talking to it, you're just building a headless UI on top of Shopify’s API, then Shopify’s API is already built with a global caching layer, and it's really fast globally, right? That starts making a lot of sense, especially for that kind of e-commerce use case.

Then on our end, part of why we did the Gatsby acquisition is to build out their product line that they started called codename Valhalla, which is really an idea of building this content pop, where you can use Gatsby source plugins to define how do you want to get data out of your different data sources and make it available to the web developers.

Can we then just have a system that keeps that data layer in sync and gives you both at build time, but also at the edge and at runtime, very fast data layer where you can access that data without ever having to do a full round trip to the actual API and where you can do that in a uniform manner across data sources that might already be really optimized Shopify’s API or internal data sources. That might really not be like your old Drupal install or your PIM or whatever you really try to get data out of and into the UI around, right?

I think that gives us a great potential to help companies solve these problems of, “How do we let web teams build these kinds of user experiences across a lot of different data sources, but we get some guarantees that it's always well-behaved, that we don't suddenly have edge code trying to do a bunch of round trips and slowing down everything or overwhelming our APIs with dynamic requests or stuff like that?” Over time, we’ll probably not be the only one helping companies follow those kinds of patterns.

Jean Yang [00:28:19]: Thanks, Matt. Another question is have there been shifts in web and tools that have caused you to rethink some of your roadmap or goals? If so, what have those been?

Matt Biilmann [00:28:32]: I mean, it's a fast-changing space and landscape. So we've always had to stay on top of it, right? Today, we have a whole pillar of engineering called the framework pillar that have people just constantly making sure that anything that framework authors come up with is integrated into our way of deploying and operating and running and so on, right,? Some of that becomes more reactive than proactive, and some of it is more proactive than reactive.

Some of the things – I would say that we're seeing a lot of interest in running sort of streaming, rendering at the edge that we have— Initially, when we built our edge functions, in the first iteration of that, we weren't thinking that much about that use case. We were thinking more about simpler decision-making at the edge, like routing decisions, personalization decisions, authentication decisions, and so on.

Now, we're seeing that layer. When we sort of retooled that layer and launched our current version of edge functions at the start of last year, that was really around, okay, we see that people will want to build full streaming, rendering services at the edge that feels a bit more than applications and that need a bit more weight.

I think, over time, people will also discover some of the complexities of that, and there'll be some split between when you want to do it and when you don't want to do it. But it was definitively one of those where we said, “Okay, we need to really be ready for this and really be a great platform for this, even if that wasn't at first how we envisioned for that to go.”

David Mytton [00:30:07]: Yes, that makes sense. Well, before we wrap up then, I have two lightning questions for you. The first one is what interesting DevTools or just tools generally are you playing around with at the moment?

Matt Biilmann [00:30:19]: So right now, I'm playing a bit around with both SolidJS and Astro and the ActivityPub protocol. It's been really cool to see. I mean, at Netlify, we always had this idea of making the web better because the web is sort of the open platform that doesn't have any single corporate owner, right? I think a lot of people really got a sense of what that meant with the Twitter acquisition and everything that happened there.

When your platform has one owner, that owner can also suddenly change their mind and go do other stuff that you had hoped for, right? I think that's reenergized a lot of the landscape around building federated social services, both in the Mastodon landscape and in tools like Nostr and so on. That's something I find really, really interesting and find connects well with some of the roots of what the web means. So I'm playing a bit around with that. Then, of course, as everybody else, I'm playing around with the new generative AI tools.

David Mytton [00:31:18]: I really hope RSS comes back. I'm always annoyed when I see a blog, and there's no RSS feed.

Matt Biilmann [00:31:25]: True, true. But I think there will also be a lot of interesting potential of making it really easy to add ActivityPub federation through your personal blog, for example. What would it take to just make it really easy to just turn on, and you don't have to run some multiuser Mastodon instance? You could just deploy a blog, but have it interact with that ecosystem. Why shouldn't that be trivial?

David Mytton [00:31:50]: Yes. Then, finally, what's your current tech setup? What hardware and software do you use every day?

Matt Biilmann [00:31:56]: At home, I'm on an old MacBook, not even the modern M1s. I'm not fully up-to-date there yet. In general, I always like to try to stick to relatively simple tools. I've never liked tools that overcomplicate things too much. As a developer, I've always looked for simplicity and tools that give long-term reliability over a lot of complexity for short-term advantages, right? Typically, all of my tool sets are pretty basic in that way.

David Mytton [00:32:31]: Well, unfortunately, that's all we've got time for. Thanks for joining us, Matt.

Jean Yang [00:32:36]: Yes, thank you. This is great.

Matt Biilmann [00:32:36]: Yes, thank you. Thanks for having me.

David Mytton [00:32:40]: Thanks for listening to the Console DevTools Podcast. Please let us know what you think on Twitter. I'm @davidmytton and you can follow @consoledotdev. Don't forget to subscribe and rate us in your podcast player. If you're playing around with or building any interesting DevTools, please get in touch. Our email is in the show notes. See you next time.

[END]