The Changelog: Software Development, Open Source - A new batch of web frameworks emerge! (Interview)

Episode Date: October 7, 2022

This week we're talking fresh, faster, and new web frameworks by way of JS Party. Yes, today's show is a web framework sampler because a new batch of web frameworks have emerged. There's always something new happening in the front-end world and JS Party does an amazing job of keeping us up to date. So...what's fresh, faster, and new? The first segment of the show focuses on Deno's Fresh new web framework. Luca Casonato joins Jerod & Feross to talk about Fresh – a next generation web framework, built for speed, reliability, and simplicity. In segment two, AngularJS creator Miško Hevery joins Jerod and KBall to talk about Qwik. He says Qwik is a fundamental rethinking of how a web application should work. And he's attempting to convince Jerod & KBall that the implications of that are BIG. In the last segment, Amal talks with Fred Schott about Astro 1.0. They go deep on how Astro is built to pull content from anywhere and serve it fast with their next-gen island architecture. Plus there's an 8 minute bonus for our ++ subscribers (changelog.com/++). Fred Schott explains Astro Islands and how Astro extracts your UI into smaller, isolated components on the page, and the unused JavaScript gets replaced with lightweight HTML — leading to faster loads and time-to-interactive.

This week on The Change Love, we're talking fresh, faster, and new web frameworks by way of JS Party. Yes, today's show is a web framework sampler because a new batch of web frameworks have emerged. There's always something new happening in the front end world, and JS Party does an amazing job covering that. So, what's fresh, faster, and new? The first segment of the show today focuses on Dino's fresh new framework. Luca Castaneda joins Jared and Frost to talk about Fresh, a next-generation web framework built for speed, reliability, and simplicity. In segment two, AngularJS creator Misco Haveri joins Jared and Cable to talk about Quick. He says Quick is a fundamental rethinking of how web applications should work, and he's attempting to convince Jared and Cabal that the implications

of that are big. And in the last segment, Amel talks with Fred Schott about Astro 1.0. They go deep on how Astro is built to pull content from anywhere and serve it fast with their next generation island architecture. As you may have expected, there is a bonus on today's show for our plus plus subscribers. Eight minutes. In fact, Fred shot comes back to explain Astro islands. It goes deep on how to extract your UI into smaller isolated components on the page and unused JavaScript is replaced with lightweight HTML to

guarantee faster loads and time to interactive. If you're not a plus plus subscriber, don't worry. It's easy. changelog.com slash plus plus will get you started. A big thank you to our friends at Fastly and Fly. Bandwidth for changelog is provided by Fastly. Learn more at fastly.com.

And our friends at Fly let you put your app and your database closer to users all over the world. It is like a CDN for your entire application. Learn more at fly.io. Hey friends, Influx Days is back. This is a two-day developer conference from our friends at Influx Data and is dedicated to building IoT, analytics, and cloud applications with InfluxDB. It is happening November 2nd and 3rd. Learn more and register at InfluxDays.com. This year will showcase the breadth and depth of the InfluxDB platform as the critical infrastructure behind today's applications and digital businesses.

If you're new to Influx or you're building advanced time series applications, Influx Days sessions and trainings will give you the skills you need to support your individual builder journey. Here's the breakdown. Two free days of virtual user conference. Watch parties in SF and London. Free training on Telegraph open source server agent. Pay training on Flux in London. Again, this is all happening November 2nd and 3rd.

Learn more and register at InfluxDays.com. Again, InfluxDays.com. it's luca casanado from the dino team welcome luca hey thanks for having me thanks for being here fresh off your launch and I can't avoid a pun. Aha. You've launched a fresh, new... Heard that one before. Yeah. It's going to...

You're going to hear it a lot more. Yeah. As well. Sorry, you picked the name, not me. I do like it. Yeah, it's good. I like the lemon-based icon as well. Cool stuff.

A new web framework for Deno, from Deno. It's like an official Deno project, right? Awesome. What was the idea? Why? What were the impetus or the reason why you decided to build this? Yeah, so originally the idea was actually not to build a framework. The idea was to just have a tech demo to showcase a bunch of cool features in Deno and how you can use them together to make websites, essentially. And over time, this turned into, oh wait, this is actually really nice to use.

We started building utilities all over the place, which were nice to use. And it turned out that we could integrate this all together into some sort of cohesive bundle. And we started using that for some internal projects. The team internally really liked it, so we decided to put more effort into it and open source it. I like how the JS community, and I guess the TS community as well, what do we call ourselves nowadays? The web devs, are starting to embrace

just even the term framework. We're starting to see frameworks come out. In a long time it was libraries and routers and packages. And it was very much a build your own thing out of these smaller things. But I think at this point, frameworks are, they're back again, or they're here for the first time, perhaps. I think we're starting to be like, you know what, it's nice to have a lot of things all in one place maintained by a group. And I wonder, was that something you all thought about, even the word framework for this thing? Yeah, yeah. One of the core ideas of Deno for a long time, to have this whole battery is included runtime, where we're not just a runtime, but we also provide things like formatting and linting and testing and dependency management and documentation generation and a million other

things, all in the same binary maintained by the same people with the same opinions to give you a cohesive experience. And I think it's very nice that we managed to also extend this to this web framework now because those same ideas that we build Deno with, we also use to build this framework. So it really nicely integrates with Deno and it has the same core principles that things should be fast, and things should be easy to use, and things should

not be bloated. Ross, what about your thoughts on frameworks versus libraries? I know you've even very much bring things together, make your own decisions. I do like that ethos of I'm going to pick, like a craftsman would pick their tools. And I know that you've built a lot of websites over the years, and it seems like each time we talk about the tech inside your websites and it's always a little bit different like you pick different things curious what your thoughts are on like the framework movement that's happening currently i'm a huge fan of it actually i i'm starting to lean more toward that direction just it's nice to not have to think about these details when

you're trying to solve a problem and to keep your mind at the level of the problem you're solving and not constantly going down into the lower level and trying to tweak the way the routing works or or that you know these kinds of implementation details when you're trying to just solve a problem so i'm a huge fan of it now and it helps you focus on what you're trying to just solve a problem. So I'm a huge fan of it now. And it helps you focus on what you're trying to do. Just the actual problem you're trying to solve. Yeah. I feel like very often with a lot of people, it's like they think they don't like it until they start using it. Like they think they don't want the opinionation until they use something which has the opinionation and then they don't want to go back.

Because it just, once you've used it, you realize like how much time this saves you by not having to make all these decisions, but have someone else make the decisions for you. I'm from the old days of the web where pre-Ruby on Rails, there wasn't much. And then that really brought the framework into the forefront. And then there was a backlash against that in the Ruby world with Sinatra, which is more akin to Express in terms of what it provides. And you could use Ruby on Rails, which is a batteries included framework in the Ruby world,

right, to build your web apps. Or you could go the Sinatra route, which was like this super clean, minimal, but beautiful, basically router plus some other things. And if you use that, you would then pull in different things that you need. And I got attracted to that style. And if you use that, you would then pull in different things that you need. And I got attracted to that style. And I went that way, a couple of websites. And what I found myself was like piecemealing together Sinatra plus all these other components to basically be my own ad hoc Ruby on Rails. And then, but it was just mine. I'm the only one that, you know, it wasn't along with a big group of people working on it. I had all these 17 different plugins in order to recreate that.

I think something about that gravity of a bunch of people all putting their work on this one thing especially when it's supported by the runtime creators and maintainers is pretty attractive even though at first it kind of offends your sensibilities of like hey i'd rather pick each part eventually you start to see like why that's attractive and so it's pretty cool that i think we're starting to see a lot of people step up and say let's let's go batteries included and see how that turns out so fresh has its own view of the

world every framework does. Otherwise, why create a new one, right? Just contribute to one that currently exists. Tell us the perspective of the Deno team and the Fresh team on what a web framework in 2022 should look like. Sure. So Fresh is really built to be fast, like fast as in it serves fast websites. And you as a user using a website should have a great user experience and a reliable user experience, even if you're in a slow network or on a slow device. It should not drain your battery. It should try to use the platform for as many things as possible. It shouldn't try to reinvent the wheel. So Fresh really tries to not reinvent the wheel pretty much anywhere. It tries to really stick close to things that have already proven popular in other frameworks

and that have shown to be very fast or very reliable for users over the last couple of years. One of them being server-side rendering by default and not shipping megabytes or even hundreds of kilobytes of JavaScript to users on every request, but rather shipping them rendered HTML and then hydrating parts of that HTML as is necessary. So that's kind of the worldview. Try to make it fast and small and use things which people are already familiar with and have proven to work well. So no build step, no configuration unless you want to. A lot of the niceties the zero javascript

overhead into the client by default but of course kind of allowing you to opt into more and more of that as need be so it's a multi-page server-side rendered application like as you navigate different pages in your browser are you loading fresh pages every time? Yeah, exactly. So there's no client-side routing at all. It's all completely server-side routed. And there's obviously downsides to this, right? There's upsides and downsides. There's a trade-off that you have to make. If you want to have very great offline experience, that's not something you can do. You need to do more in the client. But most pages are things like blogs or marketing sites or like even applications where like e-commerce sites, which are their applications, right? Like you can, there's a lot

of interaction that goes on there, but you don't want them to imagine to buy something. You'd have to like open your web browser or your app store, sorry, search for the store that you're trying to buy something from, download their app and then start using that. Like that's sort of how we're building a lot of sites right now. Except you don't go to the app store, but instead you type in a URL and then you have to wait six or seven seconds on your 3G connection, or 20 seconds for all the JavaScript to download

