Frontend platforms, with Matt Biilmann (Netlify) - S04E06
33:09 Share

Welcome to another episode of the Console DevTools podcast. I'm David Mitton, CEO of Console.dev, a free weekly email digest of the best tools and beta releases for experienced developers. And I'm Jean Yang, CEO of Akita Software, the fastest and easiest way to understand your APIs.

In this episode, Gene and I speak with Matt Billman, 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.

We're here with Matt Billman. Let's start with a brief background. Tell us a little bit about what you're currently doing and how you got here. Thanks for having me here. I'm Matt Billman, CEO and co-founder of Netlify. Been at it for a while now. We launched our private beta back in March 2015 and

Right now we've onboarded about three and a half million developers to our platform and we are reaching around a billion unique visitors to sites in Eptron and Netlify every month. So currently keeping busy managing all that. Great, thank you. And 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?

Yeah, 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 letting developers focus on building the front-end code. And we'll handle all of the release management and infrastructure and instrumentation and so on and help you build successful projects.

And it sounds like it's really easy these days. I think 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 where you think you really changed the game? 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 or web store or web application as one big monolithic application. Like 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 them in 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 have full stack web applications in the Ruby and Rails for like 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. And typically the backend developers will have more organizational pull and heavier weight.

So very often that meant that the actual front-end tool set 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, like when we started Netlify, there wasn't even a name for this web building. And we have to sort of come up with the term Jamstack to describe this idea of like building the web experience layer on its own. And typically seeing the backend split into all these different APIs and services, like all the headless CMSs that's really become mainstream now, right? Like all their headless commerce platforms that now also starting to become mainstream and even the big

players like Shopify are starting to think how do we become a hit list commerce platform, right? And that was like what we spotted. But we also saw like 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 object stories and release management and CDN management and figuring out where the bits and pieces that you do need to run on the servers should run and then separate release management processes for those. And then figuring out how does your front end know when there's content changes, setting up complex webhook systems and so on. There were teams doing it, but it was complicated.

not a lot of teams and it was really hard to do, right? Like, so we really, before we started Netlify, made a roadmap around like, what would it take to make it really easy to do? Like, what would it require to make this a really simple way to go for the web? That became the first roadmap for Netlify, right? And now it feels like in the landscape of early adopters and technologies and startups and so on, that approach has really become mainstream, right? Like, I think very few people in that segment will go start a new project

on top of WordPress or like pick Ruby on Rails and write the front end instead of like ERP templates inside 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? Like I think we're just now sort of at that tipping point where we're starting to see this really move from the earlier doctors that are fully on board and into sort 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?

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? There's still ways to go, I think.

I think we've realized part of the vision, right? Like I think this kind of front end cloud layer that we pioneered and where we really built the first one, right? Like that's even now becoming a competitive space, which is a healthy sign, right? Like it's a sign that now it's like a real thing. It's not just Netlify or this.

A lot of them out there by now, Gatsby Cloud, Roussel, Amplify Console, Azure Static Web Apps, Cloudflare Pages, and so on, right? Like it's starting to become a real category 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 interfaces

APIs and services that they have both internally and that they buy externally, and how that fits into the architecture. How to actually make the data from all of those available through your 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 sort of more the architects and the people responsible for like, how do we think about this? Not as a single web project here and there, but as like an architecture for our company. And then I think there's also still some work to do on the other hand, especially when we are more in the landscape of marketing sites or e-commerce, but even applications as well, right? Like I think

As we are retooling this whole landscape, some of the tools you would get from a WordPress or a Groupon in the old world, or from some of the full stack frameworks in the old world, like 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, a sense that they have a better world to develop in than the one they moved away from. And 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 suppose the more modern way of building things from scratch now is TypeScript. And you've got Gatsby, which I think you've acquired recently. And there's Next.js and all sorts of other

frameworks. Swellkits, Solid, Noxt, Beatpress, Astro, right? Like there's a really wide landscape. And 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 folded onto it, right? And I think that's a big difference in this, but also the challenge, right? Like as we start decoupling these pieces, there's then like sort of the recoupling, okay, how do we still make it as intuitive as it was before?

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 like really fast evolving and can shift around a lot. But for us, it's all about

enabling the ability to build those frameworks and move fast in that framework space. We've never believed in... Other companies in our space have built way more of a strategy of building a whole stack around a framework, which has some clear advantages, but we've always believed more in that, especially at larger companies, you inherently start having many different frameworks, especially as time progresses.

We're sort of more thinking like, 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? Yeah, I think that's really insightful. Software is just inherently heterogeneous. And I believe that any company that's trying to homogenize is phony.

