#140 Matt Biilmann discovered the JAMStack

Transcript

⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes

Matt Biilmann 0:00
Gradually, I started sort of getting to know more people that that that worked in the field of technology and worked as developers and so on, and I would like excitedly start talking to them about, like, back in the day around the using CSS instead of tables and so on. And I'd see like, oh, wow, that wasn't really like, at that point, like common knowledge and so on. Like people, people are still using tables, even if they were working professionally and so on. Right, and they started getting this glimpse that like that programming is actually a very new field and, and no-one really knows what they're doing in reality.

Tim Bourguignon 0:47
Hello, and welcome to developer's journey, the podcast, bringing you the making of stories of successful software developers. To help you on your upcoming journey. My name is Tim Bourguignon. And on this episode 140, I receive Matt Bellman, Matt grew up in Denmark, where he trained as a musician, and a music journalist. But far from music, he has been building developer tools, CMS, and web infrastructure for more than 30 years, Matt is recognized for coining the term game stack. He's also an active participant in open source, but you might also know him as the CEO and co founder of netlify. Matt, I'm really thrilled to have you on Welcome to that journey. Thank you. Great to be here. So Matt, the show exists to help the listeners understand what your story looked like, and imagine how to shape their own future. So let's go back to your beginnings, shall we? Where would you place the start of your developer's journey?