before you see anything that's interactive. That's really not a great development. We want to push back on that and try to do as much server-side as possible and really only ship things to the browser that's absolutely necessary to be in the browser. Things that require sub-100 millisecond response times. Changing the color of an input field as you type input validation, that kind of stuff. I wish there were some heuristics around that decision of client-side

routing versus server-side routing. Because it really seems like there are cases where each one has its strengths. And I think my view of the world is that server-side rendering and routing, I guess, as a consequence of that, is probably like the 80-20. I think it's on the 80 side of websites and web apps. Whereas client-side is probably more on the 20. And if it was me, it's probably like 90-20. I think it's on the 80 side of websites and web apps, whereas client side is

probably more on the 20. And if it was me, it's probably like 90-10, but that's just my view of the world. But I think it's hard to make that call. Have you ever had to decide like, do I do client side, like SPA? Do I do client side routing? Do I do server side? And what are the tipping points that would push you in one direction or the other in terms of like what you're trying to build i think that with spas or you know client-side routing single page apps that that model you have the flexibility that if you do decide you need some of those features like you do want to have i don't know let's say audio playing across page loads so like you can have music you know some audio player playing even when you click a link right or

something like that that stuff's just not even possible in the, in the fully multi-page app model. And so I think some people probably are picking these client side, single page app, you know, models for their website, just because of the flexibility of like not knowing whether they're going to need that in the future and not wanting to be trapped, I guess. I felt that myself when I was building BitMidi, I needed that behavior. And so I was forced into this sort of model. But then other times I wanted to do, I wanted to just use like React or Preact and have this nice sort of modern development flow and, but also be able to do server-side rendering and have no client

JavaScript. And I felt like it was pretty hard to get, like, I was either going to have to go and build a really old school website or have to take on client-side routing and client-side everything. And so it's cool that fresh is, I really liked it. It's like you get to write your app in a modern way and get the sort of like one-way data flow that React and Preact and all that stuff gives you while still getting all the advantages of a multi-page app. So I think this is actually going to be a really nice sweet spot for folks. Yeah, I always like the example of Figma and your blog page. Figma is very obviously something that you need to do client-side rendering for.

This is something that's impossible to do with servers. There's just too much interaction. But something like your blog, this probably does not require server-side rendering at all. Or sorry, it doesn't require client-side rendering at all. It can be fully server-side rendered. And it's really difficult to figure out at what point is an e-commerce site?

Is that something you need to SPA, MPA? I think it really depends, as Farah said, on exactly what you want to be doing. If there are things that you require an SPA for for then you sort of have to use an spa right but like i think you should try to default to an mpa and then only go with the spa route if you really have to like if there's no other way around it yeah i would agree with that what's the flow like then for upgrading to an spa or going into an spa once you've started building something in fresh. I see on your site, you have this thing called like an island. Maybe could you explain a little bit about islands? Cause I've never heard. It seems like every so often there's these new words

that the JavaScript community kind of invents for new concepts. Like tree shaking was one a while ago that it felt like we already had a word for it. Like in C compilers, we call that a linker, you know, the linking step. Um, but we had to create a new word. So is islands something like that? Could you explain what an island is for us? Yeah, yeah. Islands is like progressive hydration, essentially. Well, it's not quite progressive hydration. It kind of depends on how you define progressive hydration. The idea of islands is that you do server-side rendering and you enhance, or with client interaction, only some components of the page on the client.

So for example, you have a blog page with a comment section. You want the comment section to be highly interactive and client-side rendered, but you want the markdown itself of the blog to be completely service-side rendered. The idea is that that comment section can be an island, which is client-side rendered. The JavaScript for that is shipped to the client, but the surrounding scaffold does not need to be shipped to the client at all. Only the markup itself, the HTML, needs to be shipped to the client.

And Jason Miller came up with this concept of island architecture two years ago, I think. He wrote a blog post about it. There's a really great illustration on his blog, actually, that really showcases very well what it looks like where you have this page and you very specifically hydrate certain components but not the entire page. Okay, so an island would be a specific component

that you want to hydrate client side. Let's take the comments example because I think I get it but I might not get it. Is your whole comments section the island or is each individual comment an island? As everything in software engineering, it always depends, right? Sure, sure.

Let's say you want to update the comments, like you want to live refresh them in the browser as they're being posted, you would make the entire comment section an island because then you can add or remove comments from the list. If instead you want to, let's say, each comment has a share button, which opens a share dialog,

and that needs some client-side JavaScript, then the comment content itself can be server-side rendered, then you could make one island per comment. It's really the smallest component surrounding the interaction, I guess. Okay, so let's imagine a circumstance, the former circumstance. So we have a comments section

that we want to be highly interactive. Each comment just like floats in from the site or whatever we want to do. Okay. So I make my comments component an island and that means it's client-side hydrated. But what about the existing comments that are previously there so on a typical

mpa server side rendered you know if i have seven comments on my blog post and i hit command r to refresh my server is going to render the html for those seven comments now does that still happen but now you hydrate the interactivity or you're actually just dynamically loading the html or json whatever it is, that gets hydrated. You can do either. So by default, what will happen is that it will render the HTML on both the client and the server. So the fresh homepage has like this counter example on like right in the homepage. That counter is server side rendered, but the server side renderer has the buttons disabled, for example.

So when the client hydrates, it enables the buttons. So you still have the shell there, you don't get a layout jump, but it's not interactive yet, and it shows that it isn't interactive until the JavaScript is there on the client to deal with it. But if you want to render some scaffold on the server

that's in your component, you can conditionally check, if I'm on the server, return scaffold. Or if you want it crawled. So maybe I want my comment section crawled, and so I'm going to server, return scaffold. Or if you want it crawled. Maybe I want my comment section crawled, and so I'm going to server-side render it. That being said, every time you add a comment, you break my cache, and now I'm dynamically rendering this page

more often than I would otherwise, and so there's performance concerns. It's kind of an it-depends-all-the-way-down. It sounds like with the island's architecture, you have the flexibility to make those decisions on a case-by-case basis. A lot of frameworks like Next.js and Remix, they'll send the entire renderer for

the entire page to the client to be able to do client-side navigation and routing. And because Fresh does not do any of this, you can be very, very specific about what you sent to the client. You can really scale it down to as small as you need it to be. And what are the wins for doing that?

So the wins are that you ship a lot less JavaScript to the client. If you have a blog and use Next.js and you use React Markdown or whatever to render some Markdown into HTML, you do that once on the server, then you ship the entire rendering infrastructure to the client, you ship the Markdown to the client, and then you do the rendering again on the client, even though it's already been done on the server, then you ship the entire rendering infrastructure to the client, you ship the markdown to the client, and then you do the rendering again on the client, even though it's already been done on the server. What's the point there?

That's just wasting CPU cycles on your mobile device. The content hasn't changed since the server rendered it versus when the client renders it. So you can avoid that entire thing. So this islands concept is not like a fringe part of fresh. This is like core to what fresh is, right? Because I generated a scaffold that happened. There's routes and there's islands. These are folder names in the structures, islands and routes.

And so you're gonna be writing some islands, I suppose, when you're using fresh. Yeah. Okay, Frost, is this an old concept that's been renamed or is this a new concept for you? Because now he's explaining what it means. I mean, for me, it makes sense, but I'm not sure if it had like a previous name or if it's actually just been invented by Jason Miller and the JS peoples. It's not ringing any bells for me. I mean, I know there's other frameworks that let you decide whether certain components should run on the client or on the server. I think Meteor even had like something a long time ago i don't

know what they called it i think my question about islands is just like how easy is it to go between something being an island and something not being an island like because you have a whole folder there for it so like if i start making some islands and then i realize actually i don't want this to be an island is it a whole bunch of work to go back and forth because i would worry about no i'd almost want it to be just like a boolean or something that i could turn on say yeah do this on the client or do this on the server yeah and it really is like the boolean is is it in this folder or is in like is it in your components folder is in your islands folder okay that's it like that's the only difference the files are exactly the same it's just a regular pre-art component the code is just a regular pre-art component yeah okay and like the

server-side render will automatically figure out when you're importing, or actually not when you're importing, but when you're using an island, and it'll only ship the code to the client if you're actually using a given island. So you can have hundreds of islands, and it'll only send the code for the islands that you're actually using to the client. Okay.

So the framework is just smart enough to know it's in this folder, these are islands, and if it's not, it's not an island. That's your indicator. Yeah. So drag and drop for us, just drag it out of that islands folder, drop it into the components,

I guess. Yeah. Interesting. Not the best diffs. Well, I don't know. Like on GitHub, like a Boolean prop or something would be a better diff in terms of like,

I'm switching it, but you know, trade offs. I also wonder if you're going to want to be, have more flexibility down the line in terms of like, how do you deal with an island? Cause like you might want to have certain ones where there's not even a server side render at all. And it's like 100% client side, or maybe, uh, you want some where it blocks the page. Like you want to, this like Island is super important. So you want

to like, I don't know, send it like pretty urgently down. Or I can imagine somewhere you would say like, don't even like load the code for this until they scroll it into view. Cause this is like a really low priority Island. So just save on that JS. If they don't even scroll to the comment section, you know, don't even send it. I wonder if you're going to do, if you're going to need to add more options and more, more flags there, and then the islands folder won't be enough. Cause you'd need like islands and then like three other kinds of types of islands. Yeah. Yeah. I get it. So I think right now what fresh does is it will hydrate the islands as quickly as it can but it'll like still try to yield to the browser as often as it can so you don't like block animation stuff like that but it is actually totally possible that we add an option