fighting too much. Yeah. Yeah. And especially the larger the company gets, right? Like you start doing acquisitions that comes with their own tech stack. You start just having legacy projects that you don't have the resources to migrate to something new, right? Like it's just the reality of any large company. It's different for early stage startups or even growth startups that might be more like simpler in their 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. 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. Yeah, especially in the JavaScript field.

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 it's because of the way it's been designed is just so popular because I suppose it's easier to understand bringing in the components, all that kind of stuff? Why do you think that's been able to maintain its position?

So, ironically, I think it might be a little bit about to change because to some degree, I think it's maintained its position because it had relatively small surface area and it was relatively similar for a very long time, right? And the team has been working on making some really big changes, but they've also taken a very long time. So, in reality, sort of the surface area has been relatively simple. And 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. And I think it was also a very unopinionated framework. So if you look at some of the largest React, if you look at the presence on the React and the web, it's easy to think that it's all about Nix and Gatsby, but large one is Wix, right? Like they adopted React for their component system, right? Like it's all over. If you read tutorials on

WordPress and like if you just look like a React and Gutenberg, you'll see lots of tutorials and how to use React components for the visual page build off 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, right? Like all over the place.

And 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. And I think that gives them some really cool opportunities, right? Like building an end-to-end framework that has like a stronger view on the world. But I think it might also mean that some other tools might start slotting into that more pictures. Like we just need components. Don't throw in a whole opinion of how the end-to-end world should look like.

and we might start seeing some more fluctuation in that whole space. - Yeah, very interesting. And I suppose, where would you go today to, if you were 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?

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? Like we have a runtime layer specifically adapting to Nix that'll give you like 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...

I would look a lot on what kind of project I'm building. For example, at Netlify, since the beginning, we always use pretty different technologies for our main marketing side and our app. So our app is a pure React app, not using any framework. It's actually React, Redux, single-page application. It makes a lot of sense. All of our uses are basically

desktop users or on fast devices and it's all a logged in experience right like i think that makes sense and then our marketing side was always like very light javascript originally built with hugo the 911c today i might start with something like astro for that right like and 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 like, 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 React server components and suspense and hooks and all of that. But while adding like 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 like a few core primitives and everything is sort of just side effects of those benefits.

But again, I think there's a little bit of fragmentation about to happen in the landscape just because as the React team gets more opinionated, there's a lot more opportunities to re-simplify for specific use cases and build tools with simpler mental models. And then I think long-term, we'll probably see some much more drastic changes. Like right now, what we're seeing happening around generative AI,

It's probably going to change a lot of how we interface with computers over time, right? Like 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, right? Like rather than with a human.

And 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 like five, 10 years from now, the distinction between React and Solid or Next and Gatsby and Astro is just almost not a relevant thing anymore. 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. And this was something you obsessively stuck with. And that was an experience that you told the team they could never break. And 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? And has that evolved as Netlify has progressed?

Our whole model has evolved a lot over time and will keep evolving, especially as we are 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 all these sort of next generation adopters. But early on,

as we started Netlify as a new product, right? Like, first of all, we really thought from the beginning and played out well, right? Like, we really thought about our journey as moving in concentric circles, right? Like, first, we had to...

meet the sort of core innovators in the space. And we really sought out like people that were building at the time, building static site generators, so building single page application frameworks and working in specific places where those were the tools 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 those our first adopters, first evangelists, right? Like

The next was sort of like 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 even 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 like, how do we reach them? And I think it was a lot about thinking through that kind of developer when they are...

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? And 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? Like 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? Like 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 like a great starting point, right? Like every, especially every one of these developers, they also very keen on sharing what they learned over the weekend and we need a blog for that.

But let's be fair, a lot of us are also very bad at actually getting any blog posts written. So there's a certain tendency that I've done myself of like re-architecting your blog over the weekend and writing a blog post about it.

how you build your blog, and 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. And 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 and my change is alive instantly, right? It took me 30 seconds to go from like,

Finding a site generator through having something live on a URL that I can share with others, right? Like 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 like, wait, this feels really powerful in general, right? And then we could connect that with like when that developer is then at work and thinking through,

oh, wow, we have a new campaign coming up, right? And we need to build a new website around it and 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 like 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. And then we start getting in a company and then we can start building a relation, right? So early on, that was very much the motion. Now, of course, as we're scaling and going more and more into larger enterprise projects,

some of those motions start changing a bit and so on, right? But we still want to keep true to our goal of delivering a great experience to

