Matt Biilmann 0:00
I think like now today with the with the Jetson twins to transport it truly is like living in the future between generative AI and mutual lanes and and just from how far we’ve come since the since the term was was coined. And I’m going to go talk about the that that time that’s passed and what happened since since then and where I think we could be going next, a little bit about me and CEO and co founder of Netlify indentify. Today’s serves more than a billion unique visitors to the site stores an app running on its network every single month we’ve on boarded more than four and a half million developers to Job platform, a race to 12 million in capital from from from amazing partners, and are here to build a great platform for us all to build on. In we work with customers across anything from people building their very first portfolio right out of Code School, to the guy engineering team at Twilio to large enterprises like Unilever or a Fortune brands in ng F really build a platform that’s agnostic to what you’re building, what kind of company you are in, really focused on building for the web. And for the front end. And building this was only possible because of this change from the way we did things before to the way we did things after after the emergence of the of the Jamstack. So I’m gonna go back in time, to almost eight years ago, a at this moment in back in the year of 2016, a very different times, but in some ways, is still the same. We’re all running around playing Pokemon Go a UK decided to go their own strange path A and A at the time that I’m talking about, we still thought that that guy lower corner was just a joke in and a Netlify at the time was this tiny seats, seed stage startup in, but it’s a handful of people, six people or so in building building our platform for modern websites. And back then in April 2016, I got asked to give a talk at the at the stage of the smashing magazines conference here in San Francisco called the new front end stack. That was the that was the talk where I first introduced the term Jamstack to the world. It this was the first slide that mentioned it to the to the public. Now in that job, I sort of started with a with a little bit of history of the web and where we came from. With this the very first ever website and the and the way, it was really simple setup, right like a file on the server. Other people could find it and click through hyperlinks to go from from from destination to destination, we then introduced the idea of a program at first in in a folder called cgi bin that the server would pull out to when a request came in, we could then build back a page on demand and get sort of the first dynamic websites, it to actually do stuff with that people started introducing the idea of a database in that was really like you had like your server and your database. And every time a request came in, you would get a bunch of different furies in the database and show something. And then as the web started growing, we needed to start scaling this in different ways right like so we had to start introducing a cache between the server and the program and between the program and the database. It gets all of these in my original slides from from from ETS ago right in the next step as it started in being the the wage bill was introducing like CDs in the middle as the web started going global and you had to reach people not just the next to your next to your server but all over the world. And now he started having like this pretty complex system we all had to live with back then cross monitoring and cache invalidation and release engineering and versioning and, and migrations and tunings and so on It had brought us to the point back in 2016, where the web in general was really struggling with security, reliability and performance. This, this was like an announcement that the Drupal team back then back then Drupal was really like just one of the de facto ways to build for the web, right. And they sent out an announcement saying, like, we just got a vulnerability. If you haven’t patched it without within seven hours after the announcement, you should just consider your whole infrastructure to be compromised, and maybe start over right like, we all got really used to visiting pages from from Hacker News, Slashdot, or whatever their social platform was back then, and get these kinds of database missing screens. And we were at a time where when we were raising our seed round back, then we often got the question like, why are you building something for the web isn’t at all going to be mobile applications or social media or Instant Articles? Like, is anyone really building this platform anymore? Like the challenges we face back then had been an actual threat to the web and an excuse for walled gardens. It was a very different world back then Brian was talking about it just in the last four years. But if you think that eight years ago now when I gave this first talk on the jam stack, it was it was really a different place. Right. This was Gartner’s Magic Quadrant for web content management, a by the end of 2016. Talking about like Sitecore, Adobe Experience Manager Acquia, the company behind Drupal AP server automatic was there, right? Like all these big monolithic CMS systems that people would build with and add to sort of more like, day to day front end developer world, these were probably the tools that you would go to if you were building a new project WordPress is the absolutely dominating force on on new websites, Ruby and Rails for full stack applications, Drupal expression in chin Joomla. And Magento was sort of like the most popular ecommerce platform, all monolithic into end in tiered applications, depending on server and database, and so on. And we have this spiring new ecosystem around the modern web and a different way to do things. But it’s, it’s just important to remember how small it was back then, and how early right like the we had like static site generators, like geiko, and Kubo. And Hupo is still in its early days, the build tools of the time were were mainly Grunt and Gulp with Webpack, having sort of just emerged into the space Contentful, when I gave this talk, had not even raised this seriously. They were serious seed startup in Germany, in talking mostly about mobile health being the reason you would want a hitless C API. And you’re just not going to find it in this ecosystem back then. Any meta frameworks any hitless commerce platforms or anything like that, search pretty radical at the time, when I went on stage and say like, we should stop fundamentally decoupling the front end and back end, we should build the back end around API’s a and generate the front end with modern built tools. It was really a cultural treat the front end as its own thing, its own app with its own git repository, its own release management, its own global infrastructure, versus just being a derivative of whatever back end we’re using. Or as we put it more succinctly later, can SEC removes the need for business logic to dictate the web experience. And if we go back to this, like very first slides I gave on on the Jamstack and what I talked about back then this was the first slide sort of describing what went into the Jamstack What is it actually in and think back again, ages ago and remember life of FTP into a server to update a bunch of WordPress files as part of your workflow or running Capistrano? If people hear and remember that to SSH into a server running a deploy with an acid pipeline Brian with database migrations happening right on the server then symlinking folder to go live in. Think about to the time where CD ends were either something you just offload your fonts or JavaScript bundles to or something really big companies worked with definitely not something a normal front end developer would would set up for for have a website where built tools were mainly branded golf and are often just to create some bundles within a Rails application. In web front end frameworks were in their infancy, right? Like we were talking Angular one. And Ember as the as the dominating players here, in and when most of the websites you worked on had no API to talk to a and the, where the early stage API driven CMS is we’re pretty niche and the in really small. I introduced the scan philosophy, decoupling, building and boosting, decoupling the front end and the back end move from every server having its database, database migrations and so on to encapsulating all your back end logic behind API’s. And then now you have prebaked markup enhanced with JavaScript with the goal of going from a very complex world of really complex web infrastructure deployment flow, operational flow to simpler world that should ideally look something like this, where have a page and load something straight from an edge node out of a CDN, and you have this simple workflow, you push to get you run a build, talk to some API’s, push the results to your CDN, very simple conceptual model in and then during runtime, you would obviously both, you would load the application and then you would talk to different API’s for the for the dynamic features. Now, there were two big pillars at the time going into this. And I think, in this last year, people have waited those very differently and interpret those very differently. The first really big pillar, which to me was was the core of this was the decoupling was really the idea of moving the front end into its own application away from our from our back in business logic away from the tools. We used to do API’s and services and business logic and data access and into tools built specifically to building great user experiences. And this was really, the decoupling that allowed us to build Netlify era is what allowed us to start the modern concept of front end cloud that’s now really become like commonplace and the standard for how you deploy modern web UIs. Whether you’re doing it with us or another vendor, it was the idea that allowed us to give release management specifically for your UI in with with this idea of connecting to get pushing, and then having it run, it allowed us to go and invent the concept of deployed previews back in in 2016. The idea that every single pull requests or merge requests, you make sure your Git provider would give you a unique URL that you could visit that you could share with your co workers to stakeholders, and build with to create great experiences and great processes. It was also really this decoupling that allowed us to say, we like if you’re running a full and monolithic application, CDN, it’s not really a great setup for that, right, like you have all these individual points of presence scattered all across the world in that complex distributed system. But if you’ve decoupled the front end UI, CDN becomes an amazing place to run that. And you can really start talking about an application delivery network where you put this UI app on it on a global network and, and and lower the friction for people to access it and increase the ability to scale it automatically. It also gave us the ability to standardize how we think about local development in a way that you just didn’t have before, right, like, back in it again, thinking back to 2016. If I were giving a new, a Ruby and Rails app or something like that, it resulted in a pretty complex setup, I would need to install the right database locally, run my migrations, pick out all the pieces compile Ruby in the right version, and so on with modern friends and applications. Typically, if they’re decoupled, you just clone the repository, you run an npm install, and then you fire up Netlify dev on whatever dev server you’re using, right like but it’s just become a normal part of how we work. And it’s again, a side effect of this decoupling of the front end for all the other stuff you need to actually serve your customers. Now, the other big trend back then The other big piece we were talking about and the and in that’s been a big topic since then was the pre baking, right like the idea of having a build step that can output as a static version of your site or app that you can deploy globally. This came with some very specific benefits that are still worthwhile if you go for this approach. The first one was saggy F atomic deploys, which is like, in the full consequence, only really viable as like atomic immutable deploys. If you’re taking this step, right like make make us be able to save every single deployment you make, is going to persist, it’s going to have a set of files that all go live instantly at the same time. But it’s also going to have this like repeatable history where you can roll back completely safely to any earlier point in time, because we know exactly what went into a deployment. And that pre baking as vendor gave us like a very, in a very strong contract around caching with developers building our platform, right, like so it allows us to say, when a build hadn’t, and finishes, we know that this is the time where we can do an instant cache invalidation. And we can free up all these assets, in again gave us these atomic deploys. With instant cache invalidation that work globally, that was very hard to architect, if you are not doing this aim, it also really matters for for security, this is still this is something I think people are forgetting a little bit. If people with some relation to Netlify might know the specific project pits of Netlify. It’s like very, very simple little eleventy site there at a time, all employees would go in and make a little pull request to add that pit. Right? Sir, just yesterday, I checked out this very simple little site, again, just really basic, simple eleventy site, but also one that’s just been sitting around for a while. And it’s like done any real maintenance on it outside there of adding pets. And I just ran NPM audit on this really simple project, right? Like, it gave me 17 vulnerabilities in two of them critical and seven of them high. Right? beauty of it, I really don’t care, right like this, like these vulnerability are completely encapsulated at the Build step, nothing is exposed to users interacting with this site. So I really don’t have to worry about it. But if this had been an equally simple site, build with, with with our pre baking with dynamic server side rendering, then who knows, like these vulnerabilities might give inducers access to environment variables in my system that would allow them to escalate and go to projects who really care about and do dangerous things. So I would need to react to these, I would need to go figure out like from from probably the ancient version of eleventy that we use for this, how would I update to a modern one? How would I get all the dependencies up to date and get this working? Pre baking in cebus, don’t have to worry about it. I also present it back in the top sort of like an archetypes of different types of projects you could build with this deck, there was websites really tailored well to like this kind of content base, the pre baking, build some content, ship it in, probably not changing every minute. And the builders probably they fast enough that this becomes really bad, viable, single page applications. In still a big fan of them in after netlify.com is one of them, right? Like you ship a shell, you talk to different API’s and services. But then also the realization that there’s this whole world of hybrid in between, in back then a the idea was more Okay, let’s see how much you can pre bake and then use different components or JavaScript, a methods to enhance the functionality and bring in the dynamic bits. I think this hybrid area is where we’ve seen the biggest shift over the last eight years since I introduced this talk and where we have very, very different tooling available now that we then we had a seagull. So let’s talk about that, that journey from where we were and to where we are today.

