Ep. #2, The JAMstack Origin Story

Brian Douglas: Welcome to episode two of JAMstack Radio. Today you've got me and you've also got a special guest in studio, Mathias Biilmann. Mathias, want to say hello?

Mathias Biilmann: Hi there. Happy to be here.

Brian: My main reason for having you here is because this is called JAMstack Radio, and you coined the term JAMstack. Do you want to talk a little more about that and where it came from?

Mathias: If I really remember right, it was maybe not even me that actually coined the term. It came out organically because we've been doing Netlify for quite a while now, and before that I was doing BitBalloon.

Since the beginning of that, we were in this space of modern static websites. That's a really bad description of what we're doing, right? And we kept having that problem that, talking to people about static sites, they would think about something very static. They would think about a brochure or something with no moving parts. A little one-pager or something like that.

What we were seeing was that, and the whole reason we started to build this product was that we saw people building something much more interesting, but with an approach where you really separated the backend from the front-end and separated the build stage from the hosting stage, took advantage of modern content delivery networks and all these things.

All that things that we admired, that made us build this and that were really cool projects, were not things that anybody would think about if you mentioned static to them.

They were highly dynamic web applications. They were single-page apps or they were big, content-driven sites that just used content APIs instead of a traditional monolithic dynamic CMS.

We kept running into the problem of how to actually talk about those projects with a word that actually meant something and had a relation to what people were building. And we started talking to a lot of people, like the people at Carrot. Carrot is an agency in New York that's part of VICE Media, and that built the static site generator called Roots.

Almost all their projects are built with this flow, and none of these projects have things where people will go through the project and say, "Oh, that's a static website," right? All of their projects have dynamic parts and have content teams behind them. Same with the people at Instrument that also were early adopters, and that have been doing this for way longer than Netlify has been around, and have built sites for really exciting companies where they built the build tool called Middleman.

Many of their sites are huge developer heavy projects with hundreds of thousands of lines of Ruby and so on to produce things, but it's built with this approach where the backend is really separated from the front end. And, again, they also continuously ran into the issue that talking about that as static sites made no sense to anybody.

The more we talked to people, the more we could see that there was a need for some way of talking about this new stack that all these agencies were building with, to also talking to Tom Preston-Werner, who's also an investor in Netlify and was the founder of GitHub, the inventor of Jekyll, and GitHub Pages.

He was the same, like, static is just not the right word. Just with anybody we talked to about that, anybody in this space, we started talking about what can we call it. We need some better way of talking about what we are all doing. What can we call it? We had a bunch of different variations of different phrases, and none of them really seemed to work.

I think the first time someone came up with JAM was probably just when I was at home having beers with a friend called Andreas that works at Uber now, and we were just talking about this problem of naming it. He was saying, "But that's really like a new stack, right? Before it was the LAMP stack. You should have like a name for that, like what about..." And he thought a bit, and then he said JAM. I can't remember what it stood for when he said it.

Brian: Oh, it wasn't JavaScript?

Mathias: It was something else, right? But he came up with that word and then, randomly, I thought those letters could be JavaScript APIs and markup. That's actually what people are building.

Brian: It was a bit of name-driven development.

Mathias: In a certain way, right? We weren't really sure. Is that the best way to call it? And then we just started talking with some of all these people we had already been discussing over and over with, "What do we call this?" And I said, "How about JAMstack for JavaScript APIs and markup?" And they were like, "Yeah, that works. That works."

And then we just started, internally, to use that phrase about it. And now we are just seeing that at least it solves the issue of, "How do we talk about this?" How do we call this way of building sites that's really based around JavaScript API and markup? And that decouples the back end from the front end. Typically, you worked with modern front-end build tools, modern front-end frameworks, and so on.

Brian: To circle back a bit, do you want to introduce what you do?

Mathias: Of course.

Brian: During the day.

Mathias: I'm one of the founders of Netlify, and Netlify is a platform for deploying JAMstack sites and apps, essentially. We saw, early on, these really interesting projects coming out of these modern build tools and projects like Middleman and Roots being used to build really exciting sites with.

We also saw that the people building projects with that had all these different tools and services that they needed to put together in a very ad hoc form for each and every project.