in the future where you could just like export an options bag from your islands file in your islands folder so the other restriction is that you have to have one island per file in the islands folder. So every file is specifically one island. So you can have an options bag there which says this island should only be hydrated once it scrolls into view. Or once, like it should only be loaded on small devices or it should only be loaded when this media query matches or whatever else, right? It's just not implemented because, yeah. That pretty cool yeah that's cool so the islands folder then the routes folder tell us about routing how it works yeah so the routes folder is actually very much inspired by next.js this is one of these things which it just like next.js did an awesome

job originally with how the routing worked still does i does, I think. It works the same way. It's one file per route. You can have dynamic routes where you specify the matcher yourself if you need to do something really advanced. But yeah, it's one file per route, and the route can have a component that it renders, and it can have a handler. And that handler can do things like data loading.

Handlers are really just async functions which take in a request and return a response, web request and web response. that handler can do things like data loading. Handlers are really just like async functions, which take in a request and return a response, web request and web response. So you can like do anything you want in there. And at any point in time, you can call the render function. This might not make much sense if you haven't seen the code, but it's right in the documentation if you want to look at it. And you can call that render function that will render out the component into a response. And by default, you don't need to specify this. The default for the handler is that it just renders out your component. But if you want to do data loading, you can do that in there. Or if you want to do a redirect, you can also do that in there.

You can do anything you want in there. It's just an HTTP handler, right? And you can have different HTTP handlers for post methods and get methods, so you can handle form submissions that way as well. The routes folder is really, you have one file per path like path matcher you want to match and inside of there you can declare both the component to render for that page and the handlers for each of the http methods that you want to handle this is really cool i like it a lot it's really elegant thanks yeah yeah yeah it's cool you have you have like a handler function that gets called and you can do your data fetching in there and then you

can have the jsx component that gets passed in all the props this basically come from anything that's matched in the url so like props from the url like different you know sort of substitutions in the url and then also anything that the get handler decides to return so that's where you can do your your like fetching stuff from the database or whatever you need to do that's really cool does that mean that this get handler thing runs every single for every single request yeah okay yeah so what you can do and this is not implemented right now well it is if you put in some muscle work yourself but you can cache these things as well you can have something called middlewares, which allow you to essentially intercept routes before they're matched,

or intercept large swaths of routes all at once. And then you can do things like caching, for example, if you don't want to re-render on every request. So how would that work if you wanted to have a page that you build it only once a day or something like that? So the idea with Fresh is still that you always have a server running. It's really built to deploy to the edge, to deploy to things like deploying Cloudflare workers,

where you can render really close, like server-side render close to your users, and where the cost of doing that is very low. So if you want to do something like that, what you would probably do is you'd put a CDN in front of the origin and use cache response headers to tell the CDN to cache pages for a given amount of time.

Which is what we do with changelog.com and it works great. I think it's actually a really great strategy. It's just server-side render it, but then just cache it for as long as you want at your CDN. Now that assumes that you have a CDN, of course. But what about the data then? If I have my Dinos running on all these different Cloudflare workers

or Dino deploy edges, and I'm server-side rendering a response, but let's say I've got a Postgres database that lives in LaGuardia or something. Do they all just connect back to that? Or is there a way of making that sucker live close to the edges? It's kind of a loaded question

because I know this is something that lots of people are working on. I want to hear what your thoughts are on it. It really depends. As always, it depends. Cop out. I'm just prefixing this because I'm going to answer a bunch of different ways here.

So one way of doing this is if you're really read heavy, you can do global distributed replicas, right? Right. For your data. If your data doesn't change very often, you can do global distributed replicas for your data. If your data doesn't change very often, you can do caches. If your data does change very often, you can use something like CockroachDB, which can run in a bunch of regions across the world.

Even inside of the same SQL table, you could have certain rows live in certain regions and certain other rows live in certain other regions. For example, for users that are in the EU, you'd have their data live in Frankfurt. And for users in the US, you'd have it live somewhere in the US, in Ohio or whatever. And for users in Asia, you could have it live in, I don't know, Singapore or Japan or something like that. This really depends exactly on what you're doing.

For a blog, it probably doesn't matter too much. Even if you have a comment section on a blog, you could do caching there, where if a comment shows up after 30 seconds versus after none, no seconds, it doesn't really matter too much. Can you render an island by itself? And the reason why I ask that is,

I'm starting to think about the situation where you have this server side rendered or cached in the case of what you're saying with put an origin you know put put a cd in front of your origin and cache the response that works great except for like lots of websites have just like some sections that are dynamic let me change that not just dynamic but personalized to the like the signed in user for example yeah and so that breaks a lot of caching in many places. And you're like, well, I have to render the whole page dynamically because it's different for Luca than it is for Feras.

And I can have one that's for everybody who's logged out, but once you're logged in, it breaks. But I think maybe with islands, if you had certain areas of your site that are personalized, you could potentially have a static version of the HTML, server-side rendered, quote-unquote, but it's the same every time or whatever, cached, and then maybe hydrate just the dynamic personalized portions.

If you could have an island by itself just be rendered. Is that something people are doing? Yeah, so that's possible. One problem with that is that you would essentially send back an empty shell to users if they're signed in right, and you would then fill in that shell using client-side rendering. We much prefer the model where for stuff like this, you just render the page on every request dynamically.

We have these edges nowadays, like DinoDeploy is like 34 regions across the world. You can get like 50 millisecond response time from anywhere. Yeah, but now I'm going back to LaGuardia for my data like if you think about an app like Facebook which I honestly don't know how it works because I haven't used Facebook since like 2008 but I know it has like Messenger

I know it's got your list of friends it's got your news like all these things are highly personalized to who you are like all that data needs to get fetched from some database somewhere at At that point, your edge executions, they're kind of moot, aren't they? Exactly. You need to have your data distributed as well. If you only have your compute distributed, but not your data, then that's not great.

And things like CockroachDB, which is Postgres compatible, by the way, does allow you to do this. It allows you to spread data across the world to where your users are so that you can have really fast read and write access to your data. If you don't care about write access so much, you can have global replicas. Global replicas will allow you to do

really fast reads from anywhere at the cost of slightly slower writes because you need to talk to some central database for the writes. This really goes hand in hand with having some robust story on global distributed data. And I think that is actually something that currently we're really lacking. We don't really have a lot of good options for that. And I don't want to leak too much stuff, but this is something we are working on for DenoDeploy.

And to have really awesome globally distributed data where you don't have to think of these trade-offs as much. It'll just figure it out for you. So you can have fast read access anywhere to your data. I think that's the goose that lays the golden egg right there. It's interesting to hear that you're working on it. I know Fly.io, for instance, is working on it. I'm pretty sure Cloudflare is working on it. I bet Netlify is working on it, et cetera.

So exciting. And like you said, there are people like Fauna, Cockroach, who are providing the data layer for those things. But somebody that pulls it all together into a singular service, I think is a pretty compelling offer at that point. I think until then, all this other stuff is cool,

but you're kind of like, get that one missing piece. You want to tell us more? I mean, you don't want to say too much, but you could say more. I don't want to get you in trouble. He's just smiling at me now. No comment. Let's take a break right here. We'll tease him. We'll have a cliffhanger. This episode is brought to you by our friends at Square, developed on the platform that sellers trust.

Here's what you can do with Square. You can bridge more experiences. You can build online, mobile, and in-person commerce experiences that connect more customers and sellers. You can build custom booking solutions. You can create and track orders. You can accept payments. You can manage and curate inventory. You can organize customers. You can manage employees. You can extend Square gift cards to your app. You can use Afterpay. And all this is powered by the world-class Square APIs and SDKs that enable you to build full-featured business apps for yourself or millions of Square sellers. So much is available as a Square Solutions partner.

Learn more and get started at changelog.com slash square. Again, changelog.com slash square. Okay, let's get into it quick. An HTML first framework. Mishko, there's lots of frameworks out there. You're the creator of one of them. It's still out there. People still use it, K-Ball. Lots of people are still using it. But there's React, there's Vue, there's Svelte.

There's new frameworks like Fresh from the Dino side. Why another framework? The million dollar question. Yeah, that's a very good place to start. You know, why another framework? The million dollar question. Yeah, that's a very good place to start. You know, why another framework? And you're right, there is a dime a dozen for them. Isn't that out there? So I'm going to go on a limb here and hopefully I'm not going to be too controversial. And I'm going to say that like all the existing frameworks you're familiar with, Angular, Vue, Svelte, et cetera, and kind of Angular, I'm going to maybe take some credit here, kind of started the trend of component-based client-side frameworks. They all are essentially the same in the sense that how they work. But of course, the syntax and the DX is very different,

right? So do you like your templates in the form of a string? Do you like them in the form of a JSX? Do you like them inline together with the code or separated in the files, et cetera? These are all different kind of trade-offs different frameworks make, but in the heart of them, like at the core of how they work, they're all essentially the same. And what I mean by that is that they really have one concern and that is to just render things on the client. And it's pretty much what they kind of all do. And so quick is a different thing, right? Quick is what I call resumable. And the best way I can explain resumable is, well, let me back up a second. So the existing frameworks that we have, I call them replayable, meaning that when they start up on the client, so if you do server side rendering, they have to replay all of the work that the server did in

order to get them in the correct state, right? And we have a word for that, and the word is hydration. And what that means is that when you navigate to a page, you might immediately see a server-side rendered content, but there is some time before you can actually interact with the page. And the problem is, the more complicated the page becomes, the more time it requires to wake up. And of course, we have tricks like lazy loading, but it turns out lazy loading doesn't quite work here because lazy loading is only useful for components that are not currently in the DOM tree. If a component is in the DOM tree, you have to hydrate it. And that means that even if it's lazy loaded component, you have to load it and then do all this stuff. So all of that means in practice that especially on mobile devices and slow connections, the startup performance is