Matt Biilmann 1:52
Yeah, I would probably have to place it when I was like, around 10 or 12 years and had a extremely bad handwriting, and not a lot of engagement in school. This was like back in back in the 80s. So personal computers were just sort of starting to become a thing I had seen, like, the first couple of friends get a Pong console at home. I think the school might have gotten like one or two computers that people could could experiment with. And, and something about computers were just like, deeply fascinating to me. So I really started lobbying my parents a lot to get a Commodore 64 in and they weren't quite sure it was expensive at the time and so on. But I think there was a moment where one of my I think it was probably my Danish teacher at the at the time that they were so frustrated with my lack of will to actually write longer things in in hand that she told my parents like maybe just try to get him one of those computers and see if that changes it and make some actually write some stuff in so so they agreed and and and found a use Commodore 64 and the and that became my my first server in a computer. And of course, back then when you turned on a Commodore 64 all it would show you would just be a blinking cursor, right? And then you would have to type stuff to make it do stuff in and I think just even just that interaction, just that sense that you could type stuff to a machine and it would make it do stuff was just incredibly fascinating. And then when I learned a little bit about programming and sort of had some tutorial from a printed magazine where you could like take a program and write into the computer that would show you a little sprite of it and it belonged gliding across the screen I think that's the first moment where just really remember that like fascinating with being able to write something that created some sort of universe behind the screen right in and and then I was hooked on that him it wasn't like I mean obviously I was 1012 years old. So this was nothing like as a step towards becoming a programmer as such it was just my initial fascinating with fascination with with computers and and what they could do and something that that's stuck with me until today. While I spend a lot of time on that I also spend a lot of time in the world of like literature and music and in the humanities and so on in and it never really thought about like to me programming was always just like a hobby and procrastination and a passion. I like I never even really thought a lot about it as a career. I started when when I started studying, I started studying musicology at university and then it took is a secondary In Comparative Literature, started a master's in cultural studies while I also started working as a freelance music journalist for the, for the websites of the Danish radio, which is sort of the main public service broadcaster in Denmark. And so, I wasn't actively like, at that point pursuing programming as a as a career, but I still kept building all kinds of stuff on the computer, right, like I would, I would write games for, for fun. I, I remember, around the time, when EVE Online was in close private beta, I was hanging a lot around in the chat rooms around that and, and, and some guy was running like this network of gaming related sites, and we're looking for someone to to build a CMS to keep them up to date. And I just like to, like, I can do that and jumped in and just wrote like a CMS with like, some swap connections between like, three different sites. So you could update them in one place and have the propagate to everyone I lead a build, like a whole sort of database driven website in, around like, user submitted data from, from EVE Online on all the different like spaceship types and weapons and so on, we can come in and discuss and so on, but it was always just like, I mean, I didn't charge anything for it. And, you know, I thought about it, this anything special, and I always had this, I always imagined that I was just doing this as a hobby. And out there in the real world, there were all these, like real programmers that actually knew what they were doing. And that like, like, that knew all this stuff. And I was just messing around, right? Him and and imagine that people that had studied for this and so on, they would totally know what they were doing. And I was just like, googling stuff on the, on the internet and, and figuring out my way through it, right. And then then I guess, gradually, gradually, I started sort of getting to know more people that that that worked in the field of technology and worked as developers and so on then, and I would like excitedly start talking to them about, like, back in the day around the using CSS instead of tables, and so on. And an artsy like, oh, wow, that wasn't really like, at that point, like common knowledge and try and like people, people were still using tables, even if they were working professionally and so on, right, and I started getting this glimpse that like that programming is actually a very new field. And no one really knows what they're doing in reality. And do and, and that was sort of the back step, then then, at that point, I am, I met a girl then and, and she was from Madrid and I took a trip to Madrid visitors, she came visit me and then it was a bit more went a little back and forth. And then decided that I would like move for a couple of months to Madrid and finish up my master's thesis in the music and technology in and went there and started that and then quickly realized that I would, I would want to be staying in Madrid for for a lot longer than just a couple of months. And I also at the same time realized that in the market for writing about music in Danish in Madrid, was not that large. So so that was sort of the time where I had to start coming up with a plan B in and then I had been programming forever. And I had started noticing that maybe I wasn't so bad at it. So I basically just started like building stuff I built like an online Sudoku challenge where people could go in fill out a Sudoku and then send the same pseudocode to a friend that would also fill it out. And then they could get timed on like who did it fastest. From that on I started building this like browser based space scheme where I found a, I found in all the scientific article around simulating the formation of star systems from an accretion disk that was meant to run on a supercomputer in like 67, right. And I and I saw that, okay, that whole process, you could run in a web request, like then like on a normal like on any web server, right, because computers had grown so fast. So I found I could run that process and generate like infinite solar systems and then build a UI on top of it so you could travel from planet to planet and explore and so on. And I was working with that but showed it to some people and then got an offer to to join a Denver based startup back in back in this like this rest of time when everybody were either doing In mobile gaming, or our social networks, it was right around the time when when, like, sort of Facebook was coming along, and so on, right and in, and I said yes to two to joining this Denver based startup just in just in return for stock options, no, no salary or anything. And the started started working on dead and it was like, an early rails project, I became really familiar with rails a, got a chance to work with some, some good developers and very, like sort of organically became like the lead developer on the project. It never really went anywhere, right. And those stuck up since sure didn't work anything. But it did mean that that that I started getting some experience then and I went because it was in Rails to the very first conference about Ruby and Rails, in the in Madrid. At that point, I was, I was still learning Spanish, and was not very good at it. So going to a to a full conference where all the talks were in Spanish and sitting through like a whole day of talking about rails in Spanish. By the end of that first day, I was sort of really mentally exhausted and thinking like, I had originally planned I would go to like the conference after party, and so on. But I thought like, I have to just go risk my brain a little. I don't think I can take any more Spanish today. We went to the metro. And I took took a car, and the after like two stops, I noticed that I had picked the metro going in the wrong direction in but I did notice that the direction the motorist going in was taking taking me to the stop where they sit the after party was so I got offered that stuff. And since I hadn't planned on going I didn't know anything else than it was some way around that stuff. So I spotted someone from the conference and walked over and asked like, Hey, are you also going to the after party and in Spanish style? He said like Yes, yes, but we need to get some tapas first join join us in and the inner join the few people from from from Spain there and in head tapas. And we spoke about what I was doing. And I told him I was working for a startup in the US and showed them what I had been working on shoot them to games and so on. And about a month after I I started it says it says senior rails developer in in in their company in with an actual salary. so strangely enough, my my first ever paid job as a developer was as a senior iOS developer in in Spain. And then, somehow, within the span of a couple of years, in I went from senior rails developer to then being tech lead for the project I was on to being a technical director to then becoming CTO for the company. Yeah, so so. So quite a address, like a hectic journey in and after that, I then started a startup together with the founders of that Spanish company. And that brought me to the Bay Area in where I'm still based now brought me on to the path of building like an online developer platforms. That in turn, spurred a lot of the insights that that led led me to see that there was this fundamental shift happening in how we were building from the web starting to decouple the front end presentation layer from the back end infrastructure layer. And I saw that there was like a huge gap in tooling for developers to build that way and ended up founding a netlify. Two, together with one of my best friends back from Denmark, and launch that in, in 2015. And in and today, of course, nullifies is at a place where we are serving more than 600 million unique visitors to sites hosted on our network. We have on boarded around one and a half million developers to our platform. And, and, and and the jam stack. As a we ended up calling that architectural shift of decoupling the front end presentation layer from from the back end is today really like becoming more of a standard nomenclature.

Tim Bourguignon 14:24
Indeed an interesting ride.

Matt Biilmann 14:27
Yeah, I wonder how useful it is to anybody else. Because I wouldn't necessarily recommend like that if you want to developer Go Go study musicology and cultural studies and then suddenly move to another country and change careers and so on. It's, it's not necessarily very prescriptive, but I do think I would recommend being very open minded to to change and opportunity.