They needed to set up like some form of continuous deployment. They needed some kind of object store. They needed some CDN integration, and then they needed to deal with cache invalidation. Because some projects that people would easily run into, to deal-breakers that would make them essentially do something really un-ideal. In the end, just still building a site statically, but in the end, hosting it on a single nginx service somewhere, just to be able to do things like proxy some request somewhere else, do redirects or do GoIP based lookups, and so on.

We just saw that there was this big need, if this JAMstack approach to building sites should be really a viable workflow. There was a huge need for some kind of unifying platform that you don't need to go to five different places and hook everything up manually for each and every project. You can just go in, pick your Git repository, and say "deploy this." And that's Netlify.

Brian: Some people might be, and I've only been in the industry for a couple years, so I don't remember that, like I remember the time before Git. Only because I tinkered. I was more of a tinkerer back then. But not everybody really understands the scope of what it was like to deploy a website and have somebodythat knew all that internal knowledge to do that.

Do you want to explain how JAMstack is different and how the approach is different?

Mathias: I think one of the really important things, that I keep seeing as essentially three really big evolutions, have taken place over something like the last five years where, again, if we go back five years ago, it was really the most normal workflow for front-end developer was to FTP into a production server and change code there.

I've asked that question at a couple of conferences: "How many of you were doing that five years ago?" And it's everybody, right? It just resonates so much with people, and it's something you look back at and think, oh my god, what were we all doing? But that was how things worked, and version control was something that you pretty much had on a lot of your development projects but not on a normal website or a normal webpage.

Web apps were barely around, right? But normal websites, they definitely they used version control and that really changed radically with Git and especially GitHub, because Git came out of very geeky, kernel user groups. And then the people around GitHub, what they managed to do was really to popularize it and make it something that every developer could figure out how to use and turn it into way more than just a version control system but also the main collaboration tool for developers.

Eventually, the way we think about doing deploys and, just in general, pushing code somewhere. And now, I think there's 18 million users on GitHub alone, and it's just become completely mainstream. If you're a developer, you work with Git. Otherwise, you're probably not a very good developer.

The second thing that happened, very much related and in the same period, was this emergence of modern build tools. On the one hand, all the note-based build tools like Gulp, Grunt and Brunch, and so on, when they first came out it was really like every week there was a new one, and no one was settling on anything.

But it was a huge change though, because, first of all, it allowed us to do all these kind of cross compilations of CSS and JavaScript, which meant that, suddenly, front-end developers could start, like today, if you're working on any modern project, you'll probably be using Babel and probably something like PostCSS and, essentially, get access to JavaScript features and CSS features from the future.

Before that, you were so tied to what the browsers actually included.

Whenever there was a new JavaScript feature coming out, and one browser was like, "Oh, that looks really exciting. Maybe in five, 10 years we can actually start using it." But today it's moving much faster, and that's in part because of all these build tools. It meant that front-end developers suddenly started to incorporate the idea of a build tool and compilation process in their workflow, where, again, before that, it was very much like about FTPing into a server, changing some stuff, and hoping things went well.

These build tools changed a lot of the process of how front-end developers work, by having that constant compilation face that suddenly can also include test frameworks and all kinds of things. And it means that to step in a certain way, from building all your fornt-end code that way to just building out the whole website that way, became very small.

Suddenly it makes a lot of sense in saying if we're already compiling these things, why not also just compile all the HTML pages and make sure that we have the content, preferably in our GitHub repository and some API, but that when we press compile we also, instead of pushing it to a server, into a database that then has to build the site every time someone visits it, why not just have this compilation setup we're already using every time we touch CSS and JavaScript. Why not just also have that build out all the sites, all the pages of HTML in our site?

Because once we do that, we can take it and we can push it to a content delivery network, and we can get performance of our site to be an order of magnitude faster, and 10 times faster, and way more, and we eliminate all of the security issues that such a big deal for WordPress, Drupal, Joomla and even Rails, an old application.

Brian: Even older version of IE?

Mathias: Precisely. A lot of their management hurdles of saying, if you put something live and it's powered by something like WordPress or something like Rails, you need to be on top of it all the time. Because at some point, you see a vulnerability in one of the plugins you're using, or something like that. You need to be on top of it enough to notice that and to roll out a fix and to make sure that that fix doesn't break your app.