kind of bad. And Google has this thing called Google Page Speed Score. And they measure and they look at different websites and how they do. And they're just trying to kind of push the industry towards like faster, better experiences for the end users. And the Google Page Speed Score is not very good for most websites, right? So, and then the reason I'm going to argue for that is because all these frameworks have this thing called hydration. So yeah, I kind of spoke for a long time in the thing

and i haven't really talked about quick but does that make sense so far i'm with you okay well you with them yeah okay so before i kind of explain how quick works i think it's useful to kind of go and do a parallel so back in the day when like VMware first came out virtual machines, I was blown away with a particular thing about them, which is that on my host computer, I can boot up, let's say Linux as my virtual machine. And the Linux boots up goes into through its boot up process. And finally, at some point, I can log in. And once I'm logged in, I can, let's say, open up a Chrome browser. and I can navigate to like Google Docs, for example, I can start writing my document. And at some point, I can just save the virtual machine into a disk and I can take that file and send it to a friend of mine.

And that friend can then just open the file up and continue exactly where I left off, right? Specifically, they don't have to go through the boot up process, the login process, the opening up of the Chrome or Google Docs or anything like that. They literally, bam, they're in the final thing and ready to go. And this is what I call resumable. And it is specifically how our current frameworks do not work.

They can't do that trick. Instead, what they do is they essentially, every time you do navigate to a page, they, for all practical purposes, they have to boot up. And this boot up process is what we call hydration, is really the way the framework recovers all of the information about where the components are, where the listeners are, what is the data, and so on and so forth. And we have some tricks, like we can like prevent the client application

from doing fetch requests back to the server by pre-fetching and pre-populating like local caches that we'll kind of inline into our page. But at the end of the day, like the application has to replay, right? It has to hydrate, it has to boot up, it has to go through all of these phases. And all of these phases kind of slow us down in terms of the startup. What it means in practice is that if somebody sends you a link on Twitter or somewhere says like, look at these awesome shoes, you should go buy them. You get the link, you click on it, and you see the shoes immediately.

And then you're like, oh, yeah, I want to buy it. I hit the add to shopping cart and nothing happens for several seconds, right? And at some point, you're just like, you know what? I don't really need the shoes. Right. And you leave. And so if we can improve a startup performance, I think it's a huge impact for companies.

And Amazon has done tons of studies on this that they basically published. And I don't know the exact numbers, but basically say for every 100 milliseconds that we can improve rendering performance and interactivity performance, it's like X million dollars worth of revenue for us. Right. So they actually know this and they spent huge amounts of time and effort, making sure that they can be as fast as possible. And so this one of the reasons actually, that Amazon actually doesn't use any framework, because all frameworks have this hydration or reasonable replayability property, right, this startup cost property, and it would make the startup performance of Amazon slow. And so they have kind of a custom, I don't know what they do, but it's not any existing framework. Right. I just wanted to comment real quick on the impulse buy of those shoes. Like your first three or four seconds, you're like, I want to buy these suckers.

But the point is taken. It's just funny to think about somebody clicking a link and just like ready to buy shoes before the thing can even download the payload. That being said around the world, different places, you know, maybe that could be eight, nine, 10, 12 seconds if things are not going well. So Google PageSpeed, right, emulates things, and you can go and navigate to many popular brands, I don't want to call anybody out. And Google PageSpeed will say 30 seconds before the page is interactive. Really? And it's like, common big brands, right? So the point is, like, you can go and look at top 50 e-commerce websites. And what you will discover is that I think the number, like, in terms of performance, like Google puts them in the red, yellow, and green bucket, top 50 websites, right? Nobody's in the green. Green is a

unicorn that doesn't exist. And I know for your simple hello world website, you can probably get green, but I'm talking about a real e-commerce website with the real needs, right? Nobody's in the green. There are very few in the yellow. I believe Amazon is in the yellow. I believe Ikea is in the yellow. And Staples, which kind of surprises me, is in the yellow. And then everybody else, red for you.

Wow. Even like Nike. Yeah. Yeah. I mean, assuming. Everyone. And so the interesting thing for me is that we have this thing in the industry where like, say your website is slow.

What we do is we kind of blame the developers. Like, oh, your developers are not very good. They messed up. Like, they should have done this, this, this. Like, it's easy to kind of blame the developer for this thing. But it turns out the developer has actually very little choice about this. Or to put it differently, like, if I practice the best practices for whatever framework I'm using, right, I will end up in a place that is less than ideal, right? Like, you don't get performant website out of the box by just following the best practices, right?

It's usually like some crazy hacks that you have to do and spend time on afterwards in order to get there. So I'd love to dig in a little bit, actually, on the virtual machine analogy. Yeah. Because I think it's quite interesting to think about, and I don't know the numbers on this, but when you send a virtual machine with state, it's booted up, I would assume, and correct me if you know better on this, but you have to send much more data across because you're sending application state and all of these different things as compared to simply booting from a boot file

or something like that. And I know in the sort of web world, was it Cloudflare? Someone was looking at doing web workers and trying to make them boot faster so that if you were running JavaScript, you wouldn't have to boot up the whole JavaScript process. And they compiled it down to an image in WebAssembly, and it was much, much faster to boot. But they're doing that on the machine where sending bytes over

the wire is not a problem. So I'm kind of curious, first of all, like, do you happen to know what is the space differential in terms of how much data you need to send to kind of boot up in space? And how does that play out when we're talking about something that's going to happen over a web connection, potentially a slow one? Yeah, so that's all excellent questions. Actually, I think the short answer is you're taking the analogy too far. Fair enough. Okay.

I was wondering that as well. Yeah, yeah. So what I'm trying to get at is that we have this property we call resumability, which is that the application can resume where the server left off. And what we mean by that is that at no point should there be duplication of work. Like if server did some work, then the client shouldn't have to do that, right? Now, in a normal VM machine, like, yes, you serialize the whole memory, which is huge, right? And that's not kind of how this works.

Like, we're not sending a serialized state in here. Instead, what we do is we basically say, what we want to do is we want to serialize the state of the application as well as the state of the framework. People forget about the state of the framework because usually the framework kind of deals for it on your own, right?

But when you, let's say, using Next.js with React, and by the way, I'm not picking on any particular framework because they all kind of work the same way. So I'm, let's say, using Next.js with React, and by the way, I'm not picking out any particular framework because they all kind of work the same way. So I'm just going to use React and Next.js because it's a common thing that people understand.

So if you use Next.js and React, the Next.js will serialize your state, I think, in something called a NextData property or something like that. Yeah, it'll just dump that on the page and everything boots up from there. Yeah, it will just dump that

on the page, right? So that's the state of the app, so to speak. But what it doesn't dump on a page because React doesn up from there. Yeah, we'll just dump that on the page, right? So that's the state of the app, so to speak. But what it doesn't dump on a page, because React doesn't kind of expose it, is the state of the framework. What I mean by state of the framework is the framework needs to know where are the components, where are the listeners,

what do I do when you click on this button, and so on and so forth. There's a huge amount of state that exists inside of the React that isn't exposed to you. And you don't usually think about it, but it's there. And what Qlik does is basically says, not only am I going to serialize the app state, which others already do, right?

I'm also going to serialize the internal state of the framework itself, which others don't do, right? So that's one thing that we do differently. The second thing, and by the way, the amount of data isn't that big. Like the amount of state information is not that big, right? The second thing we and by the way, the amount of data isn't that big. Like the amount of state information is not that big, right? The second thing we do

is we now have to also serialize things like where are the component boundaries? And we can serialize that directly into the HTML by adding special tags. And we also need to serialize where are the listeners in a DOM tree. And we can do that as well by adding special attribute tags

into the HTML. So between HTML and your JSON payload that represents the state of the system, we can basically serialize everything we need to make this thing run. Now, of course, next question is like, well, where's the code? So that's the next big problem.

And existing frameworks have this particular problem, which I call, you know, single entry point problem. What it means that that existing framework has a single main method, so to speak, right, where the application boots up. And this main method is the only way to get into the application system. And therefore, this is the only way to get the system up and running. And so there's the only way to create chunks, bundles, and so on, so forth. When you have something that's resumable, like quick, let's say you just have a page with two buttons.

If I click on button A, then I'm entering the system through a different path, different chunk, different code that I have to download, than when I click on a button B. And so Quick not only has to figure out how to serialize all the state, it has a second problem, which is that

it needs to take your source code and break it down into lots and lots of small that it needs to take your source code and break it down into lots and lots of small JavaScript files. Or the other way to think about it is it has to break it up into lots of entry points, right? Every single interaction that you can do with a page is a potential entry point that reenters the system in a different way. An existing framework have this problem that like, well, they end up with a single chunk. And therefore, you have to download the whole thing at once. And not only is it a whole thing at once, you can't really resume it because you have to kind of execute the main method in order to kind of build up the internal things. What the quick

needs to do is needs to take this the source code and break it up into lots and lots and lots of small ones, create lots of entry points. And then every component, every listener, every effect, and so on and so forth becomes a separate entry point in a system. And then when I click button A, I only download the button's A behavior. And when I click on button B,

I only download button B's behavior. So the end result here is that we are actually downloading a lot less code than an equivalent regular application. And specifically, if you look at a typical app, lots of components are what I would call static.

In other words, they're just kind of for the layout purposes. They don't actually do anything, right? And Quick can basically look at all this stuff and say, this is all static stuff. It's already server-side rendered.

I will never, ever need to re-render this on a client. And therefore, this code never gets shipped to the client. So you end up with actually a lot less JavaScript than you would on an equivalent framework application. So this is reminding me actually a lot about Svelte, which I think in some ways is different than React, Vue, Angular. They take because of their pre-compile and i am not

