Matt Biilmann 0:00
Matt Biilmann 19:39
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.