Often when you update a plugin, suddenly it depends on other libraries. You need to update those, and then you need to update your whole Rails version or WordPress version, and suddenly you spent like days or hours just going through an update that, for you, has no value, just keeps your site exactly the same as it was before. But it's necessary to avoid getting hacked by automated scripts and so on.

Once you decouple this, once you just say during the compilation step, "I'm just going to build out all my HTML sites, pages, and push them to a CDN," then that problem goes away. You no longer have to stay on top of your site in the same way, because the final site doesn't have these moving parts.

The first big thing was the emergence of Git. The second really big thing was the emergence of all the modern front-end build tools and compilation as a part of a front-end developer's workflow. And then the third thing was this emergence of the API economy. That's based on several different things, right?

But one thing is just that if you look today at anything like adding comments to a website or integrating a helpdesk into your web app, getting live support chat on a site, or so many of these things, adding live search to a site, even just adding search to a site.

All of those things used to be things that meant that if you wanted to do any of that, the only real way to do it was to have a big monolithic web app connected to a database that would interact with the request every time you visited. There was no other way.

Because browsers have become so much more powerful, it's way more feasible to just have small parts of the page talk to some external API and give you those kind of functionalities.

That has meant that there's this whole economy of these kind of services that's emerged where you can easily add, like today, even most WordPress installs use Disqus for comments because it's just more convenient than having the comments go to your big WordPress install and go into the database.

And the same, if you were to add a social Twitter feed, there was a time when you would have written that server side and had your server talk to Twitter, and so on. Today, it's just the most natural thing that you'll just plug in a bit of JavaScript and you'll have your Twitter feed appear and it's the way to do it.

Brian: Which was huge. You mentioned the second part being the modern build tools and how that's been changing. But the fact that JavaScript has been even more of a strong player on the web, I think, and the advent of Node coming onto the scene as well, really set the stage for all these build tools to start happening. People started to do a lot more interesting things on the web, for sure.

Mathias: It's been pushing the web a lot, right? And then, these are like the three main improvements that happened. The emergence of Git, the modern build tools, and the whole API economy. And then on the other hand, there's been a bunch of pressures that meant that people also are now really needing to change to this way of building sites, because otherwise the end result is just not good enough.

One big pressure has been with the emergence of mobile performance have become even more important than it was before and has become really something where, if your site is not performing enough, bounce rates will suffer a lot. People will go away.

In a certain way has also become an excuse for some of the big corporate entities like Google and Facebook, and so on, to introduce alternatives to the web that are not as open.

We can see from Facebook that when people go to our website, it's too slow. So that means that more people simply get lost. Instead of using websites, you should use Facebook instant articles and then sell your soul to Facebook, do everything within our UI, but it'll be faster.

Google is doing something similar with AMP, saying you should build this whole completely different thing parallel to your website that gets hosted on Google's infrastructure, and gets indexed better, and so on. That happens to also be controlled by Google, in a way. The only way to counteract that is to make sure that the web itself gets faster and that we just deliver better performance by default.

The other huge issue is that malware have become like a $100 billion industry, and you have all these automated bot attacks that will exploit anything you have out there that's not updated. One of the really famous examples was the Drupal apocalypse where they pushed out a security notice for Drupal 7 saying that this is an exploit in the wild.

"We've already seen automated scripts using it to crawl any Drupal site, and anyone who's running Drupal and that hasn't updated the Drupal install within seven hours of our initial announcement should consider their sites compromised and their servers hacked completely." How many out there are even capable of applying an update within seven hours of it being announced? It's huge.

Netcraft, I think, estimates that 70% of all current WordPress sites are vulnerable to known exploits, typically because of some plugin they use or whatever. But it's become such a big deal that it's become really hard to run a site like that without, at some point, getting defaced or compromised or having a script injected that starts infecting your visitor's browsers, which is really not the kind of advertisement you want to make, and those kind of pressures in terms of general levels of traffic, of course, being larger and larger as the adoption of the internet grows.

If you have a dynamic site, and you're not super sharp about caching it, and suddenly it goes viral on Facebook or something like that, the amount of traffic you get will just kill it. So it will just go down exactly when you need it, unless you really over-provisioned wildly, and then it becomes expensive and hard to manage. These are the pressures that also means that we have to start thinking differently about how we architecture our sites to be able to make sure that the web is performant enough, that's it's reliable enough, and that it's secure enough.