a salt expert but i have played around with it a little bit and i think they they do some amount of the same types of optimizations where because they're pre-compiling they can have multiple entry points if there's no dynamism you don't get any javascript for a component and they don't have this sort of virtual dom thing which creates that need for the centralized main loop that you have in like a view or a react. But I think they still do have a hydration problem. Yeah. So I'm kind of curious, are those problems deeply connected for you? They are. They are absolutely connected. Actually, I'm also not an expert at Svelte, but my understanding is that they only have one entry point. I don't think they can create separate ones. The thing that Svelte does

really well is they can prune the tree, right? Because they don't have VDOM, they can prune the tree and say like, oh, these things never change. And therefore I don't have to do updates on them. But they still have hydration because in order to recover the state, like Svelte is also reactive, which means like something changes, they know how to just update a specific part on the page, which is all great. But in order to rebuild the information specific part on the page, which is all great. But in order to rebuild the information about where the components are, where the reactivity are, like if I change this data, I have to change this component and so on and so forth. In order to rebuild all this information, they have to execute the application at least once at the very beginning.

The theme for all of these frameworks is that in order to recover the internal state of the framework, they have to execute the application. In the process of executing of these frameworks is that in order to recover the internal state of the framework, they have to execute the application. In the process of executing of the application is what rebuilds the internal state of the framework. And you're correct that different frameworks are, you can say, have different efficiency factors in terms of how good they are at rebuilding. But I think QUIC is in a category of its own because it just serializes everything

and you don't have to download anything in order to make a page interactive, right? So imagine anything you can build in like Svelte, you can build in React and vice versa, right? There's like, we all agree that all these frameworks are kind of universally the same thing, kind of apps that they allow you to build. And the same is true also for Quick,

like whatever you can build in Svelte, React, Vue, Angular, and so on, you can also build in Quick. So the kinds of applications you build are absolutely identical. What's different is how the application resumes on the client and all kinds of other implications we can get into it in this show. But the reasonability is kind of the key difference. So I'm thinking about the statement that you said

about the server-side rendering about the server-side rendering and the client-side rendering. With Quick, there's never any duplication. There's never any work that's done twice. And I'm curious, is Quick aware of the server? Is the server aware of Quick? How does a server know the state of the page in order to not re-render things

that have already been updated since it rendered last? Is there a server-side? Is it full stack? Or I don't understand how it works. Yeah, yeah. That's an excellent question. So the big difference is that, as I said, existing frameworks, really, they only care about client-side rendering. And the reason why Quick can do all these things is that Quick doesn't just care about client-side rendering. It also cares about server-side rendering. It also cares about serialization of the data, sending the data across, deserialization, bundling, breaking the application into chunks, and so on and so forth.

So in that sense, QUIC is a full stack. Like it cares about the whole thing because that's the only way QUIC can deliver all of these things. Also, we also care about prefetching of the code as well. So basically all of the concerns that you as a developer need to worry about in terms of like what makes an application performant are directly the responsibility or the thing that the framework cares about and has an opinion about and lays everything out for

you. And so that's kind of the biggest difference between it is because we own the whole thing end to end, we can do certain things that others cannot. Like, let me give you an example. In order to break up the application into pieces, let's take a simple example of let's say you have a component that's a counter, there's a button, you click on a button and it increments, right? We need to be able to take this listener for the button and be able to lazy load it. Now, in this particular example, of course, when you click on a button, you're also going to have to re-render the component.

And so they always come together. But let's say it's a more complicated example that sometimes you don't have to re-render it. So the problem is that you'll do something like a button on click equals state plus plus or something along those lines, right? You cannot take that function, the closure that increments the counter and lazy load it because it closes over the state, right? So if you pull out the function and make it lazy loadable by itself, the function will not work because it will say, well, what's the current count? Like I'm incrementing something, but what

is it? How do I get it? Right. And if you just lazy load code, I say that the code has amnesia, right? It doesn't have the information that you need. So as developers, we know how to serialize code. That's just JavaScript. We know how to serialize data. Well, that's just JSON. But what we don't really know is how to serialize closures, right? Closure is function plus data. And so the thing that QUIC can do is it can serialize closures. So it can take the closure that represents your button that's, you know, add one to the count. And we know how to extract that on the top level and serialize the associated data with it and then make that whole thing lazy loadable. But the only way to do that is if the bundler

and the runtime cooperate, right? But existing frameworks, they're like, bundling is not my problem. And therefore, a bundler can't do anything that would change the semantics of the code. And so the bundlers are very limited in what they can do, because doing something crazy would make the application be broken, right? Whereas the frameworks are like, well, bundling is not a problem. And so the amount of things you can do are very minimal. We are because we own the whole thing. We can do magical things where we can be

like, oh, it's a closure that closes a bunch of variables, let me extract it to a top level function. I understand which variables you closed over. I know how to serialize them. I know how to recover them. I'm going to make a special kind of function for you that of course won't run by itself, but the framework expects this and the framework knows how to put everything back together

in such a way to kind of recover everything, right? And so this is where the magic is. So you are transforming the code. You're applying custom compilations in order to make it resumable. That's right. Interesting. So you've read code. Quick DX, developer experience, right, is extremely similar to React.

So if you know React, you know Quick. And this is intentional, right? This is not like we thought about this and we're like, this is the way to do it. So we intentionally designed the DX to be like React. So you write your functions, your components, and so on and so forth. Now, QUIC has a special thing where we add dollar signs to the API. So it's not useEffect. We actually understand server and client, so we added an extra word in there.

It's useClientEffect dollar sign. And a dollar sign communicates two things. It both communicates to the developer and also to what we call the optimizer, the thing that can rearrange the source code. So the optimizer, it basically says, pull this out as a lazy loadable thing. And to the developer, it basically says, special rules apply here. Like you can't just do anything here. Like you can do a lot of things, but special rules apply. Basically, the special rules are that you have to understand is one, this thing is going to be

behind a lazy loaded boundary, which means it's a promise. It's not a direct thing. And two is we can serialize lots of things, but not everything. You have to be careful about what kind of things are serializable.

But the framework will eagerly tell you that you're trying to capture something that's not serializable so that we have a good developer experience. But for the most part, you'd be surprised how we basically figured out how to serialize just about anything. So obviously, the basic things like objects, primitives are easy. But we know how to serialize closures, which is kind of mind-blowing, but like, yes, we know how to serialize that. So that already gives you a lot of things. And we recently figured out how to serialize promises, which is even more mind-blowing, right? And so certain things we cannot serialize, like, I don't know, if you create a set interval and then, you know, you get a number

back and it's a number like that has no meaning outside of the server then, you know, you get a number back and it's a number like that has no meaning outside of the server or, you know, the place where you got it. So there are constraints you have to understand and work with. But for the most part, you can just like write your application the way you want.

We know how to break it up into pieces. And that's extremely difficult, by the way. Like that's one of the blackest magic we have with Quick. I mean, I'm happy to go into the details. It's not like a secret or anything, right? But it is this thing that was super hard to figure out. And now because we have that, we get the resumability property, right? So that on the client, let's say you have the counter example.

On a client, let's say you click the button that says, you know, add one. And let's say this button randomly decided whether or not to increment the value or not, right? So when you click on the button, the system has to download the closure that represents the incrementer. There's no choice about that. So you have to download that. And then let's say that button decides that it's not going to increment things because it's random, then the system is done. There's nothing more to download. But if the button randomly decides, actually, I am going to increment the value, then now the system has to be reactive and say, oh, you modified this thing.

Which component is invalidated because of the action you have done, right? And most frameworks are like, oh, I give up, just re-render everything. And then there's like ways to kind of prune the tree. Right. But when you say give up and render everything, you just mean like, oh, download the whole application.

So that's not a thing for us. Reactive frameworks are like, oh, I know you modified this, therefore I have to modify this component. And so they have an advantage, except in order for them to rebuild the reactivity graph, they have to run the application once at the very beginning. So that's useless, right? So the thing that Quick understands is what is the reactivity graph? But this reactivity graph is actually serialized into the HTML so that when you go and modify the count value, Quick can say, aha, I know exactly which component I need to download and update. And so it can be extremely surgical about it, right?

Now imagine a page where you have add to shopping cart, right? You have your prototypical shoe. You say add to the shopping cart, right? Now imagine a page where you have add to shopping cart, right? You have your prototypical shoe, you say add to the shopping cart, right? So when you hit that button, the code behind it will go probably and update some shopping cart data object, which then means that I have to re-render the shopping cart, right? So you have to download the code for clicking on the button for add to the shopping cart. And you have to download the code for the rendering of the shopping cart. But notice what you didn't download. First of all, you didn't download anything else on the page, but you didn't even download the component associated

that originally rendered the button for adding to the shopping cart. Because like, you didn't change that part. You didn't re-run anything over there. So why should we even download this, right? So the one way to think about it is one of the things about it is one of the things that quick is trying to do is to say, look, if you're going to go through the trouble

of downloading some JavaScript, then you better execute the whole thing, right? Like we don't want to be in a situation where like we download JavaScript, and then don't execute it. Like so if you look at code coverage, for a quick application, you should be pretty close to 100. Right? Because we're only downloading and executing stuff that we actually need to do, right? And so the magical bit is like, how do you take an application that is written in a standard React-like way and break it up into lots and lots of entry points, create ideal bundle sizes, and do all of this magic that needs to happen. And then basically push all of this thing to the browser in a way where the developer doesn't have to think about any of

this stuff. So I want to dig into one particular thing there. And that's how are you thinking about how state moves through these different components? Because I was thinking about your example where you have a button somewhere on a page, and you have a shopping cart somewhere else on the page, and you change some state based on the button and it only impacts the shopping cart yeah in many component-based applications that state may live in like a prop or something that is propagated through a number of parents to get down into whatever the actual component that's depending on it is yeah our current implementation is inspired by MobX, or kind of what I believe what Svelte does as well. So we have stores and stores have properties,