Matt Biilmann 19:39
So back then I mentioned that this was a really nascent ecosystem, right, like again, we were seed stage startup Contentful at spilled out announced the seriousIy there were no meta frameworks in there were very rudimentary simple build tools, the first meta framework around Jamstack that that emerged at that time was West Gatsby. And one of the things Gatsby really brought to the market was the idea that we can think about the merits and stuff. But but the idea of React hydration, right, like this was a big change, especially from the from the hybrid side of things, the idea that you would pre build a lot of markup. But also, when you request to the side, and you load the page, react would kick in, and essentially hydrate the whole dome in that page into a new single page application. So every navigation after that would be would be very fast. But you would also cobbled the initial page load with a lot of JavaScript, and a lot of a lot of logic, in any word, essentially, JavaScript UI, every single part of the dome for every page view. In a little after this, we launched nearly five functions, which was a pretty new part of the stack, right like until that it really was like, you have to pre bake everything. Output, it said static files. And that’s that that’s what you can do in this decoupled architecture. With modern front end cloud, nearly five functions introduced the idea of a serverless runtime layer that you can deploy front end logic into that way, you can build the back end for your front end, or where you suddenly could even do server side rendering. And the next major framework is what’s next in that emerged on on the scene really capitalizing on this right like, again, relying on React hydration as the mechanism of essentially turning everything into a living application. But introduced the idea of choosing on a page per page basis between static or server side rendering in serverless functions. And later on, introduced this like middle ground, all the incremental static regeneration, where instead of building everything, statically part of it, you would have serverless function build and persist on the very first visit, sort of a middle ground and a sliding scale towards something may be a bit different. In 2020, we introduced the concept of fear of edge handlers, the complicated edge functions by giving us JavaScript code running globally around the world, at the at the CDN request cycle. And later on, the idea of edge functions became became popularized. It’s a common concept that we expect from from any front end cloud today. And the landscape of frameworks kind of exploded, right? Like this is just a slide of, of our free frameworks, modern frameworks in this space, that have a official financial backing from from from some company, right? Like it, we’ve gone from non in 2016, to this whole group, is that that’s even growing. I’m even missing a couple on this slide, I can see like, like quick. And we moved to this expanded version of what a front end cloud looked like that now included of Stearic Acid serverless functions, I saw functions, Edge functions, and so on, in we’ve already expanded that. And we really went from like this early day around like 2017, where the first stack that kind of emerged around the Jamstack was kind of Netlify Gatsby in Contentful. To a world where we just exploded in a choice between all the different front end clouds options. Now the different frameworks options, the massive amount of headless CMS is where now, even the traditional CMS is all structured like all actually to implement hitless versions and composable architectures. We’ve seen an explosion in headless commerce, where again, 2016, couldn’t name a single headless commerce tool today. Almost all the commerce filter you’re interacting with have haven’t have a headless version in and even the idea of databases as API’s with tools like fonthaus, superbeets, Isata, and so on, that that makes it easy to spin up a database service that feels like an API rather than feels like a database you’re always interacting with in and then by the end of 2021, the React team made this big introduction of food react server components that acid shaking up the the ecosystem we are in quite a bit. It took a while before we really saw sort of the first production ready in version of this in if we didn’t truly seen that get in. But