Tim Bourguignon 14:51
Hmm. Let's unpack a couple of things. First, I would like to come back to the very beginning because I have a very opinionated question, and I need to clarify this. You were growing up in Denmark? And at the age of 10, you were playing with a C 64. Did you have a manual in Danish or did you have to learn English on the fly?

Matt Biilmann 15:16
I kinda, I kind of had to learn English, there was some books, like there was a Danish author that wrote that wrote a fairly big book about programming on the Commodore 64 in Danish. So I got that one book. And again, back then there was no internet or anything, right, like, so like, no World Wide Web as we as we know it, right. So you had to, I had to go to the library and get and get books about programming. And then there were apart from that there were in magazines, local, deenis magazines about computers, right? And they would, they would come with program listings that you could take and type into the computer. And you would spend a lot of time like typing every letter, as it were, and then you would try to run the program, and there would be some typo somewhere. And the end, you would get your first lessons in debugging by by trying to figure out like, why is it not working? And what did I type wrong? And and, and that would sort of be the intuitive way also to start unpacking? Like, what did all those words on the paper actually do? Right? Because in order to figure out where something is broken, you have to start building a mental model of like, what what's actually happening,

Tim Bourguignon 16:34
I find it fascinating that all those hurdles, early on, didn't seem to slow you down. And you really wanted to know more and really wanted to discover how this thing is working what you can do with it. And so nothing was stopping you there. That's, that's interesting.

Matt Biilmann 16:53
I've always been, like driven by those kind of like puzzles and challenges, right? And figuring something out. Like I get very stoppering. If If I'm in front of a problem that I haven't quite figured out like I have a very hard time then putting it away and just seeing if it doesn't matter.

Tim Bourguignon 17:14
Is this a hidden way to manipulate you to

tell you:
"no, it's not working, give it up, that won't work"

Matt Biilmann 17:21
Who knows? I will neither confirm nor deny that!

Tim Bourguignon 17:29
We'll see if I get some some some secret mail after the show. Yes, indeed. I'll let you know or not, we'll see. I was asking that because that that's exactly how it started with me. Or for me, I started. The first games I played I think wasn't where the LucasArts games at this point and click LucasArts games, obviously, all in English, and I was French, I was about 10 years old as well. I didn't speak a word English. And I spent hours just with a dictionary on my lap trying to decipher what it was supposed to do. And I'm pretty sure I never ended one of the games was such a hurdle to just flip through the pages and try to understand word by word webs. appositive. But apparently, you had a drive that it didn't have.

Matt Biilmann 18:16
Like even bigger challenges was the Sierra quest games that came before the LucasArts games like Space Quest and Kings Quests and the like that aim that had like a written interface. So you had to write what you wanted the character to do. And now it's even, like, even harder to figure out in English.

Tim Bourguignon 18:37
Absolutely. Yeah, we Europeans didn't have it easy, didn't we?

Matt Biilmann 18:46
I do think there's something to that, that that's like a really valuable skill as a as a developer, right? Like it is, I always send to say that to be a really good developer, you have to have a very, very high tolerance for frustration, right? The truth is that that all the time when we work as a developer, you run into things that that can be extremely frustrating because it's seemingly some benign little step standing between you and a result and you don't know why something is not working right like all the way back from the first like your type thing your whole program for a magazine and for some reason it's not working right like and you have to have some tolerance for seeing like this is really frustrating and I want it to work but I have to figure out what's wrong right? But the same will happen to as you like that that never ends right like when when you're writing like programs for distributed system is something you run into weird issues where there's just for some reason something is broken. And and you have no idea how long of a time it will take for you to get to the bottom of like what what's wrong with this system where where is there like what what is it? I'm not understanding I think part of going into the to the journey of really becoming a pro developer is to accept that that's a part of life, that's a part of your daily job to get hit with frustrating moments like that and and push through them.

Tim Bourguignon 20:14
That's a pretty dark way of putting it.

Matt Biilmann 20:21
You're then also good at getting yourself graded, right? So every time you get through one of those, you're like, I did it.

Tim Bourguignon 20:30
Indeed, and sometimes, it works, and you still don't know why. And then it's the other way around. But exactly the same, the same frustration. I know what you mean, I know what you mean. And it's gonna be more of this. When we grow into more parallelism, and synchronicity. Right now, it's still on the web and still debuggable. But when the CPUs are going to do this for us all the time, and we're going to use a more functional way of programming, etc, it's going to be become interesting. Let's hope the tooling follows to help us with race conditions and stuff like this...

