Phil Hawksworth 0:00
We’re going to talk about getting to the glass today. What an Earth is that about? I mean, you may have heard this expression before. You may be very well familiar with this term. But if you’re not, and you you work in web development, you might think that getting to the glass is something that you know after working with JavaScript dates and time zones and daylight saving, or after seeing that the future of the design of interfaces seems to be driven by men who love to have compliments from saucy sounding fictional AI, female roommates, whoever they are. And as a result, you’re kind of getting to the glass to reach for something, to drown your sorrows and stare off distantly into the fire, like in this image. But no, never fear, that’s not what we’re talking about at all. Getting to the glass is an expression that I don’t know. I haven’t heard for a while, but it used to be all the rage when I used to work at an agency, once upon a time, getting to the glass. Talked about the speed that content would arrive at the screen. So the glass of your monitor, or the glass, more likely these days, of your device, time to glass was something that clients were always obsessed with during the proposal times, you know, working at an agency. And then it seemed to get forgotten about during the kind of the design phase where, well, performance is something we’ll fix later on. And then it became something that we’re obsessed with, again, in the kind of the building and the testing and the delivery phase, and then it was ignored again when it got into the business as usual kind of business, you know, operation of the site. But it’s incredibly important. Of course, it is performance, we know is a really, really important aspect. So we’re going to talk about that a little bit today. And you know what? What’s involved in getting to the glass? Well, you know, this is, this is a familiar kind of scenario. We’ve all seen this kind of picture before, of, you know, content that is delivered from some sort of server. Maybe there’s some machinery, some cogs turning, some logic happening on a server. Maybe that’s happening in the client as well. And even before this happens actually and gets to the glasses of the user, you know, this has to be requested. So requests go through this chain and through all the infrastructure and comes back. There’s lots involved. There’s load balancing, there’s DNS, there’s network requests, there’s all kinds of things. There’s all the magic that go, that does the things, that gets the stuff to the place. That’s what we’re we’re talking about today. I would have called the talk that, but frankly, I didn’t think that would make me sound very credible, so I thought I’d use a nice buzz, Buzzy term, and also we’ll talk about getting getting to the glass. You’ve already heard a little bit about me, maybe too much from Sean already, but as as you heard, yeah, my name is Phil Hawksworth and my family describes what I do as I work in computers. Does anyone else have that job as well? You work in computers. This is what my family thinks I do, I guess. But as you heard from Sean, I’m part of the developer education team and Netlify, and you will get a chance to ask questions. Maybe I’ll spot some floating past in the chat. You never know. But otherwise, we’ll pick some of those, those questions up afterwards. But if, for whatever reason, we don’t get to all of the questions, or you’re watching this on a recording, and you want to ask a question, you know, afterwards, then you can find me in most places. Whatever social media is these days, I tend to just stick to using my name. I’m not as creative as some. So you can find me. It’s PhilHawksworth on on all these places. Ask me questions there. I’m always super excited to chat about all things to do with this, this kind of territory. So let’s get back to it. Then, getting getting to the glass. What are we talking about there, and how do we do the best job of getting to the glass? How do we do the best job of rendering things in a performant way on the web these days. Well, the answer to that, I’m sure you’d be delighted to know, is it depends. I’m always very cautious about giving that answer. It gets a lot of eyebrows raised, but I think actually it depends as an incredibly important answer to give, as long as it provokes the right questions afterwards, it’s the follow up conversations to that which are really important. And we’ll come back to it depends a little bit later on. But as you’ve already heard, alluded to a little bit from Sean already, kind of there are lots of trends in web development, and trends tend to be kind of cyclical. We often use that expression we talk about the tools and technologies and the trends in web development and engine web engineering being cyclical and kind of coming around from time to time. I kind of think of it slightly differently. I kind of think of it as a bit of a pendulum. You know. I think the pendulum swings from one side to the other, and we’re kind of going back and forth. I don’t know if it does kind of nice in kind of a gradual way, go from one face to another. It feels like it heads to extremes and back again before. You’re thinking, well, this is a nice, majestic way to look at it. I’m not thinking it’s a majestic pendulum from some, I don’t know, ornate and regal grandfather clock or something. We’re talking about these kind of pendulums that hang off noisy, shouty in your face, opinionated, not cheap. It turns out cuckoo clocks. Who knew cuckoo clocks are expensive? I had no idea until I found this image, but certainly being on the technology pendulum is expensive too. We kind of swing from one extreme to the other and taste change approaches, change trends change over time. Where’s the right place to be on this pendulum is the kind of question we’re asking. And I think there is a sweet spot that actually is a sweet spot somewhere in that where that pendulum swings. It might be there. I don’t know. It might be there. It might be there. It depends. It depends on the current climate. It depends on lots of different things. So it depends. It’s very much an answer. You will hear me reach for many, many times, but I will follow it up. But you know, how do we choose the right tools we’re going to be using for for rendering things on the web? How are we going to be getting views to the eyeballs and the devices of our users as fast as possible? There are so many things to choose from, and the right things to choose are, well, kind of It depends. But it depends on things such as, you know, the costs of those technologies, the budget of the organization and the team that you’re you’re working within the time available to you. How you know, how much engineering time can you sink into this? And how important is that to you? What skills do you have in the team? You know, what do you need to cross train entirely? Or should you be using something a bit more fulfilled? Familiar to you? How sustainable is the approach that you’re going to take? And I mean that in terms of the longevity of the technologies that you’re using, how supportable it is? Is it? How maintained are the various systems that you’re going to be using? And you know, you could talk about sustainability from an environmental point of view as well. You know, how energy efficient are these? Are these technologies? All of these things should factor in. And of course, so should the requirements, the functional requirements, and indeed, the non functional requirements of what we’re building. That’s such a key thing to factor in before we decide what is the best way to do anything on the web. We shouldn’t be led by the fashions that the tools that we see are most popular. We should be thinking, do those satisfy our needs. So it really does depend. Everything depends. However, I would say there’s something which is kind of pervasive, something that is always there. And I think that something that that doesn’t really depend is that simplicity is something we should always strive for. You heard in the introduction from Sean the mention of simplicity. And I think this is is such a huge advantage if we can bring some sort of simplicity to what we’re what we’re building and the way that we deliver things. And that might seem like an obvious thing to say, but we so often lose sight of it. Simplicity is at the heart of the web of HTML itself. It’s one of the design principles right there, in in inherent in the web. You know, the principle of least power is one of the design principles there in the web. And, you know, Tim Berners Lee said it in the in the design principles themselves. He said, computer science has spent a long a lot of effort making languages which were as powerful as possible. Nowadays, we have to appreciate the reasons for picking not the most powerful solution, but the least powerful. And he was argued for it right in the design principles of HTML, and it’s kind of coupled with the with the robustness principle and making sure that things stand the test of time. And so there are so many reasons to kind of search for simplicity and reach for simplicity. And I think it’s a really desirable attribute. So I’m very keen that we always simplify as much as is possible, but no more because, you know, simplicity and complexity are also things that live on this pendulum, and I’m cautious about extremes. I’m cautious about being absolutist. So make it as simple as possible, but no more simple than is possible. What an obvious thing to say, but such an important thing. I think, as well, pragmatism is so important, and being pragmatic, rather than being dogmatic or absolutist, is really important, I think, when designing our approach to the web.