any excited weekend adopter that want to go maybe today not just write a blog but maybe try out solid js and planet scale and build something cool with dino running at the edge and so on right like and give them a sense of like wait what i could set all of that up in the in a few seconds and write a globally distributed application talking to a database without doing anything but writing code and pushing it to get up

- And 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 suppose Neon if you wanna 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. - 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, like this Jamstack architecture is probably what they're going to go at where the web developers will be working on the web UI, but they'll probably not

be working like I don't think if you go to those larger companies like if you take some of our customers like Twilio or Dr. Sign or Unilever or something I don't think they'll suddenly like

throw their core business data into a globally distributed edge database and have their front-end developers access that data directly through SQL and the edge, right? Like, they're probably still going to have, like, core API teams that will probably be working more in languages like Go or Java or C Sharp. Some cases, maybe Rust. In some cases, Ruby and Rails and Python and so on, depending on where they sit, right? Like,

That builds APIs and then they'll probably have teams build around digital experiences that builds applications, websites and e-commerce and mobile applications that fetches those. So I think the use case where you will see web teams building directly on the edge, directly with Nia on a planet scale, a cockroach, a 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, like, 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 it will probably end up becoming more of a...

caching story and reality, right? Like 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 like, we're going to move all of our business data to an edge database.

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 like centralized data. I think that'll be the typical approach. I think we're seeing some of that from Shopify and their remix acquisition and their strategy around that, where they're

A lot of projects, namely trying to use Remix, will just run into that problem that data is not at the edge. 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? So that starts making a lot of sense, especially for that kind of e-commerce use case. And then on our end, part of,

why we did the Gatsby acquisition is to build out the product line that they started called the codename Valhalla, which is really an idea of building like this content hub 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 and

And 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 like 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, like Shopify's API.

or in terms of data sources that might really not be like your old Drupal install or your PIM or whatever you need to actually get data out of and into the UI around, right? And I think

That gives us a great potential to help companies solve these problems of like, 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 like 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 kind of patterns. Thanks, Matt. Another question is, have there been shifts in web and tools that have caused you to rethink your

some of your roadmap or goals? And if so, what have those been? I mean, it's a fast changing space and landscape. So we've always had to stay on top of it, right? Like today we have a whole pillar of engineering called the framework pillar that have people just constantly working

making sure that anything the framework authors can come up with is integrated into our way of deploying and operating and running and so on, right? So 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 like a lot of interest in running sort of streaming rendering at the edge that we have, like initially when we build our edge functions,

In the first iteration of that, we weren't thinking that much about that use case. We were thinking more about like simpler decision making at the edge, like routing decisions, personalization, desisting, authentication decisions and so on. And now we are seeing that that layer, like 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 like 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 definitely 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 the architecture to go. Yeah, that makes sense. Well, before we wrap up, then I have two lightning questions for you. The first one is what interesting dev tools or just tools generally are you playing around with at the moment?

So right now I'm playing a bit around with both SolidJS and Astro and the ActivityPop protocol. It's been really cool to see. I mean, at Netlify, we always had this idea of like making the web better because the web is sort of the open platform that doesn't have any single corporate owner, right?

And I think a lot of people sort of 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? And I think that's re-energized a lot of the landscape around building federated social services, both in the Mastodon landscape and in tools like Noster and so on. And that's something I find fascinating.

really, really interesting and find connect well with some of the roots of what the web means. So I'm playing a bit around with that. And then, of course, as everybody else, I'm playing around with the new generative AI tools. Yeah, I really hope RSS comes back. I'm always annoyed when I see a blog and there's no RSS feed. True, true. But I think that will also be a lot of interesting potential of making it really easy to add

activity pop federation to your personal blog, for example, like what would it take to just make a release that you just turn on and you don't have to run like some multi-user mastered on instance, you would just like deploy a blog, but have it interact with that ecosystem. Like why shouldn't that be trivial? Yeah. And then finally, what's your current tech setup? What hardware and software do you use every day?

At home, I'm on an old MacBook, not even the modern M1. So I'm not fully up to date there yet. And 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? So typically, all of my tool sets are pretty basic in that way. Excellent. Well, unfortunately, that's all we've got time for. Thanks for joining us, Matt. Yeah, thank you. This was great. Yeah, thank you. Thanks for having me.

Thanks for listening to the Console DevTools podcast. Please let us know what you think on Twitter. I'm at David Mitton, and you can follow at console.dev. Don't forget to subscribe and rate us in your podcast player. And if you're playing around with or building any interesting DevTools, please get in touch. Our email's in the show notes. See you next time.