Matt Biilmann 21:11
That's that that's a task of like, of great tooling and great architectures, right. And it's been one of the, it's been one of the thoughts around pushing something like the jam stack architecture, right? Like is that to be efficient, as a developer, you have to try to, you have to try to cheat in some way, right? Like, you have to try to find ways where you can narrow the scope of what you have to understand to debug your problems, right. Like, if if to build anything, if you had to understand all parts of the stack, all the way down to the transistors on the on the chip, and the voltage, vibrations and like, all the way up through like the actual Bits and Bytes represented on on the computer all the way up through the registries, and CPU caches instructions, all the way up to like, to what happens in the browser, right? Like, then it would be, of course, impossible for a human to actually program anything, right, like so. For us to be efficient in building things with with with computers, we have to build these layers of abstractions, that gives us some level of black boxes, where we can see all the stuff that's in inside this black box, I don't need to understand in order to, to to work efficiently, right, like so a lot of the role of architecture and of frameworks and so on is to, is to bring that kind of encapsulation of stuff in and decoupling of of elements that allow you as a developer to focus on a specific problem and a specific part of the stack without having to constantly in your head whole, the whole like complexity of everything that's going on.

Tim Bourguignon 22:56
Before we go deeper, would you want defining the #jamstack for your listeners who don't know what and maybe give us the the Enlightenment story how you came to to coining this and then how the scheme into into your life if there is or there.