Brian: With this whole JAMstack approach, you mentioned a term, earlier, about separation and having the separation between your front end and then your back end? Do you find that that's overall a more of a trend? I know frameworks like Django and Rails are still around.

Mathias: They're still around.

Brian: And it makes sense for certain people, but what do you, what's your opinion on where the web's going?

Mathias: I think it's definitively going towards more separation between the back end and the front end also, so you can re-use the back end for different kinds of clients. Often now, the front end is no longer the only client speaking through your API. You might also have a mobile app that speaks to an API, or you might have a CLI tool or an app or whatever. But also because the whole concept of microservices, is obviously super hyped right now...

Brian: It's a buzz word at the moment.

Mathias: As with everything, there's always some tradeoffs. And of course monolithic apps made something simpler that can be harder when you have a more recommended kind of infrastructure. But at the same time, I think people are doing it because it makes a lot of sense in terms of, in development in general, just the idea of decoupling elements have always been one of the basic building blocks of how we create abstractions that are easier to think about.

When we can really take components apart and have them very isolated from each other, it typically gets easier to work on those components because we don't have to understand the whole system just to work on one component.

I think that's a bit of the same trend now. You can simply take the front end and make it easier for someone to work completely in isolation on your front end and can know that the person working on the front end is not going to break your servers or accidentally create a performance issue that makes your infrastructure blow up, and so on.

Because he can't, probably because you're working on an isolated component that's your front end. and you have someone else working on a specific API or even the same person working on this specific API. But just changing mindset and saying, "Okay, now I'm going to work on the API for doing orders in my catalog and charge with Stripe. Then you have a very isolated piece. You've made sure it's pretty self contained and does one thing and does it well and is easy to reason about and can be maybe used in a context, as well.

I think that way of architecting applications can be really powerful. I also still think it's early days for it, right? I think there's a huge ecosystem still to be built around it. I think we have now like a ton of these API services that are typically proprietary, but very easy to use. You can plug in comments, you can plug in Facebook feeds, you can plug in something and say, "Okay, now I have a shopping cart," and so on.

I think there's also room for kind of an open-source ecosystem of these kind of very small, targeted APIs that you can use with this kind of JAMstack approach. And I think that's going to be one of the things that's going to be really exciting to see evolve.

Brian: As far as these tools, you mentioned static, and I know that you maintain the Static web generators, staticgen.com. It's like a list of all these different tools to get up and running. Do you want to explain that and how many actual tools do you have on there?

Mathias: I don't have a count now. Actually, I really need to merge in some pull requests that's been hanging for a little. The list keeps growing. People keep submitting new ones, and it's very exciting. There's like 120, 140, something like that now. I'm not even up to date with the exact count.

It's an interesting little project in itself. Originally, it was actually built as a dynamic site that had a little database and talked to the GitHub API, and so on. It was actually a little hard to run because we needed to do a lot of API requests to get the most recent numbers. So we had to start thinking about how we could cache that and do it, but without getting stale content, and so on.

It was actually a real pain to run staticgen.com. At a point, I was really like, "Okay, this makes no sense. I have to actually change staticgen.com to be static." And I rewrote it with Middleman. As soon as we actually had the initial continuous deployment part of our Netlify product, I set it up with that in a way where everyday, Netlify will run a build of staticgen.com. During the build, Middleman will talk to GitHub's API and it will get all the latest stars and forks and issues for each of the projects.

Each project is just like a markdown file in all GitHub repositories, so it's also very easy to contribute a new one. You just make a portal request with a new markdown file, and the build process will automatically look up that repo and find the number of stars, and so on.

Then it uses an interesting little hack to keep track of the history over time. There's actually a gist in GitHub that's like a big adjacent document with all the history, and every time that we finished the part of a build that fetches the data from GitHub, we use the GitHub API again to push a new version of that gist with an updated history. So it's like using gist as a very slow database, but it does need to be fast, because it's just a static build.