Matt Biilmann 25:21
if ed in 2020 to a next year’s resell joined it launch the app router in that took the existing pages router that could really choose between like static SSR, or ISI and introduce this more complex, a bit more powerful app router that gives you a more granularity through a React server components. And that’s been sort of one of the big evolutions in the ecosystem is as we look at just this is this is a chart from our in from from our annual report on the on the modern front end web ecosystem where we’ve asked our community a bunch of different questions we had about 7000 developers reply in this is the graph of the report that shows the popularity of the different frameworks in our community. There’s no doubt right now that like next is massively the dominating framework in the number one place a with a vision of sort of solving everything, right? Like all of these different modes, you can go to through the framework. This is a gamble, the founder of for self explaining the flexibility of next right like you have an SBA and existing API, you can do it SBA plus data, you can do it static site from CSS, you can pre render with next static site with personalization, you can pre render with the SSR screaming for the Dynamic Pitch of it pitch for the client. And I could go on, there’s so many different avenues and so on, right like, and someone asked him about one of these in, and he replied by aim next, passing a promise from an RSC into a client component that hydrates the initial stage of a single page application data fetching layer, like stale while revalidate. Now, this is this is powerful. And it’s a powerful tool. But it no longer feels simple. When I think back to that original sort of like statement of where the web had gone. And where we should move towards. When I look at the docs from next year’s. This is from the next year to page two dark our new caching for next year’s right like, see this diagram with the text that caching behavior changes, depending on whether the browser is statically, or dynamically rendered, data is cached on cache. And well I request as part of an initial visit or subsequent navigation. Depending on your use case, you can configure the caching behavior for individual routes and data requests. Again, this is powerful, right? I can you can build powerful stuff with it. But it also feels a lot like this, right? Like it’s hard to discern those two diagrams conceptually from each other. When I go back and think of where were we back then what were we trying to achieve? And where have we come? We definitely want in terms of decoupling the front end into its own thing, we’re now are seeing it as a as a separate pressure to see like, let’s squeeze everything into the front end, let’s rebuild the monolith in this front end layer in. But we made that decoupling happen. We made front end developers much more powerful, we made release management much easier and infrastructure much easier. But it also got a lot more complex. So as we look at 2024 and beyond, where, where are we going from there? And where do I think the future lies? I think people are starting to really crave to get back to the to the feeling of simplicity. Again, that’s kind of like an internal cycle we’ve seen in every single landscape of development. If you’ve been around for a couple of decades that like like I have, right? Like you introduced no tools, you keep expanding what they can do. And at some point, they become very complex and you start thinking, how can we simplify? What can we do to make the mental models simpler in with with the knowledge we have now, again, in I think there’s two paths that we can look to to simplify. One is looking more back at the idea of prepare a big Jamstack and see like this simple build simple conceptual model that gave us a like, a set of very strong cash contracts with our infrastructure. And that gave us like the benefits of security of immutable deploys, and so on. What What can we do with that. And if I go back to the survey of our community that that that we ran last year, we saw this like a chat off, not the not the total size of every framework, but of the changes in in responses since the survey the the year before, in, in the in the survey from 2022, the outlier was VT. And I think in 2023, we really started seeing the effect of that with almost every framework starting to adopt VT. This year, or last year, the outlier was was Astro that it suddenly catapult it into a big uptick in usage, combined with a big uptick in their satisfaction score, people really seem like we started using this new framework, and we really like it. And I think that’s really significant. And I think it comes from this urge to get to something simpler. In I think the Astra team aim went back to the idea of like, how do we build content first, websites, it? And how do we make those hybrids with an island architecture, right? Like where you can sort of go back to the, for idea of like, what if we can prebake very easily build out all four pages in and then instead of hydrating everything and turning sort of every page into a full single page application with with with all the complexities? What if we can just pick the individual components that should actually do something interactive, and make them small, dynamic islands? In it’s it’s really a in our like, in our estimate, in the survey, when we looked at like, why is sto gaining this popularity, it’s because it reduces the overhead and complexity compared to other framework. And again, I think the community is starting to really long for that, in simplicity is back, we’re starting to see this Iceland model in tech get get get traction again. And we just launched Netlify, developers stuck netlify.com in as our new developer portal where we will have fewer developer content in build with Astro in because the team was generally excited about the technology. And it’s been a great experience, it’s very simple to work with. Now, the other way to get to simplicity, this, some people might not think that if you come from me, but the other way to get to simplicity is to go the other way. And say let’s forget about the pre baking, let’s think about the decoupling, but let’s embrace server side rendering with this new architectural piece we have right like if I think back to this, or these original diagrams, this is how you would think about a single page application for the Jamstack Linux, right? Like you would build this shell app, you would serve it straight out of our CDN. And then you would talk to different API’s. I don’t think it’s a major, like fundamental architectural change. If you do this, instead, you have your build tool, you deploy it into a set of serverless functions in your cache and a CDN and those serverless functions, talk to the API’s. Now, it’s very different if there’s serverless functions that just directly connected to a database, and you’re building a monolith with all your business logic in but if the only change you make, is that small change from thus the API’s talk directly to the browser, or do they talk to your serverless function? That’s not a major architectural change? And I want to remind everyone of a slide that I think people forget a bit from my original presentation in 2016. Where is it? Like the Jamstack fundamental is not about static, it’s about how do we build great dynamic experiences? How do we build the right user experiences at the time, the only way to deliver these in a decoupled ways with steady that’s not the case anymore. This starts becoming a viable model. And I think when we do this survey this year, I suspect that we’ll see a similar outlier next year growing in in both adoption and satisfaction. And I suspect that it will be remakes we’ll see next year. We will see at the end of the year if I’m if I’m right, in remakes, especially after they got acquired by Shopify, it’s really been able to focus on on simplicity, again, in it’s a framework that it’s taken the server side rendering approach and said like we’re not going to have all these like really complex things. Free rendering oops, instead, we’re really going to start from like a a server side rendered mode, make data loading and and hit a control to do caching in as simple and straightforward as we can in the recently embraced meet. That, as I said, was the big outlier from last year’s service. And basically turned all three makes interviewed plugging, again really going from a poor simplicity, and started a their expansion, experimental version of remix for single page applications as well, in just this a beat flocking based on essentially React router. And I think it will be a really strong contender for the fastest growing framework this this year in baleen into the concept of server side rendering, plus edge caching in again,