Matt Biilmann 23:09
Yeah, of course, I mean, their, their idea behind the game stick is fundamentally to decouple the web presentation layer from the back end layer, and then try to compile the UI in and deliver it straight from from a location very close to your user, and then pull in the data as needed. You can either pull in data during compile time when you're building out there, the actual UI, or you can pull it in it at runtime in. But the idea is that separation of like the web experience layer, pre build that as much as possible, get it really close to the user and then talk to API's and services. And it kind of as an architecture, a as an architectural approach kind of mimics how we build applications for for for mobile phones and mobile devices, right? Like we build an app, we ship it to the device. And then we talk to all these different API's and services, right. Whereas Additionally, on the web, we would build apps in a way where we would have a big monolithic server running, and everything you did, which sort of interact through a request and response cycle going all the way through the trend application server that would talk to a database and build the HTML on the fly and send it back to you right, in what what I started seeing was this trend of actually just decoupling the front end layer, the web presentation layer in thinking about that layer more as we would say, as an application, right, and thinking like you can pre build that you can compile it, so to speak. And then and, and, and then that layer can can talk to different data sources, but you keep that clear, decoupling of the sort of underlying business logic and API services, and then the actual user experience layer in And, I mean, it really came about, for me working in this developer tooling space for a long time the company I was at in Spain, we build websites for small to medium businesses, but at a very large scale. So we would build something like 100 websites a week in. And, yeah, it was really about mounting a machine around that, right. So I ran the teams that built there, there, the different iterations of the platform that their designers would come in and do design with, that the clients would use for content management, and that powered every single website all the way from, from initial brief into production hosting him. And then I started the CMS company in Spain, together with the founders of that Spanish company, where we were basically saying, okay, we just went through all the all the experiences of building this kind of platform in house that's built like a multi tenant cloud hosted CMS that I like agencies and other professionals can use when, when they are building sites for their clients. And I was working with that. And that that was like, that was still based on the traditional sort of monolithic application structure, right, where everything would go through that request response cycle, and get rendered on the fly and so on. And then we're trying to add all these different caching mechanisms in front end, and so on, right, like to make it more efficient. But you would still sometimes have have bad things happening. Like, I remember, one, one user managed to create a site that would they do 63,000 database queries for each request. A and and the system was was like most attended running a bunch of stuff. So so like, when the site just first went up, like no one noticed, but it was from for a site for a really big company and that big company at some, they put like a big advertising campaign out there pointing to the site. So suddenly, it got like a huge spikes of traffic. And each request would like try to do 63,000 reads to a database, right, and, and it just took down the whole system. And stuff like that would happen. him and I know, I just really weren't familiar with all the operational hassle of operating that kind of infrastructure Where, where, where the front end presentation is like, deeply intertwined into your database layer, all the security things, you have to be aware of all the scalability and reliability things, you have to be aware of all the all the hardships of trying to implement reasonable levels of caching of the actual HTML without a breaking people's expectations of freshness, and so on, right, in, it's a really complicated system with a lot of nuances. And most people that work on the presentation layer, don't necessarily understand the nuances of the database layer and database indexes and query efficiencies. And the other way, people that are experts in that typically don't have a great appreciation for like front end frameworks, and what you can actually do in the browser and so on, I started seeing some of the work around some of the early static site generators, like Jay Cole and the like. And I started seeing the work on the early front end frameworks like back then it was like cappuccino and sprout CO and that then turned into Ember. And then Angular came along and so on. And later on, we got like react and view and swell, and so on, and so on, right. But I started to see this new world of front end applications essentially running in the browser, or this world of pre built static front ends. And I had a hard look at, at everything people were building with this with with the CMS I had built like everything from from e commerce sites, to airport sites to in to his newspapers and so on. Right. And, and I could see that there was no technical reason that you couldn't fundamentally take the whole presentation layer all the HTML and templates and CSS and pre build that and put it directly and then on on, put it directly in that caching layer instead of on the web server. And then decouple like the the specific dynamic parts into self standing API's and widgets that that you could talk to from the browser. him and I could just see that they that if you did that, it would solve so many of the troubles that that I would have to deal with all the time in terms of like how to get the performance good enough how to avoid the system going down how to handle like massive traffic spikes in and it would allow you to take that precompiled front end and distribute it not just to one at cash but to a globally distributed edge network with points of presence all over the world. And, and, and I started like, really being convinced that that architecturally This was the architecture that would make sense for the web in the future. But at the same time, I could also see that if you didn't give people like coherent tooling to work in that way, then it would just be very, like, very hard to actually develop projects, you would need like a CI CD pipeline, you would need like object storage and a caching layer, you would need to think about things like atomic deploys, and instant cache invalidation in, you would have to think about how to build like staging environments, and so on, you would have to think about like how to synchronize with the data sources, you would want to pull content in from during build time, and so on. And, and I could just see that, that, that there was all this external stuff that wasn't like part of like the clarity of the architecture, that as a developer, you would have to put up and put together and maintain and operate and so and that that meant that even if architecturally, this approach, made a lot more sense and could give incredible benefits in in scalability and performance and cost and simplicity. It wasn't really viable for normal teams of developers to build in this way. And that's when I started to talk a lot with with Chris, who is my co founder today, and which one of my best friends back from from Denmark, back in my music times, we used to go to a lot of jazz concerts together and always end up starting a jazz club until we sort of figured out the economics of jazz clubs and quickly gave up on that idea in bodying. But I started talking to him and he was sitting as Chief Digital Officer and partner in a large full service agency at the point running like the digital strategy for the Walmarts of Scandinavia, and so on, then a and, and all of the problems of like building and maintaining these monolithic applications and scaling them and the cost of hosting for them, they really resonated for him. And he could also see that if he went with this new architectural approach that at the time didn't even have a name, right, like and went to his developers and were like, let's build in this way. They, they wouldn't know where to get started. And even if they did it like they would hearts together, like a CI CD service, and a CDN service and an object storage and a bunch of shell scripts to manage like updates and validations. And web hooks from from, from headless CMS and so on, in a way that they couldn't possibly come to a client and say, like, here, we build your all this stuff. Good luck maintaining it, right? So that's, that's when our idea of netlify got born of really seeing like, What is it? What would it take to make this architecture really viable for developers? Right? Like, we already believed that it was better architecture, but it just wasn't viable to actually build and operated, right? So So we went in and said, like, Okay, what are all the pieces that we need to put in place to, to make it really appealing and frictionless to work with. And as we started doing that, we also started seeing that, that there was a lot of people doing things in that space, both in the space of static site generators, and headless CMS, but also in the space of single page application frameworks, and progressive web apps, and so on. And none of them had like a nomenclature for talking about this general decoupling and this general shift. So we started seeing the, we just had a need for some nomenclature, to actually be able to give it a name and say, like, we're working with this architecture and have it be something that people could in could talk about sn architecture, and we started thinking a lot about what could we call it and so on. And to be honest, one day, I was sitting with it with a developer friend over a glass of red wine and and we started talking about what could call it thing and he said, like, it could be something like similar to the LAMP stack, and so on. But but for for, for a new kind of stack, a different stack, I mean, could be something like that, that has a sound to it like a gem stack. And then I was like, What would gem stack stand for that. And then I was like, it could be like JavaScript API mock up, because this is like the fundament fundamental elements of the stack, right? You pre build mock up, that's kind of like what you shipped to the browser. And then you use JavaScript, this main runtime in the browser, and you talk to all these API's and services for anything that needs to be dynamic, both at build time and at runtime and so on him, that that that became the birth of like, of the word jam stack. And then we just started talking to a lot of people in the industry and sort of circulating the term and little by little people started picking it up because because it was useful for for everybody, right, it's useful to finally have just some words to to talk about this architectural approach without going through the whole Description of like, we're sort of decoupling the front end and the back end and talking to these different API's and so on. And suddenly there was a word for it. And that started to unlocking a lot of a lot of collaboration and a lot of like category growth.