Once the whole build is done, we push it to Netlify, and the new version is live. And that happens as a daily process we trigger with webhooks. Everyday, we rebuild and update the stats, and every time someone makes a pull request, Netlify will actually also run a build of that pull request and give it to me on a URL so I can go in an check if everything looks right and then merge in the pull request.

Of course, it completely solves all the issues we originally had around how to make the site perform or do caching or whatever of those lookups. It's a serial means in this project, now, of course, and has been on Hacker News and stuff like that many times without, obviously, any issues.

Brian: Awesome. So, the static portion really makes sense as far as like using a product like Netlify or going like the estuary route and just getting your front end to be hosted.

But one thing that really got me interested in Netlify for me as a user, my intro to JavaScript, not my intro to JavaScript, but my intro to actually production-level JavaScript, was Ember. Ember was really big on separation and concerns, so their framework actually builds properly down to the index.html. React is the same way. It's built on Node. Angular, same thing.

So, all these JavaScript frameworks, I just want to make it a point that JAMstack doesn't stop once you start adding in Node. You're able to, services like Netlify, you can host an entire React app. Do you want to explain more about that?

Mathias: Absolutely. Our own application at app.netlify.com, right now, that's actually an Angular app, but very soon we're going to release a new version of that that's a React application. Of course, app.netlify.com is hosted on netlify.com. In our case, we use Webpack, which is more and more becoming the standard for all of the asset compilation pipelines.

We use Webpack to take our whole project and turn it into a bundle and a CSS file and an index.html. Then we've hooked that up with Netlify, so every time we push to get it, we'll just have Netlify run a build and deploy. When many of these frameworks started out, like when Ember started out, the common way of using them was like having your Ember application inside a Rails application, and things like that.

I think everybody just discovered that it's much nicer to really get a clean separation and to have one repository with whatever tool you're using to build your back end APIs. Either back-end API or different APIs if you're using a lot of different services. And one repository that's really just the front end in itself.

One of the things that's also powerful with this is that it's very easy. For example, with Netlify's application, if you just clone the application and locally run npm install, npm start, then you'll instantly just have Netlify's client-side app running locally, talking to our production API.

That makes it really easy when working on just UI components and so on, that you don't even actually need a local database or anything. You can just work directly with the production data and see how it looks and tweak components.

Then, of course, if you're also doing work on the API, you can just set an environment variable, and the app will talk to your local version of the API or whatever. But, again, that kind of decoupling makes it really easy to work on each part and in isolation.

One thing I'm also excited about is, apart from that, that's something we're starting to see and I spend, actually, my weekend doing a little proof of concept for some of this. But where you really start also building hybrid approaches, where you use some kind of static build tool to build out a ton of HTML pages, but then you decorate those pages with small, single-page apps for the interactive functionalities, and in our own case, we have some examples of that.

When you go to netlify.com, there's an interactive terminal tutorial on how our CLI tool works. And that tutorial is a little React application itself. We just pull in the script for that, and then it runs in a little part of our static site that's built with Giggle and takes all control of that little part and gives you this interactive tutorial. I think we'll see that becoming really, really mainstream as well, this mixing of, statically-built, content-driven sites with elements that are handled by small, single-page apps.

Brian: One really good example was the last Static Web Tech meetup that we had here at Heavybit, and David Wells who presented the topic for CSS modules. As like a little extra sprinkle at the end of it, he showed his React playground, I guess is what he called it, which was a mixture of Phenomic, which is a static site generator for React.

But it's also tons of React components shoved in there, so that way, designers and other front-end developers can just go in there and play around some CSS, play around with resizing boxes. Which kind of blew me away, understanding that, oh wait, I can do this. This is simple. It's just a little bit of markup and a lot a bit of JavaScript.

Mathias: Absolutely, that's really cool. There's two static site generators that's really pursued that idea, which is like Phenomic and Gatsby. And I know that Kyle from Gatsby is also going to do a huge push to actually take Gatsby to the next level, and so on.

By the way, if anybody out there is listening and interested, he's very much looking for people that have projects that would benefit from one of these approaches and that would want to work with him on giving real use cases for Gatsby.

Brian: Just pushing the project forward.

Mathias: Yeah, pushing the project forward. And Phenomic has also really made great strides. There's also a React static boiler plate and so on. But I still think like Phenomic and Gatsby are the two that are really pushing that vision.