Phil Hawksworth 9:14
So let’s think again then about how we do the best job of of getting to the glass and being before on which of these things do we choose? Where do we live on this pendulum? Sean already mentioned, you know, how the trends have changed. It used to be that everything was rendered on the server. In other words, the server would generate the HTML that would be interpreted by the by the browser. But then the pendulum seemed to swing, and then we were doing everything in the client, and so much was happening in single page applications, and kind of really getting excited about the fact that we could do so much in the client. Where is the sweet spot? Well, I don’t know. It’s somewhere in between. It It depends, but we should start unpacking some of this a little bit more detail if we’re going to get into the guts of this. So. Let’s unpack this all the magic that does the things that get the stuff to the place. What are we talking about? Well, we’ve already seen this. You know, it used to be that the content was just delivered. It lived on the server, and when we asked for it, we got it, and then we started putting logic on the server so things would generate the views so that we could then see them. And then, of course, that was delivered to a client, which would interpret that and kind of render that for us. But then we started putting logic on the client as well, so we could have JavaScript rendering views right there in in the client, in addition to things happening on the server. Now things happened to all arrived on the server because of some kind of deployment or some sort of build, and I got very excited at the prospect of, you know, once we’ve kind of separated the client and the server side of the equation. I got very excited about the prospect of builds doing all of the heavy lifting so the servers could become dumb again. I love dumb. I love boring. I think it’s it’s simple, and it’s something that we can reason about much more easily when that’s the case. So I got very excited about this idea of regenerating things as much as possible, kind of this SSG approach, static site generation and then putting dumb assets onto infrastructure that can be then delivered to the client. There’s an idea that maybe that means that we do all of the dynamic things through client side JavaScript, and that’s true, but we don’t have to do everything in client side JavaScript. I’m a big fan of minimizing the JavaScript that’s happening on the client, you know, just as much as we need, and no more. The more I can do upstream and ahead of time, the better. But if we’re trying to think about minimizing what happens on the server and minimizing what happens on the client, but still having something that’s dynamic and engaging, where do we put that? Well, I think there’s space in the middle, and it turns out the middle, it’s called the edge, which is bonkers. Of course, naming is hard in in computer science, but this place, the edge, the edge of the network, is a really exciting place that we can start to do things. And, you know, with that’s, that’s a serverless runtime, serverless environment, that we can do really interesting things. Now this diagram has started to get a bit complex. And a few slides ago, you may recall I said simplicity is always something to strive for. So what gives? Well, let me defend myself a tiny bit here and kind of just just ring fence this. This part of the diagram, you know, this area here is what’s happening at request time, the things that are at play when requests are being made. And you know, if we’re thinking that, well, we’ve got a model where we can actually simplify the server and get that just some assets that are being served that’s kind of commoditized these days. It’s great. And if we can simplify things that are happening on the client and not do all of the rendering on there, then this place, this serverless environment at the edge becomes a very kind of easy to reason about environment, and this whole model becomes much more easy to reason about. I like the thinking that we’ve got this model of. We generate pages in a build, we display our pages in the client, and then we can enhance our pages at the edge in a serverless environment, if we need to, not a lot of environments, not a lot of sites, or rather, the vast majority of sites, don’t actually need this, we could be serving things that aren’t, aren’t all that’s all that dynamic at all. But when we do need to, we can do things, excuse me, we can do things like enhance them at the edge. I really like this model very much. It’s very it’s it’s very powerful. It’s also very boring, which is great. I’m excited about this, this pattern, and I’m not excited about it in the terms of, I think it’s going to be flirting with me one day. I’m excited about it because I think it’s, it’s a powerful way of getting logic and moving parts into our sites, our applications, without having to have infrastructure to manage, without having to have the hostile environment of the browser or the unknowable environment sometimes of the browser being being a bottleneck. It’s a very exciting, very exciting paradigm, I think. So, what could we use this for? Let’s have an example now of this, to stop it just being lines and boxes. So I was thinking, what’s a nice, tangible example that will people will relate to? Of course, the most relatable thing on the web and maybe in the world, is Cookie Monster. Sadly, I’m sorry to say that cookie monster isn’t what I’m going to be talking about here. I’m going to be talking about to be talking about this cookie monster people who live in Europe, and actually people all over the world will be familiar with this kind of UI now. I hate it. I hate it so much. I think it’s one of the worst things that we’ve done to the web. I think it’s a danger to the web. I think it’s a danger to users, not just because, you know, it teaches people to be phished by giving them a huge call to action that just accept, get out of my way, accept the thing, not only because it it does need to give you the option to review your options, but if you try and see that often, like the hit targets, the click targets are a bit sketchy, so that you end up accepting them. UI. I hate them, not only because of those things, but also because often it takes up the whole UI, the whole interface that gets in the way. It doesn’t build trust, it just builds frustration, and people just hammer the button to get through. It’s just a really bad thing with lots of dark patterns and this, this, this convention of cookie consent banners. And UI is something that’s that’s manifested in a particular way, because, you know, it needs to display some content conditional kind of interface this UI needs to control cookies, needs to be aware of them, needs to be able to give you access to either set them or not, and kind of flag those permissions. And often that’s fiddly, so we end up with third party client side JavaScript doing that to for us as a result of that. You know, often it’s just a terrible performance killer. It really gets in the way of the rendering, the performance, rendering performance of content shifts all kinds of horrible things. And, you know, just the interface is just, it’s just horrible for brand and for trust and for lots of things. If you’re not picking this up, I’m not a fan, so maybe we could do this better. And maybe you’re thinking, well, this isn’t the most exciting example there is, and it’s just kind of fluffy and not of much consequence. Don’t think of cookie monster that way. He’s all friends and friendly, but can you imagine if he got angry? Terrifying. He’s absolutely terrifying beast. So we need to do this properly. So you know, if we don’t want on our projects to introduce some kind of logic on the server to do this, we don’t want to introduce some projects somewhere on the client to do this because of the performance issues, then the place that we could maybe do something here is in serverless environments in the edge, and it’s actually a really good use case for this. So I made a little thing that did this nicely. Is this as an example. This is this is me showing cookie consent banners. I’ve realized this might not be the biggest draw on the internet, but it’s illustrating a point, I hope so. This is just a little example remix site. As it turns out, it doesn’t really matter what the site is built with, because all of this, all of this is happening not in the server, not in the client, but at the edge. It’s this little layer that will add a bit of UI if the user is making a request from somewhere a territory that needs the cookie, consent banner. So in this case, you can see that I’m in the UK, and so this has been injected, and this has been just injected as HTML. You know, there it is in the HTML right before the body tag. That’s all that’s happened. You know, we’ve, we’ve detected that. We we need it. We’ve injected it into the into the HTML. So the when the page has been delivered, it’s there and it’s ready. There is no JavaScript here, or rather, there’s no client side JavaScript, you know, in the edge function there’s JavaScript, or rather, there’s TypeScript. So there’s but there’s nothing happening really. In the client the HTML arrives complete, and it’s location aware without needing to ask for permissions.

