How mobile apps led to a change in web architecture
In this episode, we talk about Netlify, Jamstack, and modern web development with Matt Biilmann, CEO of Netlify.
Ben Halpern is co-founder and webmaster of DEV/Forem.
Mathias (Matt) Biilmann is CEO of Netlify, a company he co-founded in 2014 and today is one of the fastest growing web development platforms. He has been building developer tools, content management systems and web infrastructure for more than 30 years and is recognized for coining the term “Jamstack.”
[00:00:01] What you build and where it takes you shouldn’t be limited by your database. CockroachDB, the most highly evolved distributed SQL database on the planet, helps developers build and scale apps with fewer obstacles, more freedom, and greater efficiency. So you can forget about the database and trust that it just works. Sign up for your forever free database and get a free T-shirt at cockroachlabs.com/devdiscuss.
[00:00:27] Cloudways is a leading edge Managed Cloud hosting platform built for your PHP projects. If you simply wish to focus on your business, Cloudways is the way to go. They take over server management and security and free uptime that you can dedicate to growing your business and acquiring new clients. If you want to give them a try, use promo code, DevDiscuss.
[00:01:15] MB: I think what really led the JAMstack to be a successful term was that it was just an inherent need for a lot of different people across the industry to have a vocabulary and they connected what they were doing to a broader theme of modernizing the web.
[00:01:40] BH: Welcome to DevDiscuss, the show where we cover the burning topics that impact all of our lives as developers. I’m Ben Hoffman, a Co-Founder of Forem. And today, we’re going to be talking with Matt Biilmann, Co-Founder and CEO of Netlify, and coiner of the term JAMstack, and we’re going to get into all of that today. Thank you for being on the show.
[00:02:00] MB: Thanks for having me.
[00:02:01] BH: Before we get into Netlify and JAMstack, can we get a little bit about your background as a developer?
[00:02:07] MB: So as a developer, I started programming when I got a Commodore 64 at the age of 10 or something like that, just turned on the computer and you had a blinking person, you had to write stuff to get it to do anything, right? So it was sort of a very natural progression into having to figure that out. Let’s say that I ended up studying musicology, comparative cultural studies, and literature before I ventured into actually being a software developer, worked a bit as a musical journalist, and then moved to Spain, changed careers, at that point became a software developer for a Denver-based startup, working remotely, and then got hired by a startup in Madrid where I started out as a developer and then became a tech lead, technical director, director of development, and then finally CTO of the company. Then after that, I started a couple of my own companies and those ended up in co-founding Netlify.
[00:03:11] BH: Were you surprised that this is the path your career took? Is this what you were expecting?
[00:03:15] MB: It was, for sure, not the beaten path from studying musicology to running a tech company in San Francisco. So that way, there’s been plenty of surprises along the way, and I think I had a strong urge to build stuff and trying to find the way I could build the most impactful stuff that I had it in me to build to at first like diving into programming to a level where I was sharing what I was building and got hired based on that and then sort of tried to continuously step up into more roles of higher responsibility just to have more impact and try to drive more of what we could build in the companies I were in and then started my own company just to really be able to build what I saw as being necessary for developers. By now, of course, like over the trajectory of a company like Netlify, your role constantly changes from the initial days where the first version of Netlify, I wrote all the code and ran all the infrastructure and was the one getting paged every night if anything was wrong with the service. Now we are more than 150 people in the company, running all kinds of web properties for more than 1.8 million developers, ranging from hobby projects to really big mission-critical properties for enterprise companies with a large team running it and so on.
[00:04:39] BH: JAMstack is a term you coined, and the idea has become pretty popular in the web development community and is a big part of Netlify itself. Can you define JAMstack for the audience, for anyone who might not be familiar with this architecture?
[00:07:46] BH: So Netlify was doing JAMstack before the phrase JAMstack became a thing. And this is the idea you all had in mind, and it’s pretty impressive to have been able to name this, popularize it, and really grow this entire ecosystem around the idea.
[00:08:04] MB: I mean it was also very much a way of describing that, of course, there is a niche of static sites that gets filled with this kind of tooling. Right? But today, for example, Twilio’s log in experience, when you login to Twilio, that’s running on Netlify, right? Netlify itself, when you login to app.netlify.com, it’s running on Netlify, right? When you sit down on a Peloton bike and open up the UI, that’s a web UI serving out of Netlify. It was important for us, for people to understand that this decoupling of frontend and backend is much bigger than the idea of your static assets, which is a big part of it and a big driver. Right? But it was not just sort of an attempt of coining it differently and so on. It’s really important to make it visible to people that this was actually like a broader architectural approach. And then as time goes on, we’ve seen that approach also evolving, right? We’re now starting to talk about it as a sort of architectural approach within the JAMstack that we coined the Distributed Persistent Rendering. Again, one of the key ideas behind the whole JAMstack approach was this idea of being able to reason about the state of your website and having a very strong caching agreement between developers and platform providers. That’s what allowed us to do a lot of the magic of like push to get new things alive. They are completely predictable, they cast in each network, but they can be instantly rolled back. You can have the proper views around them and so on. Right? With Distributed Persistent Rendering, we’re sort of looking into as we evolve the type of projects that people are checking with this JAMstack approach, especially as we’re seeing companies building e-commerce platforms with hundreds of thousands of products in their catalog or they’re like, “How can we get around like just the limitations of having to have one built that builds everything and then deploys while still keeping the same mental model for developers?” I was like, “How can you still always know?” When someone goes through a URL right now, what’s actually going to happen and how can we still establish pretty strong caching contracts that can allow providers to abstract away all the complexities of like when should you cache while also giving more flexibility than one build state, one deployment state? So Distributed Persistent Rendering is sort of one example of starting to evolve also the architectural patterns within the JAMstack and starting to say, “Okay, we can have a site that has like an initial built into planning step.” And then in that build step defines a set of on-demand builders that will build a set of URLs each, but they will still build each URL essentially once, right? So you still have a different mental model initiative, different caching guarantee than if you work in a traditional server-side rendering approach that still allows like platforms like ours and others to put in a lot of convention-based default that will give developers a great experience out of the box.
[00:11:42] RudderStack is the CDP for developers. Its 150 integrations make it easy to connect your data sources to all of the tools used by your marketing, product, and data science teams. With RudderStack, you can say goodbye to the headache of managing custom built integrations and easily manage all of your customer data pipelines in one place. Sign up at rudderstack.com to give it a try.
[00:12:06] Cloudways platform offers a choice of IAAS partners, AWS, Google Cloud, Digital Ocean, Linode, and Vultr. In addition, you get a performance optimized stack, manage backups and staging environment where you can test your code before pushing it to live servers. Best of all, composer and kit come pre-installed so you can get your projects up and running quickly. All this power, simplicity, and peace of mind falls right with their brand slogan, moving dreams forward. If you want to give them a try, use promo code, DevDiscuss.
[00:12:41] BH: I discovered Netlify after asking a question on DEV about what the best static site hosts were, and I was pretty disappointed in the overall hosting environment before I discovered Netlify. So I become a satisfied customer. Forem still uses Netlify in small ways. Our core technology is not JAMstack. But it’s just become part of our philosophy and how we use it in certain ways, but you really do want to grow JAMstack to be more and more core technology. It’s not just static sites, it’s not just being high quality service for hosting static sites. There’s a lot more to that.
[00:13:27] MB: It’s this cool concept of simplicity that’s really important to me. I’ve referred a couple of times to Rich Hickey’s talk some years ago at QCon called the Simple Made Easy where he really sets up one category is simple and one category is easy and say like, “They’re not actually the same thing. You can make something really complex very easy to do. But then it’s still very complex and you’ll still have a very hard time understanding it. If you run into any problem, you will get leaky abstractions and so on.” Or you can make something that’s very simple. It might not necessarily be easy. Right? I was just reading a paper about built systems in Haskell around, like, how you can create a set of abstractions that expresses every single possible build system in like 20 lines of Haskell code. Right? And it’s very simple. It’s very beautiful, but it’s not easy, right? It’s very hard to understand and you need to understand monad and applicative functions and so on to really understand the paper. Right? But I think there’s a certain kind of magic that happens when developer tooling can make it really easy to do something that simple. In our product philosophy and in the way we try to encourage people to think about the JAMstack as an architecture, that’s constantly like the access we’re trying to look for, how can we get to that point where it’s easy to do something that’s ultra-simple and it’s simple to reason about. Because that’s also the way that we can give tools that works when you’re like a big enterprise building complex software, but want to do it with a tooling that’s simple and have patterns that are easy to reason about and simple to understand if you run into problems and that still give us that very high sense of instant gratification for an individual developer that comes in and build like a new project and finds like, “Oh, wow! This was easy.”
[00:15:28] BH: As Netlify grows and becomes more ambitious, tries to serve more customers, how are you able to maintain that joyful experience? As things become maybe less simple and basic as an overall service, how do you make sure you’re still able to actually provide that basic, simple service effectively?
[00:15:47] MB: I mean that’s one of the really interesting things. As I talked about earlier, when a company like this grows, your role as a founder constantly changes. In the beginning, I was the one that just had to build it all. I didn’t figure out like how should it be and so on. Right? And then you start bringing your team in and you’re building it together with that team. But of course, as the company grows, my role becomes more and more, “How can I build the kind of company that builds this kind of product?” So a lot of focus over the last year for me has been like, “How do we build a product and an engineering organization that can take ownership of different parts of the product and really understand like those parts of the product in depth and operate independently on improving and evolving those parts of the product? And how can I give frameworks, metrics, feedback that allows them to take decisions on like, ‘Are we evolving in the right direction or the other wrong direction?’” That is to me a really interesting problem as well and an interesting space, like, “How do you build the machine that builds the product rather than the product itself?”
[00:16:57] BH: So you, the founder and CEO of this company, are constantly thinking about things, trying to come up with mental models, simple versus easy, looking for talks. So it’s one thing for you to understand where things need to go, but how do you convey this to your whole team, especially as the company grows to the size it’s become today?
[00:17:17] MB: I think refining the JAMstack, I just published an article in Smashing Magazine on the evolution of the JAMstack and the architecture work we are doing now around Distributed Persistent Rendering. That’s another piece where we think if we can put sort of a mental framework in place for this pattern around splitting up parts of the sites into individual builders and so on, then that’s something that we’ll again see people be able to be creative with. And we’ve already seen internally, Zach, who works at Netlify but also maintains the open source project, Eleventy, really jumping in this concept and doing really cool stuff with it in a short period. So that’s one area where I’m excited about in a similar kind of like that’s opened up a community RFC and talk about this architectural approach and then see how just like the description of it and the ideas behind it can help the community focus their creativity. Then another area that I’m really excited about is the new collaborative features we’ll be launching May 19th. A lot of what we’ve seen is when we are really opinionated around these JAMstack architectures and build a product that’s opinionated around that in a way that developers using Netlify, they have to somewhat adhere to that. You can use functions as escape hatches and so on. Right? But if you navigate within that JAMstack architecture, then we can give you a lot of workflow out of the box that you would otherwise had to spend years working on with your dev ops teams and so on, things like instant deploy preview is for every pull request you make and instant rollbacks, so like immutable deploys for any point in the past of your site and all these features you get out of the box with Netlify. And then we’ve really seen an opportunity to say we can go even further in how we can help teams of not just developers, but also the other stakeholders, product managers, designers, marketers, and so on, collaborate on building together and releasing together. That’s something that we’ll be showing to the world soon and that I’m really excited about.
[00:20:15] MB: Yeah. I mean, we’ve always had a very clear philosophy of being framework agnostic, right? I’ve always seen Netlify as a tool that doesn’t go into the process of what’s core to being a front-end developer, but that takes away all the friction from all the things that sits around it. Right? So our goal is that front-end developers can really focus on picking the right tool for the job, writing the actual user experiences and creating value, and then we can take all the friction out around doing stuff together, running CI/CD pipeline, so operating infrastructure, monitoring, scaling, all of those pieces. Right? We’ve always had an approach where we want it to be a step above the actual framework layer because I don’t think there’ll ever be like one framework that will be ideal for every project you will want to build. Right? There are use cases where Eleventy is fantastic and there are use cases where… of course, I would never try to use Eleventy in the areas where Gatsby is a really good fit and then there are areas where if you try to shoehorn them into Gatsby, it’ll probably just be really painful. The same goes for Next or for or Create React App and so on. Right? And the other part is that the framework space is just continuously evolving so fast, right? Gatsby was huge a year ago and now it seems like Next is having a lot more traction. Maybe next year we’ll see something like Nuxt, this wealthy kid taking over, right? This is a landscape that’s evolving very fast. For us, we’ve always had this viewpoint that we want to focus on that architectural layer on the whole experience of like how can teams be efficient when executing lots of different use cases. And then we just want the whole JAMstack ecosystem to grow. Right? The best thing for us is that that whole ecosystem gets really big and that there is a healthy ecosystem with lots of different layers and providers and choice and optionality and so on. So from our point, we are more focused on like what is it our customers want and what can we do for them and what is the right level for abstraction for us to operate on and how to build the best product in the ecosystem.
[00:22:59] Scaling an SQL cluster has historically been a painful task. CockroachDB makes scaling your relational database much easier. The distributed SQL database makes it simple to build resilient, scalable applications quickly. CockroachDB is Postgres compatible, giving the same familiar SQL interface database developers have used for years. But unlike older databases, scaling with CockroachDB is handled within the database itself. So you don’t need to manage charts from your client application. And because the data is distributed, you won’t lose data if a machine or data center goes down. CockroachDB is resilient, adaptable to any environment and Kubernetes native. Hosted on-prem, run it in a hybrid cloud and even deploy it across multiple clouds. The world’s largest banks, massive online retailers, popular gaming platforms and developers from companies of all sizes trust CockroachDB with their most critical data. Sign up for your forever free database and get a free T-shirt at cockroachlabs.com/devdiscuss.
[00:24:01] BH: Have you, Netlify, had any major missteps strategically, any priorities you’ve focused on which really didn’t turn out to be useful for the business or your customers?
[00:24:12] MB: I don’t know if we’ve had like very big missteps. We’ve had things that we thought would be more important than it turned out to be. Like early on, we thought we would have to invest a lot into building like an open source CMS to make sure that there were options for developers to give the right kind of tooling to marketers and to other team members and so on. And there, we quickly learned that there was such an evolution going on in the space that it was much, much better for us to really partner with all the different CMS companies that were already trying to solve that problem and would have much more resources and time to invest into that. So that was one area for sure where we saw like, “Okay, it makes sense for us to focus much more on our partners and really help people be successful with them.” There’s been similar pieces here and there like that. Right? But I wouldn’t say we’ve had and you sort of baked that and say, “Okay, this risk is fundamentally the wrong direction we are going in.”
[00:25:12] BH: What’s it like working alongside the browsers to further this architectural principle? So since you began working with JAMstack and popularizing this idea, browsers have shipped a lot to probably help you out. What’s that been like?
[00:25:27] MB: I mean Chrome did a lot for the general ability to run real applications in the browser. I think if we just look at the really big picture of things, if I went back 10, 15 years or something and told a group of designers, like, “You will replace Photoshop with a URL,” they would probably have been like, “No. Wait. That’s not going to happen.” Right? But today Figma is pretty much like the tool all of our designers intuitively reach for when they need to design anything. Right? It’s collaborative, it’s instant, it’s no app download or anything. You just open a URL and it’s there, right? The same with spreadsheets. By now, it’s more where I get an actual Excel file versus just a link to a Google Sheet, right? Again, just core software that we’re using every day that’s now just browser based. Right? And even tools like Slack that might still be an app are also built with browser-based technologies and so on. So I think it’s really important to just acknowledge how incredibly far the browser has come today and essentially being the operating system that powers the most popular applications we’re using for productivity and for day-to-day work and so on. And I think that will only keep accelerating. Right? I think we’ll see video editing tools moving to the browser. I think we’ll see tooling that before might have been only imaginable as desktop software or phone applications just be fully browser-based. And of course we hope to play a big role in helping make it easier for team to build or maintain and operate this kind of software, but it’s been amazing to just see the overall evolution of what’s possible take place.
[00:27:46] BH: So JAMstack is described as using mobile patterns for the web the way data is fetched asynchronously and such. Do you have any plans to get into the mobile space at all? Any cross compatibility? Or is Netlify and your work strictly web focused right now?
[00:28:09] MB: So far, we’re a very web centric company. Right? It’s part of our mission that we want the web to win. Right? We’re a big fan of the idea of having your own domain that you can publish what you want that’s not controlled by like a specific corporate institute that owns that app store or the like. Right? So we’re pretty bullish on the web in general as a company and I’ve always been excited about things like progressive web apps and so on. It’s fun to see now with the Epic lawsuit against Apple, that Apple are using progressive web apps as their argument that the App Store is not really a gatekeeper because everybody can build a progressive web app and get just as good results. They have been sort of at the same time holding back by not really supporting all this stuff that Chrome has been pushing in Safari, but maybe parts of these battles around like the positioning of the app stores will actually force them to also start investing more and really allowing the web as a fully native mobile experience. So out of the box, we’re more focused on supporting that journey and then we have a lot of clients that are using web views within mobile applications as a really common way of shipping and iterating and building the UIs much faster than constantly going through a traditional update and release process.
[00:29:48] MB: I’m always a very curious person. So I’m always reading up on all kinds of things, whether they are related to my domain or completely foreign, reading a book right now called Galileo's Error on theory of consciousness, for example, it’s not exactly related to Netlify. Of course, in things that might connect more with my domain, I’m always looking, always following close along with what’s going on in the space around what you would call Web 3.0 in like true federated applications, typically related to blockchain technology, and so on. I’m very much not a crypto speculant or anything like that and don’t hold any crypto and so on, but I’m very interested in the underlying technologies around federation and what they could mean long-term both to the way we build systems independently of all of that technology and to future evolutions of how we distribute applications and information and so on.
[00:30:50] BH: Do you have any advice for someone who’s in a similar boat to where you were towards the beginning of this journey, founding and building Netlify? Maybe they have a technology they’ve cared about, they have a young startup, and they’re looking to grow. Any advice for that person?
[00:31:06] MB: Yeah. It’s a good question because it’s like, again, where to even begin, you learn so much along this journey, right? And that’s the main advice. Just be ready to constantly learn and grow and enjoy the ride and focus on your customers and the enjoyment of building something that they can get real value out of.
[00:31:30] BH: Thanks for being here, Matt.
[00:31:31] MB: Thanks for having me.
[00:31:41] BH: This show is produced and mixed by Levi Sharpe. Editorial oversight by Jess Lee, Peter Frank, and Saron Yitbarek. Our theme song is by Slow Biz. If you have any questions or comments, email [email protected] and make sure to join us for our DevDiscuss Twitter chats every Tuesday at 9:00 PM US Eastern Time, or if you want to start your own discussion, write a post on DEV using the #discuss. Please rate and subscribe to this show on Apple Podcasts.