Brian: I see a real need for a lot of this, especially documentation. I'm only very new at the React community, but I've been very impressed with the documentation thus far, from the community. I think Ember does a really good job as well, but not every project has good documentation.

Brian: But the fact that you can easily just spin up a static website, host it on Netlify or S3 for super cheap, kind of lowers the barrier for the limitation. I know a lot of the Ruby projects that I used to contribute to are really ugly looking YAML files and mainly, I think, hosted with GitHub Pages on the built-in GitHub Pages build tool.

Mathias: Giggle, like those.

Brian: Yeah, it really opens up the door. The limitations of GitHub Pages, I guess I'll talk a little more about that, where it's built around Jekyll. Jekyll works really well with GitHub Pages, but when you go to anything outside of that...

Mathias: It's more of a pain, and you have to actually push the build output to a branch in your repository, which always, at least if you're a little bit of a purist around version control and so on, it always feels very dirty when you have to actually push build output to your version control instead of just pushing source code.

Brian: It's a bit wonky, and I think a lot of people have built their businesses and projects around GitHub pages, and I think GitHub's realized this, and I think about a year ago they started throttling certain pages for a good reason. I mean, it wasn't made for that type of platform.

Mathias: No, and it's a free service that's really like meant to help people host their open-source project page and documentation, and so on. So, of course, when people start pushing it to run like production sites, I imagine that GitHub has to take some action.

Brian: Which is the beauty of JAMstack. The whole approach and the whole, the term itself is pretty agnostic of what your choice is, so if you want to use like pure static stuff that build with node, go. You can do it.

If like Jade over Haml, or over regular HTML, you can go ahead and do that, too. I like that. I guess a difference, the only one, I haven't used LAMP stack. But MEEN stack is the other one that is the stack itself. I know it's very specific to Mongo-Express, Angular, and then Node. I know a lot of people were trying to push to MEEN.

MEENs like the two-E MEEN stack, which was like, instead of Angular or Ember, there were like a lot of different phrases that came out about a year and a half ago, that people were trying to, "Oh, MEEN stack? Well, you'll like our new, like, whatever stack." And I know JAMstack is not that.

Mathias: Another thing from, initially, when starting to talk about JAMstack, was also to see that in a certain way, the main concept for the JAMstack is that the stack has moved up a little, where before it really was very much about what's on our server. With their original, the whole terminology started to come with the LAMP stack. And that was really like Linux, Apache, MySQL, and PHP, or Python, or Perl, or so on. It was very tied to, "This is what I'm running on my server."

Of course, one of the big things that's happened is also this idea of no longer having a concept of "my" server.

When people deploy to Netlify, obviously we run a lot of servers, and right now we have like 26 different presences in 26 different data centers, I think, and servers all over the place. But people that use Netlify don't think about servers. They no longer work on the level of extraction of a server.

This whole concept of a serverless stack, which of course, in one way, it doesn't make sense at all. Because, of course, there's lots of servers. You need servers to run your stuff. But at the term, at the level of abstraction that the developers work on, the idea of a server goes away, and you start thinking about, "This is my front end. I just push it here, and it gets distributed all over the world, and I don't have to think about that."

We're starting to see this with the idea of Lambda or sure functions, all of these, Iron.io as well. These functions as a service or method used as a service, where it's really like I'll even just write some code and just have a function that runs somewhere when I need it. I stop thinking about about servers in the same way.

Of course, there's a ton of servers involved in that and it's a super complicated process, but for the developers themselves, we are starting to see this step up where the stack has changed to be really like, in the terms of the front end, really just about markup, JavaScript, and the APIs you talk to.

That level below it, of, what is running on my server? Am I using Varnish, or nginx, or what about my database? Is it MySQL or Mongo or whatever like that? That level is out of the equation for actually working on the front end, and that's really what I mean with the stack has moved up a little.

Brian: A good example. About a year and a half ago, I started a Slack community with some friends. I built what could've been a static site, but actually ended up being this like weird Express Node app. It was a Slack community. All we had to do was send invites and auto-accept those invites when people submitted the form.

With Slack, it's more of a closed model. You have to accept people. You can't just have people go to our link and add your email, and you're in. So we basically wanted to get rid of that one step.