Tim Bourguignon 35:13
It's very interesting how we need something, a name to call something to be able to talk about it. And without this, we're stuck. And discussion doesn't happen. But here's the name. And even better if the names resonates with somebody, and your job on retrofitting the terms in there, by the way, and then we can talk and that that's fantastic. And very nice story, a very nice person. Sorry, thank you for thank you for that. I would have one one question, which is going more into internet Wi Fi. You just described all the tooling that you felt was missing, and which is basically what netlify is doing right now. And then some? How did you approach the problem of choosing what to do first? And what to do next? Because you obviously couldn't build the whole thing. Right away? How did you find what is the highest priority?

Matt Biilmann 36:03
That's a really good question. And it's something that that I think, is a skill that takes really long time to learn as a developer, right? And it's a really valuable skill to start looking at a really big problem. And seeing like, how can I break this problem down? Not not just into smaller problems? But how can I break it down to a journey where I can build the first little bit of it, that has value in itself. And that, and that, if that value shows out to be real, it will validate or, or like it will either prove or disprove whether the rest of the thing has value right? In. So I think that's a skill that's really valuable to get good at right? Like to mentally start looking at problems in that way and seeing like, okay, what's the biggest vision of a problem, right? Like, what's the biggest thing it could be like? And we already when Chris and I started talking, right, we started talking about a very big system and a lot of things involved in it, right? But then really boiling down, okay, what's the smallest step I can take in direction of that vision that will bring value on its own? And for me, that started with a small MVP, called bit balloon, that the very first step was to say, like, Okay, what if you could just drag a folder with your HTML and CSS and JavaScript onto a website? And then you would get a URL? instantly, right? That in itself feels like it's part of this idea of decoupling, right? Like, it's part of like, you have this HTML and CSS and JavaScript, like, it's the only thing that that you have, you've maybe built it from a static site generator, you've handwritten it or whatever, right. But you think about that as your package you want to put on a URL, right? Him? How can I make the friction of getting that front end onto a URL as small as possible, right, and the smallest step I could imagine was like, just drag a folder onto bid balloon calm, and now you're live, right? So I spent like two weeks implementing just that functionality as a spit balloon in and now it's really pragmatic at first, like I build it as a Rails application. Because I already had a Rails application I use the same database and infrastructure already had from from web pop started really like tried to really not focus on being super creative with the technology choices or anything and just really seeing like, what's the shortest step to to to get this to get this idea of like just get a front end live instantly it to work right in and then after the first two weeks has been sort of another two weeks adding like signups and subscriptions and and a payment system and so on, and then then then actually launched bit balloon as and as an MVP, got it out into the world. Him and instantly saw that, that that? Yeah, there was interest in this right, like people found this idea of like, of just being able to put publish the your friend and stuff really appealing. But they also started asking for like more programmatic access to it like outside of dragging and drop it. Could they do it from a CIO even from an API from another application, and so on. Right. So that was sort of the next step of adding COI tooling and API and so on. Right. And, and then already from that, I started having something that in itself was was useful, right. Like you could tie it into other like ci CD systems and publish through API in or you could do manual publishing, or you could build application that used bit balloon as the publishing target and so on. And in the first iteration, even even if it if the vision was to have a distributed network, right, like in the first iteration, it was just serving out of singles. Data Center and so on. The next step then became to say, Okay, how can I take this front end that that people are pushing out and make them sort of infinitely scalable and and globally available. So that became like the next piece of the journey to start building out our own edge network, essentially, right like, and running, like, replacing this idea of your one web server with a network of servers all over the different cloud providers and DNS based, like traffic director to, to, to send the induces to the, to the closest node. And then when Chris came aboard, and we and we launched netlify. The next really important piece, which is really defining for nullifies for today's was the workflow piece, right? Because I think that was our core innovation that on the one hand, we built sort of this runtime layer for for the gem sec, but tied very closely to a workflow layer that takes care of the whole ci CD process and the build process and will listen for web hooks from headless CMS and so on, right? And that that became the next, next, next big, big piece of the product puzzle to build the initial version of that ci CD pipeline right in. And then of course, we kept innovating, right, like after we put that out. And after we raised our first round of funding, we we invented the the idea of deploy previews, where every single pull request will will will build and give you a URL that you can preview that, like how would that pull request look like if you took it to production in we added, like, the idea of serverless functions where you can simply put, like JavaScript functions in a in a folder, and we'll deploy that into a AWS lambda and set up the routing at the edge to go there. In the innovative in terms of our whole it's logic layer with like role based access control at the layer, it should geolocalization at the edge, advanced proxy rules and so on, in and and of course, we keep, we keep innovating now, both on the runtime layer and under workflow layer.

Tim Bourguignon 42:08
That is fascinating. I would have so many questions. But looking at the clock, I'm going to go into a different direction. Did you have, in this original vision you had, did you have some things that didn't turn out to be the way you imagined? And we say that that was my idea, but actually didn't work out this way? Or there was a better idea? Do you have any any story in the in this of this kind?