Matt Biilmann 35:54
the simplest way to do edge caching would be to just set a cache control header in, this would be a header that just tells any browser that visits the site cache this page for 60 seconds. problem here. As soon as you do this, you’d set completely goodbye to it atomic deploys, you don’t actually control when any given user is getting something new from you, they could get from navigate from one page that’s new to another page that that’s old, you could introduce like broken to acid chunks, if you could introduce like weirdness, and navigation and so on. And we’ve recently launched a whole bunch of premises on Netlify, to make dynamic caching much better in our platform, in part because of the excitement around what you can do when you take it all into account. So the first one is just to use the standard of CDN cache control, is CDN cache control allows you to scope the cache control to any specific vendor you’re using. In this case, you’re saying Netlify cache control, and you’re just telling our cache to keep this content for 60 seconds, not the end users cache. And this means that you can still get, we can still automatically invalidate all of these assets on every deploy. And you still get a sense of ethnicity. It’s not the full atomicity of pre baking everything, but you still get like instant cash and validation on every deployed globally. We also introduced support for the stale while revalidate hitter, where you can tell our edge to refresh in the background. So you essentially, in normal traffic, never have any user experience like a full SSI cycle apart from just after deployed. As soon as that deploys ready, users will always get a cached version of the pay they’re viewing. And then our CDN will go fetch a new version in the background. And again, we’ll invalidate all of these assets on every full new deployed, so you never have to worry about like a cache invalidation and troubles they’re in, we also gave you like one level of control more where you can see, okay, but give this specific acid a cash check for the API. Let’s say this is this is a page that’s built from a specific API. Now, instead of invalidating undeployed, you can tell Netlify every time that API updates invalidate these assets, and you get like a new cycle of global caching, but with building invalidation in, and you’ll invalidate an API updates, as well as deploys right in. Now, the last like one other problem, because there’s real challenges on doing caching. Well, one other problem, you’ll see, this is like just a small example site from from our internal tests on remix on on Netlify. If we, if we look at this site, this URL, when I go request, this site, this this will be the cache key that I’m caching this piece of content under right like and when I go in, a cache will look up and we have a piece of content for this specific cache key and serve it straight out of that if we do now, this is me in sharing this site, through messenger or Facebook with a friend of mine. And notice that now the cache key suddenly includes a query parameter, the URL suddenly have a third parameter. Is that a unique session to me, if you proviral on social media, and this is your caching strategy, this this is pretty bad, because like now, every single visitor is essentially getting their very own unique cache key. And it means that you’re completely bypassing this whole CDN caching layer. So to work around that you have to have some control over how you think about cache keys for every one of your endpoints. And again, at Netlify, we made that really simple by introducing the Netlify berry hitter. So in this example, I’m saying like, very based on a query parameters, peach and peach, but ignore all the other ones. So now, if I visit this, it’ll see like the snow page or per page, it’ll generate a predictable cache key. And we’ll get back to actually making caching work for these dynamic applications in with a much lower cardinality cache keys in. And again, the reason I think this SSI approach plus caching is exciting now is because we have modern front end clouds now, like back in 2016, CDNs was a completely different layer that you would put in front of your infrastructure that typically had a different networking team managed with manage them, were typically the front end developers had no control how cache keys were made, you would have to go into fastly and configure VCLS, and so on. Today, we can bring both the serverless functions and the edge caching infrastructure together in one release cycle. And I think this, this will be a really empowering, powerful approach going forward. But one just end by saying like, in this eight years, since we started essentially the Jamstack one, right, I go back and look at WordPress, and for most of this time, it was completed dominating and growing, it’s starting to very visibly decline. It’s no longer the new kind of tool, you go to build a new modern front end project in the web content management magic quadrant that included all these big monolithic end to end in systems. Gartner went and killed it in favor of the modern GFC index peak quadrant, because it’s just not as relevant anymore, right? Like they called it they reached maturity aim. I will challenge any one of you here to name a single new commercial CMS or ecommerce platform that was launched during these last eight years. That That wasn’t deadness, right, like, basically, we saw everything shipped to this mode of building as the default. And we saw this amazing landscape emerge around the Jamstack, with billions of dollars in investment, and with so much choice, and so much different tooling. But it did also get kind of complicated. From from simple beginnings, we’ve got to pretty complex point now. And I think as I think about 2024, and beyond, we should, as a community look to like, what can we do to make things simpler again, and we push back in that direction. And I think there’s two paths, this pushing back towards the pre baked approach that gives us these out of the box guarantees around security, reliability and simplicity. But that doesn’t necessarily stretch to ecommerce sites with a million skews, or really complex fast changing a social media sites or things like that. And then on the other hand, I think we have a possibility of leaning into SSR bi and edge caching. Now that we have these unified front end platforms where the where the edge layer is integrated into deployments and runtime in they’ll give us fast pot machines that let us scale content to millions of pieces. And that lets us introduce some server logic as the backend for the front end for when you’re sending back a post request or when you want to brand the lip, a few different API calls and turn them into one thing. Thank you, and then can’t wait for the for the next eight years of this. It’s been a an exciting journey. And with generative AI and all the new toolings we are about to get it’s only gonna get more fun.