and you pass stores around. And then when you read from the store, that's how we know that a subscription has happened. And when you write into a store, that's how we know that you modified something. That's one way to do it. We're also actually thinking hard about what SolidJS does. They have signals. And that is another interesting thing that we would like to explore. We're kind of exploring it. We're liking it. We'll see where the thing actually lands.

But yeah, the idea is that you pass stores rather than props so that you don't do much prop drilling. You can also have context, et cetera. But yeah, if you do the classical prop drilling then you have the problem that you'll force re-rendering all throughout the system and you don't want to do that right yeah that makes sense view also has a store-based system a lot of the time so yeah it's yeah what i'm kind of getting at is that like your developer experience for building in the application is very much unchanged and it's probably closest to React, but like maybe some things like stores

from Vue or Svelte, et cetera. But fundamentally, the DX is something you're very, very familiar with, right? But that's not what we're selling here. We're not selling you a better DX. We're selling you a better experience for your end user because we are smarter in a way we bundle, execute,

and deliver the information to the client. So what's the practical difference then? So like what you're offering with Quick, let's say the DX is relatively the same as you using React, you know, put some dollar signs at the end of things. There's a few more rules or different rules. What's the practical difference? Is it an order of magnitude in a complicated application? Like we're talking about your app's going to be 10x faster, 100x. Like what happens when I use Quick instead of React? Yeah. So we have our homepage, Builder.io homepage, and we actually have that homepage. Originally it was a Next.js React homepage, and we just switched it over to Quick. And actually we have the ability to run both pages simultaneously. So

if you go to Builder.io question mark, render equals next, you get the Next.js one. If you just do without anything, you get the Quick one. If you open up in Chrome, sorry, if you open up in Google PageSpeed, we get, I think, around 40, our score is, in Google PageSpeed and Next.js, and about 95 in Quick. Now, I'm not picking up on Next.js.

Like, we could have done this in any other framework. I think the numbers will be about the same because they all fundamentally have hydration that's happening. And what we're really paying for is the hydration here, right? Okay. So no matter which framework you kind of choose out of that category, I think you'll see similar numbers. If you go to Chrome and if you open up DevTools

and you can go to the performance and the performance you record the startup thing, what you'll see is that builder IO page on a desktop computer spends, I believe, something around 80 milliseconds executing JavaScript at startup. And that includes quick and party town and third-party scripts and everything, right? And in the Next.js version,

it takes, I believe, 800 milliseconds. So we're talking 10x improvement in the amount of JavaScript that the browser has to execute on startup. But I think the improvement is even greater because when you have a regular framework, like let's go to the example of somebody sends you a link, the shoe, and there's a buy button you want to click. When you do the normal frameworks, right, you render everything, there's a button, and you click on the button, and nothing's happened because you clicked on it too early, right? And so you have to wait until hydration is finished before you can click on a button. And that can take time. And you know,

on a mobile device, it can take literally 10s of seconds. The nice property of quick is that the moment quick HTML loads, the HTML contains all of the information about where the listeners are. And it also includes little tiny, what we call a polyfill, which is a piece of JavaScript that sets up a global listener for everything at the root, which is super tiny. It's about one kilobyte.

It executes in like under 10 milliseconds. It costs nothing, basically. And this polyfill is ready to listen for things immediately. So as soon as the HTML shows up with a button, inline inside of the HTML is a script tag that's already executed, is already listening for click buttons. So when you go and click, that click goes directly and gets immediately processed.

And now, of course, you have to fetch the JavaScript. But instead of fetching this huge thing, which is the whole application, you're fetching just the code necessary for that button, right? You cannot get any more efficient. Like we have removed everything that is strictly not needed. And we ended up with the absolute bare essential. Like there's nothing else left to remove. The other thing we do is we also know statistically,

and also we can kind of guess through heuristics, as to what are the possible things that you as a developer can do. And so even before you click on a button, we already instruct the browser with a prefetch links to say, like, this is most likely what's going to happen. So go and start prefetching this JavaScript. We don't execute the JavaScript. We're just prefetching it. But the nice property is that if we guess wrong

and you click on a button, your request goes in front of the prefetch requests, right? So you immediately even pull yourself up. So all of this basically means is that you are essentially ready to interact with the page immediately. It's hard to imagine a scenario where the interaction would be even better. Like, I don't know what else could be removed

out of this particular thing, this equation, right? Just a blank page, you know, just white, it's nothing. Exactly. Hey friends, this episode is brought to you by my friends and potentially your friends too at Fire Hydrant. And I'm here with Robert Ross, founder and CEO of Fire Hydrant. And Robert, there are several options out there for incident management, but what is it that makes FireHydrant different? The reason that we think that FireHydrant is on to something is because we're meeting companies really where they are. We face the same problems that every company in the industry that is building and releasing software is also facing.

So we want people to be able to sign up for Fire Hydrant and immediately be able to kick off an incident using the best practices that we've built and we've experienced and have gathered through the other amazing customers that use our tool. It really is a very quick time to value. And we want people to have a long jump from where they are to where they want to be in incident management. I love it. Thank you, Robert. Small teams up to 10 people can get started for free with all Fire Hydrant features included. There's no credit card required to sign up. They are making it too easy to get started.

So check them out at firehydrant.com. Again, firehydrant.com. And by our friends at Retool. Retool helps teams focus on product development and customer value, not building and maintaining internal tools. It's a low-code platform built specifically for developers. No more UI libraries, no more hacking together data sources, and no more worrying about access controls.

Start shipping internal apps that move your business forward in minutes with basically zero uptime, reliability, or maintenance burden on your team. Some of the best teams out there trust Retool, Brex, Coinbase, Plaid, DoorDash, LegalGenius, Amazon, Allbirds, Peloton, and so many more. The developers at these teams trust Retool as their platform to build their internal tools, and that means you can too. It's free to try, so head to retool.com slash changelog. Again, retool.com slash changelog. so astro is is you know kind of just came out with this 1.0 but it's really not new i mean it's new

yes but not really is i feel like you know i've been hearing about astro for a while i've been seeing you all push stuff and it's been this slow kind of reveal so can you kind of give us some timelines and give us some insights into kind of like, how long have you been working on this project and what motivated it? Yeah, it's like every overnight success, there's years in the making this. Yeah, yeah. This really traces back to even that Pika story. But Astro itself, I think is about if you go back to the first commit, like a year and a half old. So we've really been working on this for a while trying to get it right before we stamp it with that V1. The best way to explain it is essentially a content-focused or content-driven web framework. So if you're thinking of how you want to build your website and you're looking at like Next.js,

SvelteKit, or Nuxt, or maybe you're looking at like a static Jamstack builder like Eleventy or Hugo, we're trying to be the best choice for anyone who's building a content site. So marketing sites, portfolios, blogs, personal sites. If the focus of what you're building is content, getting content to someone who's trying to read or consume that content, that's what we're trying to be the best at. And we have a lot of really cool features that are kind of designed explicitly for that use case, where we see other frameworks optimizing more for apps and dashboards and really complex use cases, which are all well and good. But we see a real opportunity here to build a framework for people who build content sites.

Yeah. And so that's what Astro is. Yeah, no, that makes a ton of sense, Fred. I feel like for me, that's like a really refreshing kind of, I think, motivator and perspective, because to some degree, like even things like AMP were really created, right, to focus on. All right, well, you know, we have all these kind of static sites that need to get to users faster.

What do we do? Oh, I know. Let's just limit all the JavaScript, right? And also come up with our own cryptic set of rules. And, oh, I don't know, like use private servers to prioritize caching and blah, blah, blah. And maybe a few years down the line, make a lot of publishers and whoever angry right so you know for better or worse we're gonna make the web faster by making it only what we let you do in this little sandbox and therefore the web is fast now and good and yeah that's pretty antithetical to yeah a lot of things about the web right but again i appreciate

for me right i appreciate the experiment i appreciate the innovation i appreciate the intent right so now like how do we the innovation i appreciate the intent right so now like how do we kind of further evolve from that right and feels like astro is kind of taking a step in that direction i think for me like this focus on content and content like websites that are like you know that's your niche i'd say like okay great job picking a niche because that's really the majority of the internet right yeah it Yeah. As far as niches go, you can't really get much bigger. I think the last number that I saw is like around 60% of the internet is like, or the top 500 sites are that type of content focused site. So yeah, as far as niches go, it's a big one. Yeah, I totally agree. And like, where would you say

places like Reddit fall into that spectrum? Because I feel like Reddit is like so heavy on content. It's like read, read, read for the most part. And then there's some interactivity there as well from users. But that's like user generated content, I feel like. Yeah. So where does that kind of fall in that spectrum for you? I think you use the right word, which is spectrum. It's definitely different sites and even different pages within a site can kind of

take different forms. So yeah, Reddit, like the creation of content is much more interactive than just reading the content. And then once you get into the comments, there's a lot of little interactive bits. So we like that content focus because it really kind of is our North Star. But there's really cool features that kind of back that up. So the big one is thinking about how you architecture your site.

The biggest difference that Astro has from others is that we really like this idea of generating your page. It's all static HTML, and then you're hydrating like the interactive bits around the page. So for some things, if everything is connected data, like you post something here, it updates the dashboard there, like this doesn't work for every use case. But for content, when the majority of the site is actually the static thing that you're consuming, it really works well to kind of color in almost within the lines, like a paint by numbers. Well, here's the kind of interactive comment here. Here's the button here. Here's the navigation there. The benefit of that is that you're actually only hydrating individual parts of the site. And the performance benefit there is