Matt Biilmann 42:33
I think it was more from a company perspective, there were things we thought we would have to do where we found out there was much better for us to partner with other companies straight like early on, when we started five, we also started building a git base, there's a open source CMS called nullify CMS that's that that's still around us an open source project. But back then we thought that would that that was one of the problems we would have to solve. And then we started seeing like this whole rise of content fall and now sanity and cosmic as and take shape, and so on and so on. And we started seeing like this whole really vibrant ecosystem of headless CMS. And we quickly realized that, that there, it would be much better for us to make it really easy for our users to use all of those solutions, rather than rather than to build our own. Then, of course, back when we started netlify, AWS lamp, there was not really a thing, especially not in terms of like something accessible for the web. So I think even if directionally, we had the vision of the world going in a direction where where developers would write code and not worry about where it ran. That that was, that was something we also went when we really realized, like what it meant had to incorporate it into the architecture and figure out like, what does that mean, when you start having access to those kind of like serverless functions that, that that you can instantly route to, and that you don't have to, to to worry about in. But it's actually been like, in some ways, pretty surprising. When we go back and look like at everything Chris and I were discussing back before we started netlify how how much it's still the same roadmap we are pursuing and still the same vision, then that's part of it. That's also just taken much longer to build than we then we dreamt it would that's still ahead of us now. Many years later, right. But But I think in terms of like, the overall vision of where we wanted this to go and what kind of problems we wanted to solve and what kind of company we wanted to build around it. It's it's actually been more surprising to me that that we've had less drastic changes then then then I would have normally imagined

Tim Bourguignon 44:55
That's very interesting. If you had to to advise somebody "not-to-use the jamstack" or not use Netlify, what would be the the kind of use-cases where you

would say:
"that's not what we're trying to address there"?

Matt Biilmann 45:08
I mean, we're not trying to address building native applications. And we're not trying to address building the debug back end infrastructure layer, right. Like even if you have, even if we have serverless functions, we see them more as a part of the web presentation they are and the server logic you do need for that part, rather than is like, go build all of your business logic there from from the ground up in there, there's this this deeper tooling available. In then there are areas where where, like, where you can say that with the gem stick approach this to very clear cut approaches says when you have like the type of site with the amount of content where you can clearly pre build everything upfront with mistake site generator, and you'll get that they'll give you like, amazing results in like, in in, like knowing the state of every deploy, and a very clear development cycle instant rollbacks, like incredible performance. But of course, there's a level there where as you increase the amount of files, you might not currently be able to pre build everything upfront with the speed you might need for certain things. They are, you might say, you might have set at a point that the jam stack would not be a good fit. But I think it's more question of actually evolving the architecture to to also solve for those problems, right. So we've seen some some steps towards the idea of incremental generation in. And I think there's something to that as long as it fits in with the same architectural clarity where we still feel that you're breaking the request response cycle and defining something that can be built and stored in its server and delivered, then there's part of that way of think, deferring part of the build till till after the site goes live makes makes sense. And then there's a whole world in the other end, where you will just build single page applications like app.netlify.com, where, where the jam stack approach is an extremely good fit. Right. So as I see it, I think, I think we'll see in general, that this approach to decoupling the front end presentation layer from the whole platform business logic layer, I think that it will be like the main approach for how you should approach the web as an as an architecture in the in the future. I think right now, there are gaps in the tooling in certain spaces that gaps in like, in the in the deployment mechanisms, and certainly certain places that that means you might go with something else. And then there are developers that just prefer like, an all monolithic workflow. And, and, and well run with that. But but I don't really think it's because that that there's like this whole set of applications that you couldn't build with the gem sec.

Tim Bourguignon 47:57
No, I agree. I agree. I think the the analogy you made it the beginning, thinking about mobile applications, is really is really speaking to people in this mobile world. You have the app on your phone or on your on your tablet, and then there's only data coming going in and out. That's maybe an extreme and not necessarily was Netlify is advocating for, but it kind of is a great metaphor for for understanding it.

Matt Biilmann 48:22
Yeah. And it's very mentally clear model to work in as a developer, right? Like I don't I don't know, any mobile developers that I've met that said, like, Oh, if only we could change the architecture. So when the user click a button, it we download a new version of the app and show that UI that would be much better, right? Like, I've never heard any mobile developers who say, like, I wish for this, right, like, they would probably say like, that sounds really strange. Why would you possibly do it? Right. But that's been our traditional architecture for the web, right. And there's good reasons for ya. It's been the traditional architecture for the web. But I think the more we can move to a mental model, it feels more like the like the mobile architecture, the easier we make life for, for for for developers and the ECF. We make we make life for developers, the more interesting things they will build and ship.