Brian Rinaldi 44:18
Thanks, Matt. That was that was a really great presentation. There’s so many things I’d love to talk to you about. I’m fortunate we only have a few minutes left for q&a. Yeah, that’s okay. So much good information that if you and I’ve been talking about this stuff since I mean, I don’t remember when that was Google. You know, I presented about static site generators at Google. And that was like maybe 10 years ago and we’ve been talking about ever since it’s like, you know, it is amazing how how quickly these things have changed. You know, and I think I personally am totally in agreement with you that things got a little complex. I’ve been talking about it for a while and I, you know, I tend to I, I give off that old man yells at Cloud vibes when I complain about it. But I think it’s it’s not just me that feels that way. You know, I think one of the things I like about, say, like your caching solution, or some of the frameworks that have come out lately, like Astro, as an example, although there are plenty of others, like, you know, Levante and spelt kit that I think kind of follow this is like this simplicity by default, right? Like, I want simplicity by default, but I need the ability to add complexity, where we’re where it fits, right, I think remix does this as well enhances another one that I’ve been watching. That that kind of does, it like kind of starts with a simple premise, that gives me the tools and flexibility to add in that complexity to if I need it to configure caching, or I need to add in some more complex configuration type things, I can do that. And that’s, that, to me is like where the future lies, I believe, and I don’t know if you have any thoughts on that.