Phil Hawksworth 17:55
You know, often we see these, these banners, being displayed wherever you’re accessing from, because we have to ask for permission to get your location if we’re doing a client site. So we don’t need to do that also. This is sandbox from the rest of the site code, but it still gives control to the site users. So it’s a simple example, but I think it illustrates a point. So what does adding an edge function look like? Well, depending on where your code lives, what infrastructure you’re on, what tools and services you’re using, this might be a little bit different. There are lots of providers out there. I’ll happen to talk about Netlify because it’s where I work, so it’s what I know. But this is what adding an edge function to any project looks like there. You know, if you have a folder in the root of your your project called Netlify, and within that, you put an edge functions folder. All of the Typescript and JavaScript files in there can become edge functions, and this is what the hello world looks like. It will simply return hello world if you request, make a request to it on the path forward, slash Hello. So if we expand this then and start to think about what this looks like for our cookie consent serverless function, then we’re going to do a couple more things. We’re going to get the context from the Netlify edge functions library. Now this gives us access to things that happen on the netify CDN and to do with the request and response. So there’s a bunch of utilities in there. We’re going to have a little bit of UI that we’re going to reject, and that’s just included from a JavaScript string literal. This, this kind of Banner, bit of bit of bit of markup, and then we’ve got a list of territories where we need to apply this to. This is just an array of country codes that we can match with the location we get. So then we move down into our code, and we do indeed get from the context, we get the geolocation, we get that country code so that we can check against the list of territories where we know that’s applied. And if we if we need to do that, then we can, we can inject the the markup into the response, and we get the response again through this context, we can wait for the HTTP response, which is about to flow through. The Edge function to to the user, and we get the content of that so that then we can look for the end of the body tag and add the UI that we’ve got from our little library function. So all of this is doing is injecting some HTML into the HTML that was part of the response, the HTTP response already Simple as that, and as a result we get we get this right there in the page. Now this is something that I really like as a pattern of generate, not getting in the way of the generation of your pages. I love doing as much as possible upfront. I love keeping the client side simple, but as the response flows through the infrastructure. We can decide to do things conditionally to enhance that, or we could do things to gate it, or what have you. Here. We’re just enhancing the page by adding something to it. Enhancing is a strong term when we’re talking about cookie, consent, UI, but it’s something we’re all familiar with. We could do other things. But the point is that this is framework free, or rather, it’s framework agnostic. Now we’re using it there with remix, but it’s not remix is not aware of it, and it doesn’t depend on free wit, on remix. This is can be with any framework or without a framework is using what we call it, netify, the platform primitives. You know, we’re we’re able to interact with the HTTP requests. We’re able to do things like access, geolocation, have fine grained control over cache control and what have you. So really, we’re just using things at quite a low level that we can then build on top of. And this pattern of enhancing pages could, of course, be used in all kinds of ways. I mean, we could use it to localize the times of an online event so that you know, the HTML of this is being served correct for one time zone, but we could change that depending where people are accessing it from. Localizing is important. There’s your there’s your Z, everybody don’t, don’t, don’t hate me. Or we could be doing that for things like pricing data or stock levels, Product Data pages, product description pages on ecommerce sites used to cause such headaches for me. It used to be an area where there’d be many, many skews. So the idea of pre generating things wasn’t really, wasn’t really an option because of pricing changes, which means we need to regenerate all of the pages or stock levels. We need to regenerate all the pages. Here. We can build these things once and then just update the small portion of the page that needs to change as we let that flow through an edge function. So serverless functions like this can really, really be very, very powerful. I think I love this pattern, the idea that, you know, the building of the page is done, the display of the page is done. We don’t need to do any client side render either. Render either the part in the middle that when it flows through the edge, function that’s really, really fast, and if it were to fail, it can fail in a way that’s completely invisible, because you’ve already got a page that could be viable in the first place. So I love this kind of pattern.