that you're not sending down this entire JavaScript app to your users. You're sending down these little snippets. So that's the biggest difference. Reddit works really well. Hacker News is kind of this demo that people like to benchmark Astro against. Yeah, get the Next.js Hacker News versus the SvelteKit Hacker News versus the Astro. And the interesting thing about Astro is, unlike all those other ones, we don't have to send a JavaScript app

to render that page and make it interactive. We're just making sure the comment button is interactive, the navigation's interactive. It's much more selective and therefore much more fast. We're just sending way less JavaScript down to your users at the end of the day. Yeah. Again, that's another really refreshing take. And I think another way that I think Astro and the folks involved with the project as a whole have really helped push the community's thinking on this.

And we'll get into some really cool stuff in a second, like islands. And no, not islands in the sun, which is what I always think of. I'm like, islands in this, you know, no, different kinds of islands. But I think what's interesting for me is that thinking about architecture that way means that you're also always planning for that fast by default experience, right? And you're being very intentional about what you want to be expensive. And like versus kind of this opposite world that we've been living in for however many years or you know where it's like

we're just by default like everything is chunky and heavy and we ship it and then we start subtracting from there after the fact it's kind of painful like no wonder teams have so much difficulty like making their apps performant like we're speaking English when we need to be speaking Italian or something like that. Right. It's like, what are we even doing? So it kind of like, are we using the right tools? Are we using the right methodology? Are we using the right architecture?

Like I would say no, no, no. Right. And so I think it's like, yeah, I mean, I have said this before on the show. I'll say it again. Might make some people upset, right? But for me in 2022, like love tools like React, but they come with their own set of problems and whatnot. But generally, like if I wasn't designing

for a multi-platform use case where I needed this to run in a native application or in a VR headset or whatever, like if I just needed this to be on the web, I would not be using a tool like React to like create a simple website. I just wouldn't. It's just too chunky.

It's not, it's just, there's too much overhead. It's got too many pieces of luggage, you know? So I'll take the other side of that. And I, you need to stop me because I will talk about that. I find the history of like how we got to where we are fascinating, but I actually don't. And I think I'm in the minority of like the web perf like

diehards here but i don't know if i find react the problem as much as i find the everything is react kind of thinking and that then applies like everything is felt everything is view where if you imagine like even like a simple hello world next js site and i'm not picking next this is like the model that they use that everyone else is using. You're not just sending down the like, hello world. There's nothing really interactive, but you're sending on JavaScript to power it. And this history goes all the way back to like create React app. And Jamstack really kind of pushed this because there were a lot of benefits to it. But the thinking that your whole site is a JavaScript app, it's rendering on the client.

You're only thinking in one code base. You have this really nice separation of concerns. Your backend's an API. Your UI is all one code base you have this really nice separation of concerns your back ends and api your ui is all one code base like there's really nice organizational things that people love from the developer's perspective right isn't that dx though that's like the dx is yeah yeah the dx is incredible it's unbeatable versus like you know like php i worked on sites where you're rendering html with php and then you're also rendering it again with react it's like you're trying to keep two code bases and i've seen some bad stuff yeah but it's that idea of like the dx was so good but then we just took that path and 10 years later we found ourselves

where we keep adding complexity and adding more code to solve a problem that is inherently too much code that's our take on it that it's not the reacts problem it's that we've way over indexed on how much is powered by react or view or svelte at the end of the day more the more code you're asking the user to run you're just fighting physics at that point that's code that has to run on your user's device it's going to slow it down yeah no i mean that makes a ton of sense and again it just take goes back to like the intentionality of what we're doing and how often like we're all working under such constraints and such like you know cow paths that also the community has paved. Right. There's best practices. There's tools like CRA that like, you know,

create racked up that make things so easy. It just one button. Right. Like if we're not careful about the complexities that we're abstracting, right. Like if we're abstracting away things like that are okay, generally best practices and good decisions like great but like the risk of mass adoption and abstracting away some of those things like is you're making bad decisions that you didn't even make you know you're just the tool made it for you right yeah the way we phrase it is like create react app and a lot of others they'll if you ever look in your node modules when you install something with create react there's i

think like 2 000 packages yeah 2 000 dependencies all sitting on top of each other and we call it like it's complexity but kind of wrapped and like hidden from you but then when you want to go and do something new it's either the tool says no you can't do that like there's too much here you're gonna mess it up or like okay but be careful if anything breaks good luck finding which one of the 2 000 dependencies is causing that problem right so it's like we've hidden complexity for so long what i love about this kind of new wave of tools like astro is what if we just actually removed a lot of that complexity what if we drop down what you have to think about when you build and instead gave you something that starts from first principles web standards html right i think that's a much better place than

just continuing to wrap the complexity in more and more layers of abstraction. Yeah, that makes a ton of sense. And put the onus on the developer to intentionally make the decisions about where they want to take the app in terms of which sections am I bulking up and being very intentional about those decisions. Also, everyone, when they have the time to think about it, typically like comes to the right conclusions. But it's just actually like, have we even thought about what we're doing really, right?

Most of us are just like on autopilot. And in all fairness to Create React App, I don't think anybody could have predicted the way it was going to take off. Like clearly there was a need in the community for all of like, kind of like having more boilerplate templates that could serve and manage away all of the JavaScript tooling complexity, right? Because there is some fatigue there from the community. And like, that's

something that we can't like not talk about, right? Because like, that is a real thing, real problem, right? And React was also the first application, we've talked about this on the show before, that went to NPN land and said, okay, JavaScript front-end developers, we're going to go hijack the Node community now because we need Node tooling to build JavaScript apps now. And, you know, that was a shift that happened. And then we ended up with a bunch of Node tools

that needed to build your front-end app, right? And then Node changed and all the tools have to, yeah. We really like this term all in one. And I think it's a larger trend. I think Deno kind of falls into this. Like Bun, if you've seen that. I think people are starting to feel more comfortable presenting something as a full, complete platform. And not a collection of 2,000 different packages all hopefully working together.

Because it's hard to maintain. So we like this idea of Astro being a really stable runtime almost a platform or foundation whatever you want to call it that is much more like build on top of this and we got you fred that was really insightful and super interesting kind of digging into some of the context and history behind some of the motivations of astro and like just kind of y'all make some pretty bold promises here. I kind of will list through some of those, right? So Astro is content focused, server first, fast by default, easy to use and fully featured, but flexible, right? And I think that's interesting. That's a tough, fully featured, but flexible. I mean, that's how do you make it easy

for newbies to get started and make good decisions without having to really think about it? And then how do you not hold back power users, right? Like that's like the always the struggle with API design. So let's get into some of this. So we've talked a lot about the content focus piece. Can we talk about the server first piece? Because there's quite a bit here with just being server first. For me, it's like, I kind of read that, like, y'all are promising that this renders in the server. So you don't have to ever worry about any state management or whatever else unless you want to. But I'm just curious, like, what does that even mean? Can you explain that to folks? Yeah, no, definitely. So it really ties back to what we were just talking about, because what we see is we're flipping the model a bit where if the last 10 years have been all about, like, let's build a big JavaScript app that runs on the client and the server. We're saying let's go back to when a lot of the work happened on the server because there's really nice performance implications there. So this is a kind of message that a lot of other frameworks are starting to try to tell, but we have this really unique

opportunity to just tell it from a fully fundamental, what we do best is generate HTML and then make it interactive versus what we do best being like a JavaScript application. So the way that we see it is that we are very server first. The template language that kind of comes built into Astro is essentially sugar on top of creating HTML templates. It's a nice way to work with HTML. And then we pair that with a way to bring different components in only when you need them. So if you like React or you like Vue or Svelte,

you can actually use those components to build your UI. But again, by default, we're just going to render them out server rendered to HTML and zero JavaScript being sent down the wire unless you kind of like opt into it you say like no this component should be interactive give me the javascript i'll pay the cost for the user's performance but i'll get this really nice interactive component versus every other framework is default i'll send it all though they might need all of it so just send it all i see we've flipped that model that makes sense so how do you all

handle this uncanny valley that we get with server-side rendering where it's like, well, it looks great because it's like, oh, this came fast and it looks interactable. Then I try to click it right away and like, oh, nothing's happening. Oh, JavaScript's still parsing and loading, right?

Some of that can be managed by reducing the amount of JavaScript that you send, but you're still just gaming the system, right? It's never going to be zero seconds or zero milliseconds to process that JavaScript chunk. So like, how are you dealing with that if at all? Like, are we just kind of leveraging the fact that like, because the users have to be intentional and opt-in,

it's usually a lot less JavaScript, like, and then there's also no framework JavaScript that's being sent along with this, right? I'm just curious, like, how are you all managing that? Uncanny Valley. That's the problem that Astro, like, exists to solve for, which the Uncanny Valley is a result of the fact that, okay, we're going to server-side render your JavaScript application in one of these other frameworks, and then we're going to send the whole page down as a full application, and nothing's going to be interacted until all of it

is. That's really a uniquely SPA kind of problem. That's really uniquely kind of that model problem that we just don't have. You still do need to make sure that your components can handle what happens if they fall back to good behaviors. But the nice thing about when we can kind of hydrate in different components, we're doing that in isolation in parallel. So where large JavaScript applications suffer from the problem of everything has to load before anything can be interactive. There's this really nice model where we can actually treat

every component on the page differently. So for example, if it's not visible, we're not going to run it like until the user scrolls down to it, that's when we'll hydrate it. That's a really cool, like uniquely Astro feature, because we're treating that component isolated from everything else on the page. And the other being like, if something's really a high priority, you can bump up how quickly it loads and you can also load that without worrying that something really big and heavy is going to block it.