Matt Biilmann 46:07
Yeah, I mean, as I said, I think personally, I’ve always been a big, big fan of simple tools, right? Like, everything gets gets complex organically. So if you can make your tools simpler in it makes your programs your writing and the architectures you’re building easier to reason about in, I also understand why tools get more complex, right? Like, because you start expanding to more and more complex use cases, hit more and more edge cases, and so on. If you’re just still again, just listening to customers, you will be adding in more and more in functionalities, they’ll expand the surface area of what your tool can do, and become a very, very complex tool that has the advantage that like next definitely had that advantage has it have a strength in that you can use it across any use case, right? Like if you’re really good at Next, you can use it across a lot of different use cases. But it comes with the price you pay in like increased complexity. And I think in general, from, from my experience, that there is a hybrid side of these use cases. But most of the time, you you’re gonna know pretty well what kind of use case structure we have when we start out right, like so, our, our website on netlify.com For many years, we built with with with 11 T, right? Like, it’s not like our Cole magazine site ever sort of organically emerged into becoming complex in application, right? Like it always seed at a core marketing side, there’s absolutely like Eyeland functionality and figuring in its use and locked in a nod and some personalization aspects and so on, right? Like when it didn’t like go organically over time to become an application. And on the other hand, like app.netlify.com was always like a single page application behind authentication built with React and Redux and so on, right. And it’s also not sort of r&d morphed into becoming something else over time, right, like, so in those cases, I would say like picking a tool that’s great for that kind of use case is going to, it’s going to work really well. And I believe a lot in toolset, pick those areas valency we’re gonna make this really simple. And then we’re going to allow you to expand, like somewhere out here, but we’re not going to build the everything machine to solve every problem up front, right. Like, I think that’s the only way like being opinionated. It’s the only way to create a simplicity and easy ways to read some about your architecture.

Brian Rinaldi 48:49
Yep, I agree there. And I think you make a really good point, which we can kind of just gonna close on is that it doesn’t have to be one size fits all for everything like you don’t just because you do one part of your site with with Astro or 11 D. And then you can do the other part with Next.js. Like because that might fit in a more complex like, you know, the kind of back end piece. You know, you don’t have to choose one tool and say, Okay, now everything we do has to be built with this tool you can pick right the right tools for the job. So that was a that’s a great point. And I really appreciate your time here, Matt. And I wish we had more time to sit here and chat. Because I always have a good time chatting with you and I always learn a lot. So but thank you. Thank you for coming out and thank you for speaking. Thank

Matt Biilmann 49:38
you for having me and keep the conversation going. I’m on you on on on all the random platforms out there. So just hit me up.