Tim Bourguignon 49:14
And then there's also what you mentioned at the beginning, "decoupling things". I've run a very small service to gather cfps for conferences. And my focus at the beginning was just getting data in and out. So I clicked some UI together, throw it in Github Pages back then, and use some Zapier automation. I didn't want to get into consider coding anything for that. That was not my focus, my focus would be "Can I get the data at all in there", and when it starts working, then you can consider something else and that's only possible when decoupling is there. And so I agree with what you're saying there. That sounds really really important. Okay, we have reached the end of our time. Both of you There's so many questions I can ask. But it's let's let's bring a twist to those who are usual advice. gems that he meant is, is JavaScript API's and markup. For newcomer, that's a lot to swallow. How would you advise somebody to approach getting up to speed with enough of JavaScript enough of API's? And enough of markup to, to start doing something? How do you thread this, this, this balance to get going?

Matt Biilmann 50:33
Yes, it's hard to say, since I started myself learning in such a different era, I just know what I know myself, I like how I've always preferred learning. And that's different for for from people to people. So this is not necessarily the right way. But I've always liked, like, imagining something that I would like to build, and then figuring out how to build that, right, I can then again, trying from the beginning to practice, like, Okay, if I don't know how to build it out, Can I at least figure out something simpler, that I can build in. And, and and, and then start there and, and make it more and more complex, right, like so start just figuring out how to start just figuring out how to build something with with with HTML and get it in front of people and start learning like the elements what they actually do like what you can do just by adding some style sheets to it and some HTML components and buttons and so on. And, and then start adding, like JavaScript to to make it dynamic, I would probably still, like I'm sort of a little old fashioned. So I'd still probably recommend starting there with the core components rather than jumping right into something like next Gatsby and and immediately writing react components and so on. I would like my my instinct would be to recommend start, start with like, the simple basics of the web and learn what you can actually do with them. And then when you have some grasp of that, in start figuring out what it means to make a fetch request to enter an API and bring in some, some some data in and show it to people. And once you have a sense of that, then maybe go to like, a full framework, like pick up something like next or Gatsby or create react app or swell view or whatever, right, like pick one of them and try to build something with it. And and keep and stay curious. And remember, to to to choose Securian programming is to choose, like, make make sure you have a high tolerance for frustration, because, as I mentioned, you'll just constantly fail, right? Like you'll constantly write something in and it doesn't work. And you don't know why. And you have to sort of just grit through it and try to keep building that mental model until you understand why why isn't it working? And what can I do to fix it?

Tim Bourguignon 53:00
But when it's working oh that feeling!

Matt Biilmann 53:02
Yes, when it's working right? Like then celebrate every victory, like be really proud. When we get something on a URL in front of people. Like Don't let anyone tell you this is just super simple or something right? Like doing these things are hard and celebrate every little victory is that simple.

Tim Bourguignon 53:21
Amen to that. Thank you. Thank you, Matt. You're You're a very busy person. But if the listeners wanted to, to start a discussion with you, where should we should they should the key

Matt Biilmann 53:35
Hit me up on on Twitter. It's my surname @biilmann on Twitter,

Tim Bourguignon 53:45
We'll add it to the show notes.

Matt Biilmann 53:47
And apart from that, I will just say that at Netlify. We just launched a new platform called explorers.netlify.com with the learning resources to to to follow tutorials to go through in that that's also a great place to get started for for beginners with this whole stack. Awesome.

Tim Bourguignon 54:05
And there's only a big "thank you" left to say, Matt. It's been a blast!

Matt Biilmann 54:14
Thank you. It's been fun.

Tim Bourguignon 54:15
And this has been another episode of developer's journey, see you next week. I find it fascinating to analyze how someone came to having a great idea. It is so easy to look at the #jamstack nowadays and say "of course", but realizing this before the fact is a whole different nut to crack. And all it took Matt was to step out of his comfort zone, move to a different country, go to a party it didn't want to go to, say "yes" a lot, work for years in the industry, producing website by the scores and slowly realizing that there was a better way to doing things and finally, acting on that idea. Easy, isn't it? There's one quote that stuck with me, it is "be open to change and opportunities". This sums it up nicely. He said yes, a lot to change and opportunities and it took a while to build Netlify into what it is today. What did you take out of this discussion? Please let me know. You can reach me on twitter at Timothy, t i m o th e p, or we use the comments section on our website just under the transcripts of this episode. And remember what Matt said as well. He thought he was just messing around with websites while the real programmers were out there doing the real stuff to realize at some point that, in fact, no one knew what they were doing in reality. Do you think this has changed since