So your big, heavy image carousel lower on the page, that's not going to block the buy button that's somewhere in the middle of the page from becoming interactive and loading. So it's a much more decoupled and by result, things that are like really essential can load much faster because we let you kind of control what loads when

and how high priority it is. Yeah, no, that makes sense. And so there is this like waterfall that you get with like unbundled ECMA modules, right? Like you have a bunch of different JavaScript chunks, like true loading in parallel like is that even achievable really in the browser these days like i don't know yeah i mean that's that kind of gets into something else you mentioned which is the fast by default

just because these things can load in parallel doesn't mean we've like blown away all the performance optimizations of bundling and minification okay we still do do that but it's a really interesting model of instead of saying, okay, here's your whole page as a single JavaScript bundle, we're saying almost like here's each component as its own. Island is a term we like to use.

It's its own bundle. It can load in parallel. And so you actually are getting still bundled and optimized without you really having to think much about it. But it's a result of us kind of behind the scenes

still giving you the model while handling the complexity of it behind the scenes for you. That makes sense. So there is some intelligence that's under like being managed under the hood in terms of like optimizations that are still happening. Yeah. It's a big thing of trying to keep that away from the user having to, it's the trick of how do you talk about your framework when every framework claims to be fast.

Right. But what we like to say is it's fast by default, which I don't think any other framework can really claim. What we mean by that is like, it should be hard to build a slow site with Astro because for content sites, performance is so key. It's key to conversions and Google SEO. They're going to rank faster sites over slower sites. Right.

In a lot of other frameworks, you're kind of like, okay, well, we built a slow site. What do we do? Okay, well, we can optimize. Let's bring in a performance expert. Let's spend a sprint on just performance and maybe you can make some progress but we want to come from a principle of like it should be really difficult you should be like having to try to make astro slow for it to be slow yeah otherwise we'd like just keeping you out of that

pit is really a main goal of the project yeah yeah yeah yeah no that makes sense that's really great to hear and i would say that like i. That's really great to hear. And I would say that, like, I think that's an interesting nuance that I didn't even pick up on reading your docs, like fast by default. Yes, you're right. It is the by default part that I think you maybe you need to like bold that or something, confetti around it or something. Yeah, you have to try you got to break Ast to break our performance story. That's our goal. That's cool. Good marketing. And so another kind of pitch on the Astro site is easy to use. And I noticed that there is a.astro UI language that's kind of part of this framework. So can you

kind of tell me a little bit about that? And easy to use is a tough claim because that's always relative. But like, how easy is it? Like, is it as easy as JSX, right? Where it's like, it looks like HTML sort of, but still comes with its, I would say, dragons, right? So what's easy here? I will call out that what you're reading is kind of like our aspirations.

Like we want Astro to be easy to use and we make design decisions for that goal over maybe something else like a really complex feature that's really hard to use. But like we'll avoid that even if maybe there's some reason to do it other than it's something that we really value is we want to always be easy to use when we design Astro as a language, as a framework, as a platform, all these things. So I agree. I want to like, why is this? Oh, it's easy to use when we design Astro as a language, as a framework, as a platform, all these things. So I agree. I want to like, why use this? Oh, it's easy to use. Like I'm always like, again, everyone says that, but it's our aspiration. We really value that over other things that other frameworks might value over ease of use. Okay. That makes sense. And so can you give me an example of like an easy to use API in the library, like something that's uniquely easy to use in Astro than some other something that's uniquely easy to use in Astro than some other framework that whoever might be using.

Yeah, so you mentioned the.astro file, which I think is a really good example of how we're kind of trying to give, like there's like two different paths you can go down and you can mix them as you want. So if you love React, you love Svelte, you love Vue, bring those into your project. They're going to work just like anything else

to generate your UI. So there's this idea of kind of bringing something you know to feel comfortable pretty much from day one using Astro. Even if you're migrating to a site, like bring that site as long as there weren't like framework specific bits. If it's just a React component that's like super agnostic, fantastic. It'll probably work in Astro, assuming you kind of meet that, you know, you didn't bring in anything that was framework specific from the old world. The other side of that is.astro is us building a templating language that's really just HTML. So one of these things about using React or Svelte or Vue is you're having to learn a framework that was built for the client side. So it's dealing with

reactivity and hooks and, you know, these like atoms that are responding to state changes. Like that was, those are all frameworks that were designed first for the client, which has a much more complex interaction story, and then have kind of been backported to the server. Because we're so server-first in our thinking, Astro is just a template language for the server. There's no reactivity to worry about. There's no hooks.

Everything's going to run once and render. And that gives us essentially something that's just HTML. We call it HTML with some like nice to have features like a JSX expression. If you want to do some sort of templating, you can use components in it. So it feels a lot like a Svelte or React, but we've stripped away all the bits that aren't really relevant on the server. So you have your kind of framework that you love. And then also we try and give you this baseline that's just HTML with a couple of little things you can opt into if you want them. That's so cool. And yeah, you know, honestly, I didn't even really put those things together in my head. Really like when you optimize for

server first, then when you're optimizing for HTML, you also by default, like it's just easy to use because you're not like, you know, reactivity is really where things get complicated, right? Yeah. That's like the 201, 301, 401, 501 classes. You know, HTML is like beginner friendly, but doesn't hold you back on in terms of presenting structurally complex data or sites either. Right. So that's like the beauty of HTML. It's something that's always bothered me of like, oh, this Hello World tutorial.

Well, we need to learn a bundler. You need to learn JSX. You need to learn React. You need to learn a state management system, a router. Like, oh, there's like a lot to learn in web development today. And it's all about rendering HTML at the end of the day. So could we build a kind of getting started flow that is just like valid HTML works as a template, as a component in our syntax. So if you just want to copy an HTML from anywhere, put it in an Astro site, that's a site.

If you've just built a site with Astro, that's our hello world. Yeah, yeah, I know that that makes sense. And Billy featured, but flexible is the other thing, right? So you hinted a little bit about like bring your own sites, bring your own. You can kind of BYOF, which is a thing that you all have coined, bring your own framework. Very cool. What does that even mean? Like there's over a hundred astro integrations to choose from, what are astro integrations? It sounds like a physics seminar of some kind, but I could be wrong. Yeah. You got to put on your lab coat, put on your goggles, jump into your config files.

Current astral projection for this equation is, you know. Oh no. You know, it's okay. Listen, this is why I don't like writing. It's hard to write. Astro integrations, I'm sure, make sense in the context of web development. So, and in the context of astro.

So why don't you tell us about what that is? So. Yeah, no, I'm just laughing because I'm never going to be able to get that image out of my mind for the rest of my life. I'm sorry. Astro integrations. Yeah. Okay. It's hilarious. Yeah. It's our plugin ecosystem. We really like this idea of our core providing all the things you need. So when you install Astro, you have the basic building blocks of a site, but then, you but then this idea of bringing your own framework, it's a pretty lofty, big scope kind of goal. We couldn't build everything into core without it just becoming this maintenance nightmare.

So what we offer is this idea of everything you need to build a site is built into Astro. We're going to focus on content sites, so stuff like RSS feeds. God, what else? Rendering Markdown. feeds god what else rendering markdown there's like all these nice little like very much more coming from like a blog or like an 11d nice to haves that are essential in the uh in the content site so we build stuff like that in or make it really easy to grab off the shelf and then when you want to use something like tailwind or reactors felt we essentially have not just a kind of a plugin and integration but also even a command that you can run. So Astro add React is going to do all the work to get that set up for

you. It's going to MPM install the package. It's going to add it to your config file as you'd expect. And the idea is you run that and now you can use a React component in your project or Svelte or Vue or Tailwind or whatever it is you need. That is so cool. But I have to ask, as maintainers, what is it like trying to normalize the JavaScript community? Because it feels like that's what you're doing. You're like, we're just going to run a big normalization query on the JavaScript community. Are you hooking into the public interface or the output of these tools? Because it's too much to go any lower. But I'm just curious, how are you managing this and normalizing this experience? Yeah, that's kind of the key of why the.astro syntax exists. It gives us that base layer where you can then plug in these frameworks into it. So create your shell and then put in your React component. And if you wanted to build an SBA, if you wanted your whole page to be one React component or many React components,

you never wanted to touch Astro's syntax, that's fine too. But that's kind of the normalization layer. I think that's actually pretty much exactly the magic that we've kind of shipped. The reason that it's not too much for us to lift is that server-side rendering a React component, that's essentially what every other framework is doing for your whole site. We're just doing it shrunken down to a single component. So it's almost this full circle story where React started early days. It was like, yep, here's a component, here's a component. It was all front-end focused and then the kind of build your app

as a JavaScript app with React, that all came later. But we're just tapping into that original story, which is use React to build this component on the page. All the same APIs work. So we're basically doing the same thing that Next.js is doing or any React framework that is going to call the server rendering internally to create that HTML.

Holy web frameworks, Batman. We have made it to the end of the show. Wow. So much web frameworks talk right there. Can you believe it? Three different web frameworks recently on the front end world? No way. If you're in total disbelief, we want to hear from you in the comments. Check us out at changelog.fm slash 509.

This is episode 509. A big shout out to our friends and our partners at Fastly and Fly. And of course to Breakmaster Cylinder for those awesome banging beats. Those beats are banging and I love them. Do you love them? I think you love them. And hey, I mentioned this already but 8 plus minutes for our plus plus subscribers. A lot of plussing going on there but hey,

plus plus is plus plus. Check it out, plus plus. changelog.com slash plus plus. It's too easy. Support us directly. Make the ads disappear and get access to that bonus content. That's it. This show's done. Thank you again for tuning in. We will see you on Monday. Thank you. Game on.