Phil Hawksworth 22:58
So you might be looking at this and thinking, Yeah, this is fine, but what about data that’s not close to the edge? You’re updating things at the edge. We know that there’s a difficult scenario when you’re not you the data is somewhere away from the edge. Well, there’s lots of solutions to this, my my colleague, or rather my boss, Matt Biilmann, founder of Netlify. He wrote this article on the netify developer hub recently, talking about how to make edge edge rendering fast. And I’ll share the links to that and various things at the end of this. But in essence, what he’s talking about there is he built this kind of clone of Hacker News. Of course, everyone always does. It’s the canonical example where, you know, the user is far away from the data, the source data, the hack and user API, needs to get to the user. So maybe, you know, we’re rendering it with an edge function, because that’s nice and close to the user, but there’s still a huge distance between the data and the edge function. So we end up with this round tripping that can, that can be, can be long, and actually make it worse for performance. So a solution to that is, I think, another little API layer here, which we often do anyway. You know, we often use APIs to kind of aggregate various data sources, and here this is, that’s exactly what we’re doing. So it’s just another serverless function which sources content from the hack and use API and returns that to the edge function for rendering as well. Now at this point, we haven’t made anything faster, actually, until we do this, which is, we can use the Stell while, while revalidate pattern here to make sure that the data being returned from this kind of remote API, if you like, is cached appropriately at the various parts of the network around the edge, making that then very, very fast indeed. And Matt goes on to talk about exactly how to do this, but ultimately is adding fine grain cache control to these functions so that we can use the stale while revalidate pattern these primitives that I was talking about earlier. Okay, we’re kind of coming up on time, so I will just talk very briefly about a similar a. Emerging pattern. You know, we you may have heard some buzz about PPR or partial pre rendering, which sounds kind of familiar, kind of similar to the kind of thing that I’ve just been describing, about rendering as much as possible first and then enhancing it. Now, this is an emerging pattern in the next JS library framework, and it differs a little bit to what I’m describing, because rather than everything being generated first and then just enhanced at the edge, really, what’s happening is content that’s generated either first or at request time in a server, as that passes through the serverless infrastructure, then that’s also getting the opportunity to be enhanced as well, but it kicks off the requests to go and get that data, fetch whatever is needed, and rather injecting it into the HTML before it sends it down the wire, kind of sends down the wire the promise that it will fulfill that with a stream later on. So then the client, when that receives the data, it injects it into those appropriate places. So it’s a similar pattern to what I was talking about, but ever so slightly different in that that update does happen client side later on. Now for me, I don’t know it’s an interesting pattern. I think it’s pretty it’s very cool. It’s very clever. It’s very exciting. And next, JS does a really good job of kind of coupling these things together and making it convenient. But it feels to me like again, are we? Are we on this pendulum swinging between coupled and decoupled, monolithic or distributed. I don’t know there’s a huge convenience there as well. But I don’t know information is power and it’s good to understand these things. And I think we’re going to be seeing some really exciting experiments coming from it. I would say that there’s also just as of earlier today, Matt’s at it again. He kind of wrote an article about partial pre rendering using this, this pattern without any framework, again, using the kind of primitives that we’ve got access to. I won’t go through that now, but, but there’s, there’s a walkthrough of how you can get that running again, using the infrastructure that’s available without any particular framework at all. Should you? Should you wish to try that? Okay, so I’m into my last minute, so I think I need to wrap things up and say, Did we learn anything? Well, I hope, I hope so. Let’s, let’s see. I mean, I think a few messages that I’d like to call out are, you know, rendering patterns are yours to control. There are so many of them, and it can be hard to choose, but they are for you to control, and for you to make the choice about and to do that, you kind of need to understand the requirements so that you can make the choice. And I’d always advocate to try and start simple wherever is possible, do as much as possible in advance. As the other thing that I would kind of call out, I think it’s really valuable to be able to try and pre generate things as much as possible so the work is done ahead of time. I like to think about building serving websites as a restaurant. Now, you don’t want your mistakes to leave the kitchen, and so doing things in the build ahead of time as much as possible, I think, is a huge advantage. I’d say, Don’t be hypnotized by the pendulum. You know, trends change all the time, and it could be easy to follow those trends, and we’re all susceptible to them. I know I am as well. So I’d just be saying, Just be cautious of that, and kind of make decisions based on the requirements and the tools that you’re you’re aware of. And then, of course, my final message is, it depends. It always depends. We just need to know what it depends on so we can make make informed decisions. The only thing that this is not a suitable answer for is the question, should I off the Cookie Monster? And the answer that is an emphatic no, no, you shouldn’t, for myriad reasons. That’s it from me the my, thanks to the folks who I used images from. And also, there’s a bunch of links and resources in there. I’ll share these slides during the rest of the conference, they’ll be online soon. So for now, I think we’ll probably get into a little bit of discussion with Sean, and that’s it for me. Thanks very much.