I created this Node server, and it's like the Express forum that talked to some other like software, form as a service. I forgot what it was. But anyway, regardless, it's not important, but they would fill out the form. I would have to have the Node server running like 24 hours a day so that we would auto accept it Then we'd be good to go. Once we started it, we had like this huge push, got a couple hundred people signing up, auto-inviting, and we were good to go.

But now, with things like Netlify and with Lambda or Iron.io, I could have just had some JavaScript function that got ran asynchronously, every time someone has filled out the form.And I would've never had to run the server on my machine.

Had my machine crash multiple times throughout the day while trying to do work, and I just wouldn't have to worry about it. And I think the fact that this podcast is in play, I'm really excited because now people are going to be more aware of that, you can actually do this. And more tools like, you know, Netlify.

People can have stuff pushed, and you can have your Lambda functions running asynchronously with whatever people fill out in your forums or whatever, so pretty awesome.

Mathias: I'm also very excited about seeing the whole ecosystem around this mature. Because, of course, it's still the early days, and you can still see that a lot of the people building big projects with this have found the bleeding edge and are doing a lot of custom development around it, and so on, right?

At Netlify we are working a lot to help people get to that point where you don't need to do a lot of custom work around it, where you can really just jump it and work with this architecture and just have things work. And I think that'll be really exciting to follow in the next couple of years, this new way of building sites really maturing and the whole ecosystem around it growing up.

Brian: Cool. Well, I really enjoyed the conversation. On that note, I wanted to move into some of our JAM picks. Shortly before the show, I asked if you had a pick. Did you have one that you're jamming with?

Mathias: That I'm jamming with? That's a good question.

Brian: Anything that you do during work or to not think about work.

Mathias: The thing is that as a founder I kind of think about work all the time.

Brian: Yeah, very true.

Mathias: I've been enjoying some good old Jaco Pastorius lately. Probably the best bass player ever. He had a way too short life. Got killed by a biker at 35, but he was the bass player for a band called Weather Report.

Brian: Is this a European band?

Mathias: No, it's an American band. They were actually the best selling jazz group ever back in the '70s with Joe Zawinul and Wayne Shorter as the group leaders, and Jaco Pastorius is an amazing character.

He really changed the way the bass has been played, and pretty much any big bass player today will somewhat be influenced by the way he started playing the bass. Just completely incredible technique and a whole new sound, very, very original. Also, very peculiar personality.

Brian: I think for the listener's sake, Matt, you have a background of music.

Mathias: Yeah, I do.

Brian: So, you spent a lot of time in music. Actually, you're a classically trained musician as well?

Mathias: Not a professional musician. I studied music at the university in Denmark. In Denmark, the music at the university is just like studying comparative literature.

You're not getting an education as a musician, you're learning about the history, the theory of music, some composition. But it's really a part of the humanities, and I had my secondaries in comparative literature. What I was studying was like the culture of music, what does it mean, why do people play music.

As a part of that, I also did play classical piano, and I miss that. I don't have a piano these days. In San Francisco, you need to be pretty lucky to be able to afford a place where you have room for a piano.

Brian: It's a luxury, for sure.

Mathias:I've even worked in Denmark as a musical journalist before I started my second career, as a developer.

Brian: Well, awesome. Super interesting. I did a podcast with Matt on my other podcast, This Developing Story, you should check it out.

As far as picks for me, I'll stick with the music. I've been listening to a podcast called Song Exploder, which is on the Panoply network, and it's super, super awesome. I only remember the host's name because it's an interesting name, Hrishikesh Hirway. He basically goes through a song from a band or a musician and basically just re-architects and breaks down why the song was made and what elements came to making the songs.

They've had quite a different big names out there that have been on, like Weezer was on there for an episode. But then a lot of other small, indie acts will be on there, too. And I think one of my first episodes was actually a rapper from LA, too, who was on there and just broke down the beats that he rapped to and the music that he created. I highly recommend checking that out.

Matt, if people want to follow you and check you out on the internet, how could they?

Mathias: They can start by learning how to spell my second name. I'm @biilmann on Twitter. I think it took me around seven years to learn how to spell it myself.

Brian: Awesome. Well, Matt, again, thanks for the chat and continuing to spread the jam.