Sean C Davis 28:52
Thanks, Phil, that was that was amazing. I I knew I was going to get so much useful information about rendering patterns, and I the thing I didn’t expect was to leave the talk terrified of Cookie Monster.

Phil Hawksworth 29:05
This is I can only apologize. Yeah, I wasn’t expect. That wasn’t my plan. But, you know, it’s important to be aware

Phil Hawksworth 29:13
it’s true. It’s true. Yeah, I’m thinking about Cookie Monster differently now. So yeah, we we have a couple questions that have come in from the audience. I have a long list as well, but for all of you out there, if you want to, we’ll have a few minutes here where Phil can answer some of your questions. So add them to that Questions tab. Okay, let’s start with the question from Brian. Brian says, I believe I read that vercel decided that edge rendering didn’t bring the performance benefits they expected in most cases, and they ended up going back to straight SSR, because the data didn’t live at the edge. And I know you explained this a little bit at the end, but Brian’s question is, how do you get around that? So maybe, maybe just add a little bit of color to that portion of the talk.

Phil Hawksworth 29:56
Yeah. So, I mean, so. That’s right. I mean, I I’m from an outsider there as well. I noticed that as well. I do recall that the the example that was citing in particular was one particular site that was that was built in a particular way. But nonetheless, I think this, this idea that the data not being close to the edge does mean that edge rendering can, you know, kind of have its limitations. And, you know, I described there just, just briefly, this idea of being able to have better cash control, to bring things closer to the edge, to make them persist at the edge. And I, you know, when I, when I talk about the pendulum going backwards and forwards and extremes and being absolutist as well. I’m very cautious about ever saying this is the approach that you should use for everything. There are some things that are going to be more this is going to be more applicable to than others, but there are other but there’s also we shouldn’t. We shouldn’t just dismiss the entire approach because it doesn’t fit for everything. It’s like when I was a big fan of regenerating. I see there’s some comments about that as well. We maybe talk about that in a bit. I was big fan of pre generating as much of a site as possible. And I’d have sometimes have people coming up to the event saying, well, that’s fine, but you wouldn’t be build amazon.com that way, would you? And my answer that is, I agree. I wouldn’t, but are you building amazon.com so for a great many uses of and applications of what we you know, what we’re using this for, it can be very, very applicable, very, very appropriate. But in those cases where we think, well, the data is not close to the edge, there are things we can do, such as the example I cited very quickly there about taking greater cache control over the caching so that you can cache things close to the edge, or at the indeed, at the edge, for folks, so that that request does does indeed work. And I think without having access to those primitives and now having access to those controls, then yes, you may well fall foul of that. But as soon as you’ve got access to those kind of things, then it starts to open. Starts to open the door again. So I think, I think we are going to see, you know, now, these tools are emerging. I think we’re going to see some interesting uses of those, and examples of that, that kind of debunk a little bit the idea that you can’t, you can’t do which rendering it’s not, it’s not appropriate. I would also say that I’m, I’m a fan of, as you heard, trying to already arrive with as much of the content rendered as possible. So I wouldn’t always try and do all of the rendering in at the edge. I like the idea of enhancing. There are a few other models as well where it renders everything in serverless functions or at the edge. And again, there are very good uses of that as well. But that’s not the thing I reach for first. I try and kind of gradually layer on the complexity as needed, rather than reaching for it straight away. But, but yeah, my the short answer after my long rambling one is greater control over caching opens up all kinds of possibilities for that.

Sean C Davis 33:00
Yeah, and you had mentioned that you can use that stale while revalidate pattern to have the to basically have the response as close to the user as possible. And you know, kind of in making a smart decision on when you update that content. Have you? Have you come across, is there? Is there, like, classic use case that would really help, kind of paint a picture for when would somebody apply that pattern to their site?

Phil Hawksworth 33:34
I mean, apply the pattern of using stalewire, revalidate?

Sean C Davis 33:39
Yes, but then, but delivering as much as possible from from the edge, as close to the user as you can.

Phil Hawksworth 33:48
So, I mean, I think some of the examples I cited before about things like product pages, where you’re adding pricing data or stock levels, those are, those are very applicable transactional things that so parts of the flow where you’re actually you have the user is creating things and actually changing the state of things. That’s somewhere where it could be a little bit more difficult, where things are much more involved in writing, not just reading. Of course, a lot of the things that were involved in building are mostly predominantly reading applications get to the point of your writing as well, or further down the line when you get through to the kind of the payment and that, that execution part of it, that adds a bit of complexity there, but everything up until that point is very applicable, I think, to do exactly the kind of the pattern that I that I just mentioned and And so you can kind of blend those, those approaches together. But yeah, I think that the more that we can consider this as an enhancement, a way to enhance the content, rather than deliver absolutely everything, I think those are the those are the use cases that kind of fit, fit the best,

Sean C Davis 34:58
sure, and I think it’s interesting that you. You pick a, you know, a product page, or an E commerce example, but then, but then also say, Well, you’re not building amazon.com so something I’ve, I don’t have a clear picture on in it’s like, is there? There’s a line somewhere in there where you’re like, this, this pattern works. It sounds like what you’re saying is this pattern works up to a point, and then you need to, you need to, you need to take a different approach at some scale or level of complexity. Is that? Is that kind of like a feeling that’s hard? Is it? It depends. Or do you like, how would you approach? It seems like reach for this, this, you know, pre rendering as much as possible, and enhancing by default. Where’s the tipping point? When it’s you might even start a project without that pattern?

Phil Hawksworth 35:52
Yeah, it depends. Sorry, to be such a, such a nuisance there, but, but, yeah, it that line changes all the time, and it changes because things like the tools that we’re building with are now way faster at rendering, you know, or regenerating pages than they ever used to be. That’s just getting better and better and better. It can depend on the complexity of the templates that you’re combining and the views that you’re you’re creating, some of them much simpler than others. And I think so benchmarking is, is the thing, kind of measuring and benchmarking, you know, as your as your site grows in complexity and scale, you can start to see how your build is evolving. And you know, if, if, when you try this out for the first for the first time, oh, the build takes 20 minutes, half an hour. It’s like, okay, this, this might not, this might not work for me. You might need to think about this slightly differently. But very often we’re in the position where, you know, we start the, you know, we’re not usually in the point that our projects start with a million different skews, most of us, some of us, that is the case, but most of us not. And so, you know, I think we can start to when we start building these things out, and we see how long builds take, and we actually measure them. If it’s acceptable, then great. We can see how much further we can push it. But over time, those are going to grow in growing scale, growing complexity. But luckily, the tools are evolving as well. You know, things are so much faster than they used to be, and we can optimize this in so many different ways. And the idea that we can remove the expensive queries of the things that are very dynamic and just build the things that are much more static and much more consistent, that really switches where this, this tipping point is. And it’s a pattern that I’ve seen being used quite a few times, and it’s been quite successful, but it’s also one that people are quite scared of, because the idea of building something that’s got dynamic elements that isn’t completely delivered dynamically, I think we’re only just starting to get comfortable with that, and I think the patterns that we’re seeing emerging are starting to kind of build confidence for people building things that way, and I think that’s only going to continue. I hope,

Phil Hawksworth 38:06
yes, yes, definitely. Well, thank you very much, Phil, there is another question hanging out. It’s from Jan checked out. Maybe you can respond in the chat so that we can move on to the our first break of the day. But really, really appreciate this talk gives me It’s so inspiring, gives me so many different things to think about and and, yes, appreciate all that content. Thanks, Phil,

Phil Hawksworth 38:29
great stuff. Thanks very much. Well, yeah, I’ll hang out in the chat. I’ll try and answer as many questions I can, and I’ll, I’ll be around so So, thanks ever so much for having me, and thanks everyone for for listening. I’ll share, I’ll share links and resources and bits and bobs i.