A new batch of web frameworks emerge!

It’s Luca Casonato from the Deno team. Welcome, Luca.

Hey. Thanks for having me.

Thanks for being here. Fresh off your launch, and I can’t avoid a pun…

A-ha! [laughs]

You’ve launched a Fresh, new –

I’ve heard that one before.

Yeah, you’re gonna hear it a lot more.

Yeah. [laughs]

Sorry, you picked the name, nt me. I do it.

Yeah, it’s good…

I liked the lemon-based icon as well. Cool stuff. A new web framework for Deno, from Deno. It’s an official Deno project, y’all are building it and supporting it for the future…

3:Yeah. That’s the idea.

Awesome. What was the idea why? what, what was 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. We started using that for it 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 we call ourselves nowadays the web, web devs, are starting to embrace just even the term framework. We’re starting to see frameworks come out, and a long time it was like 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 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, one of the core ideas of Deno for a long time, to have this whole batteries-included runtime where we’re not just a runtime, but we also provide things 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 sort of give you a cohesive experience. And I think this actually – it’s very nice that we managed to also extend this to this web framework now, because those same ideas that we built Deno with, we also used 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.

Feross, what about your thoughts on frameworks versus libraries? I know you’ve been very much a “bring things together, but make your own decisions…” I do that ethos, of like “I’m gonna pick –” like a craftsman would pick their tools. And I know that you built a lot of websites over the years, and it seems each time we talk about the tech inside your websites, it’s always a little bit different; you pick different things. I’m curious what your thoughts are on the framework movement that’s happening currently.

[06:16] I’m a huge fan of it, actually. I am starting to lean more toward that direction. 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 that 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 these kinds of implementation details when you’re trying to just solve a problem. So I’m a huge fan of it now. It helps you focus on what you’re trying to do, just the actual problem you’re trying to solve.

I feel like very often, with a lot of people, they think they don’t it until they start using it. 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 once you’ve used it, you realize how much time this saves you, by not having to make all these decisions, but have someone else make the decisions for you.

Yeah. So I’m from the old days of the web. Pre Rails, 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 was a batteries-included framework in the Ruby world, to build your web apps. Or you could go the Sinatra route, which was this super-clean, minimal, but beautiful, basically router plus some other things. And if you used that, you would then pull in different things that you need. And I got attracted to that style when I went that way, a couple of websites. And what I found myself was piecemealing together Sinatra plus all these other components to basically be my own ad-hoc Ruby on Rails… But it was just mine; it wasn’t along with the 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 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 what 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. 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. Tried to make it fast and small, and use things which people are already familiar with, and have proven to work well.

[10:02] So no build step, no configuration unless you want to… A lot of the niceties that 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; 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. There’s upsides and downsides, certain trade-offs that you have to make. If you want to have a very great offline experience, that’s not something you can do. You need to do more on the client. But most pages are things blogs or marketing sites, or even applications, e-commerce sites, which are – they’re applications, right? 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 open your app store, search for the store that you’re trying to buy something from, download their app, and then start using that. 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 the 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, like changing the color of a input field as you type, input validation, that kind of stuff.

What are some heuristics around that decision of client-side routing, versus server-side routing? Because it really seems 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 the 80/20. I think it’s the 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 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 “Do I do 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 what you’re trying to build.

[12:34] I think that with SPAs, or client-side routing single-page apps, that model, you have the flexibility that if you do decide you need some of those features, you do want to have, I don’t know, let’s say audio playing across page loads. So you can have music, some audio player playing even when you click a link, or something that - that stuff’s just not even possible in the fully multi-page app model. So I think some people probably are picking these client-side single-page app models for their website just because of the flexibility of 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 just use React, or Preact, and have this nice sort of modern development flow, but also be able to do server-side rendering and have no client JavaScript, and I felt like it was pretty hard to get. I was either gonna have to go and build a really old-school website, or I have to take on client-side routing and client-side everything. And so what’s cool with Fresh is – I really like that you get to write your app in a modern way and get this sort of one-way data flow that Reacts 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…

[13:49] 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 server-side. There’s just too much interaction. But something like your blog - this probably does not require client-side rendering at all. It can be fully server-side rendered. And it’s really difficult to figure out at what point – like, is an e-commerce something you need to SPA, MAP?

I think it really depends, as Feross said, on exactly what you want to be doing. If there are things that you require an SPA for, then you sort of have to use an SPA. But 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 an island. Maybe you could you explain a little bit about islands, because I’ve never heard –

Yeah, yeah.

it seems like every so often there’s these new words that the JavaScript community kind of invents for new concepts… Tree shaking was one a while ago that it felt like we already had a word for it… In C compilers we call that a linker, the linking step. But we had to create a new word… So is islands something that? Could you explain what an island is for us?

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 with client interaction only some components of the page on the client.

For example, you have a blog page with a comments section. You want the comments section to be highly interactive, and client-side rendered, but you want the markdown itself of the blog to be completed server-side rendered. The idea is that that comments 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.

Jason Miller came up with the this concept of island architectures 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 – you want to live-refresh them in the browser as they’re being posted. You would make the entire comments 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 like the smallest component surrounding the interaction, I guess.

Okay. So let’s imagine the former circumstance. So we have a comments section that we want to be highly interactive. Each comment just like floats in from the side, or whatever you wanna do. 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 NPA, server-side rendered, if I had seven comments on my blog post and I hit Cmd+R to refresh, my server is gonna 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, JSON, whatever it is, that gets hydrated?

You could do either. By default, what will happen is that it will render the HTML on both the client and the server. So the Fresh homepage has this counter-example right on the homepage, that counts your server-side rendered, but the server-side render 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 a scaffold”, right?

[18:23] Yeah. Or if you want it crawled. Maybe I want my comments section crawled, so I’m gonna server-side-render it.

Yeah.

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… So it’s kind of an “it depends” all the way down. And it sounds like with the islands architecture you have the flexibility to make those decisions on a case-by-case basis.

Yeah. 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 send to the client. You could 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 you 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. Like, what’s the point there? That’s just wasting CPU cycles on your mobile device. So 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 core to what Fresh is, right? Because I had generated a scaffolded app, and there’s routes, and there’s islands. Like, these are folder names in the structures. Islands, and Routes. So you’re gonna be writing some islands, I suppose, when you’re using Fresh.

Yeah. [laughs]

Okay. Feross, is this an old concept that’s been renamed, or is this a new concept for you? Because now he’s explained what it means. I mean, for me it makes sense, but I’m not sure if it has a previous name, or if it’s actually just been invented by Jason Miller and the JS people.

It’s not ringing any bells for me. 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 something a long time ago. I don’t know what they called it. My question about islands is just like how easy is it to go between something being an island and something not being an island? 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, and say “Do this on the client” or “Do this on the server.”

Yeah. And it really is. The boolean is in – like, is it in your components folder or is it in your islands folder?

Okay.

That’s it. That’s the only difference. The files are exactly the same. It’s just a regular Preact component.

The code is just a regular Preact component.

Yeah.

Okay.

And 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 will only ship the code to the client if you’re actually using a given island. So you can have like 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 smart enough to know it’s in this folder, these are islands. And if it’s not, it’s not an island. Like, that’s your indicator.

Yeah.

So drag-and-drop, Feross. Just drag it out of that islands folder and drop it into the components, I guess…

Yeah. Interesting.

Not the best diffs…

Well, I don’t know; on GitHub it would –

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 gonna wanna have more flexibility down the line in terms of how you deal with an island… Because you might want to have certain ones where there’s not even a server-side render at all, and it’s 100% client-side… Or maybe you want some where it blocks the page. Like, this island is super-important, so you wanna send it pretty urgently down… I can imagine somebody would say “Don’t even load the code for this until they scroll it into view, because this is like a really low-priority island, so just save on that JS if they don’t even scroll to the comments section… Don’t even send it.”

[22:10] Yeah.

I wonder if you’re going to add more options and more flags there, and then the islands folder won’t be enough, because you need like islands, and then like three others types of islands… [laughter]

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 still try to yield to the browsers as often as it can, so you don’t block animations, stuff like that. But it is actually totally possible that we add an option in the future where you could just 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 “It should only be loaded on small devices” or “It should only be loaded when this media query matches” or whatever else. It’s just not implemented, because – yeah.

That would be pretty cool, yeah. That’s cool.

So the islands folder… Then the routes folder. Tell us about routing and how it works.

Yeah, so the routes folder is actually very much inspired by Next.js. This is one of these things which – like, Next.js did an awesome job originally with how their routing worked; it still does, I think. And yeah, it pretty much works the same way; it’s one file per route. You can have dynamic routes where you specify the match here 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 like async functions which take in a request and return a response; web request and web response.

So you can 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 wanna 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. If you wanna do data loading, you can do that in there. Or if you want to do like a redirect, you can also do that in there. You can do anything you want in it; it’s just an HTTP handler. 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 pass 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, it’s cool. You have 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. Those basically come from anything that’s matched in the URL. So like props from the URL, like different substitutions in the URL, and then also anything that the GET handler decides to return. So that’s where you can do your fetching stuff from the database, or whatever you need to do. That’s really cool. Does that mean that this GET handler thing runs 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 swathes 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 only build once a day, or something like that?

So the idea with Fresh his still that you would have – 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 server-side render really close to your users. The cost of doing that is very low. So if you wanna do something like that, what you would probably do is you would 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.

[26:09] Which is what we do with Changelog.com, and it works great. I think it’s actually a really great strategy, to 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? So if I have my Denos running on all these different Cloudflare workers, or Deno 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… But I wanna hear what your thoughts are on it.

It really depends… As always, it depends.

Cop out… No. [laughter]

No, I’m just prefixing this, because I’m gonna 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 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 and it can – 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 U.S. you’d have it live somewhere in the U.S, like Ohio, or whatever… And for users in Asia you could have it live in 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 no seconds - that 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 this situation where you have this server-side rendered - or cached, in the case of what you’re saying with an origin; you know, put a CDN in front of your origin and cache the response… That works great, except for like – lots of websites have just some sections that are dynamic. Let me change that… Not just dynamic, but personalized to the signed in user, for example.

Yeah.

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 Feross.” 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”, 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 you would essentially send back an empty shell to users if they’re signed in, 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, Deno Deploy is like 34 regions across the world. You can get a 15 millisecond response time from anywhere. Not if you’re in Australia

Yeah, but not if 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 Messenger, I know it’s got your list of friends, it’s got your news… And all these things are highly personalized to who you are. All that data needs to get fetched from some database somewhere.

Sure.

At that point your edge executions - they’re kind of moot, aren’t they?

[29:50] 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 you can have really fast read and write access to your data. And if you don’t care about write access so much, you can have global replicas. And 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. I don’t wanna leak too much stuff, but this is something we are working on for Deno Deploy, 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 etc. 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’ve kind of like got that one missing piece.

Do you wanna tell us more? I mean, you don’t wanna say too much, but you could say more. But I don’t want to get you in trouble. You’re just smiling at me now… No comment. [laughter] Let’s take a break right here. We’ll tease them. We’ll have a cliffhanger.

Okay, let’s get into it. Qwik, an HTML-first framework. Miško, there’s lots of frameworks out there. You’re the creator of one of them. It’s still out there, people still use it, Kball. 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 Deno side. “Why another framework?”, the million-dollar question.

I’m with you. Kball, are you with him?

Yeah.

Right.

I just wanted to comment real quick on the impulse buy of those shoes… The 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 - maybe that can be 8, 9, 10, 12 seconds if things are not going well.

Really?

Wow. Even like Nike.

I mean, assuming…

So I’d love to dig in a little bit, actually, on the virtual machine analogy… 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 at CloudFlare, or 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, 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?

Fair enough. Okay.

I was wondering that as well…

Yeah. And it’ll just dump that on the page, and everything boots up from there.

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 the pre-compile. And I am not a Svelte expert, but I have played around with it a little bit, and I think 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 Vue or a React. But I think they still do have a hydration problem.

So I’m kind of curious, are those problems deeply connected for you?

So I’m thinking about the statement that you said about the server-side rendering and the client-side rendering. With Qwik there’s never any duplication, there’s never any work that’s done twice… And I’m curious, is Qwik aware of server, is the server aware of Qwik? How does the server know the state of the page in order to not rerender things that have already been updated since it rendered last? Is there server-side – is it full-stack, or…? I don’t understand how it works.

So you are transforming the code, you’re applying custom compilations in order to make it resumable.

Interesting…

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.

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, that makes sense. Vue also has a store-based system a lot of the time so, yeah…

So what’s the practical difference then? What you’re offering with Qwik - let’s say the DX is relatively the same as using React; you put some dollar signs at the end of things, and there’s a few more rules, or different rules. What’s the practical difference? Is it an order of magnitude, in a complicated application? We’re talking about your apps can be 10x faster, 100x? Like, what happens when I use Qwik instead of React?

Okay.

Just a blank page. Just white – there’s nothing.

So Astro just came out with this 1.0, but it’s really not new. I mean, it’s new, yes, but not really. I feel I’ve been hearing about Astro for a while, I’ve been seeing you all push stuff, and it’s been this slow reveal… So can you give us some timelines and give us some insights into 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 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 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… And so that’s what Astro is.

Yeah, that makes a ton of sense, Fred. I feel like for me that’s like a really refreshing motivator and perspective, because to some degree, even things like AMP were really created to focus on - well, we have all these 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, 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 for better or worse…

Yeah, we’re gonna make 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, for me, I appreciate the experiment, I appreciate the innovation and I appreciate the intent, right? So now how do we further evolve from that, and it feels like Astro is taking a step in that direction.

I think for me this focus on content, and websites that are – that’s your niche. I’d say okay, great job picking a niche, because that’s really the majority of the internet, right?

Yeah. As far as niches go, you can’t really get much bigger… I think the last number I saw is like around 60% of the internet, or the top 500 sites, are that type of content-focused site… So yeah, as far as niches go, it’s a big one.

[01:09:58.19] Yeah. I totally agree. And where would you say places like Reddit fall into that spectrum? Because I feel like Reddit is 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 fall in that spectrum for you?

I think you used the right word, which is spectrum. It’s definitely different sites, and even different pages within a site can take different forms. So yeah, Reddit, 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 is our Northstar. But there’s really cool features that back that up. So the big one is thinking about how you architect 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 the interactive bits around the page.

So for some things - if everything is connected data, like you post something here, it updates the dashboard, 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 color in almost within the lines, like a paint by numbers. “Well, here’s the 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 users, you’re sending them these little snippets.

So that’s the biggest difference - Reddit works really well. Hacker News is kind of this like –

Clone…

Demo that people like to benchmark Astro against. Yeah. 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 is 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 the–” 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, and you’re being very intentional about what you want to be expensive. Versus this opposite world that we’ve been living in for however many years, where by default everything is chunky and heavy, and we ship it, and then we start subtracting from there after the fact. It’s kind of painful; no wonder teams have so much difficulty making their apps performance. We’re speaking English when we need to be speaking Italian, or something like that. It’s like, what are we even doing? So are we using the right tools? Are we using the right methodology? Are we using the right architecture? I would say, “No, no, no.”

So I think – yeah, I mean, I’ve said this before on the show, I’ll say it again… It might make some people upset, but for me in 2022 - I love tools like React, but they come with their own set of problems and whatnot… But generally, 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 create a simple website. I just wouldn’t; it’s just too chunky, 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’ll need to stop me, because I will talk about… 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 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 then applies - like, everything is Svelte, everything is Vue, where if you imagine, even like a simple Hello World Next.js site… And not the index.js; this is like the model that they use that everyone else is using. You’re not just sending down the – a Hello World, there’s nothing really interactive, but you’re sending down 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 codebase, you have this really nice separation of concerns, your backends and API, your UI is all one codebase… Like, there’s really nice organizational things that people love.

[01:14:31.08] From the developers perspective, right? Isn’t that DX though? That’s like the DX is –

Yeah, the DX is incredible. It’s unbeatable. Versus 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 codebases… I’ve seen some bad stuff.

But it’s that idea of “The DX was so good, but then we just took that path and ten years later we’ve 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 that React’s wrong it’s that we’ve way over-indexed on how much is powered by React or Vue or Svelte. At the end of the day, 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, and that’s going to slow it down.

Yeah, that makes a ton of sense. And again, it just goes back to like the intentionality of what we’re doing and how often we’re all working under such constraints and such cow paths that also the community has paved… There’s best practices, there’s tools like CRA (Create React App) that make things so easy, and just one button… Right? If we’re not careful about the complexities that we’re abstracting… If we’re abstracting away things like that are, okay, generally best practices and good decisions - great. But the risk of mass adoption and abstracting away some of those things - you’re making bad decisions that you didn’t even make… 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 App, there’s I think like 2,000 packages. 2,000 dependencies all sitting on top of each other. And we call that like – it’s complexity, but kind of wrapped and 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. 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.”

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 was what if we just actually removed a lot of that complexity? What if we dropped down what you have to think about when you build and instead gave you something that starts from first principles, web Standards, HTML? I think that’s a much better place than just continuing to wrap that complexity in more and more layers of abstraction.

Yeah, that makes a ton of sense. And like put the onus on the developer to intentionally make the decisions about where they want to take the app in terms of like “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 comes to the right conclusions. But it’s just actually like “Have we even thought about what we’re doing, really?” Most of us are just 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. Clearly, there was a need in the community for 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 that’s something that we can’t not talk about, because that is a real thing, a real problem.

And React was also the first application - we’ve talked about this on the show before - that went to npm Land and said, “Okay, JavaScript frontend developers, we’re gonna go hijack the Node community now, because we need Node tooling to build JavaScript apps now.” That was a shift that happened, and then we ended up with a bunch of Node tools that needed to build your frontend app, right?

Right. And then Node changed, and all the tools after…

Right.

We really like this term, all-in-one, and I think it’s a larger trend. I think Deno kind of falls into this… 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.

[01:18:22.25] Because it’s hard to maintain.

Yeah. So we like this idea of Astro being a really stable runtime almost, or platform, or foundation, whatever you want to call it, that is much more like “Build on top of this and we’ve got you.”

Fred, that was really insightful and super-interesting, kind digging into some of the context and history behind some of the motivations of Astro… Y’all make some pretty bold promises here; we’ll list through some of those. 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? That’s always the struggle with API design.

So let’s get into some of this… So we’ve talked a lot about the content-focused piece… Can we talk about the server-first piece? Because there’s quite a bit here with just being server-first. For me, I kind of read that 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, 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 ten years have been all about “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 generally 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 templating language that 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 HTML, and zero JavaScript being sent down the wire, unless you opt into it. You say “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. They might need all 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 like “Well, it looks great, because 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 how are you dealing with that, if at all? Are we just leveraging the fact that because the users have to be intentional and opt in, it’s usually a lot less JavaScript, and then there’s also no framework JavaScript that’s being sent along with this? I’m just curious, 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 interactive until all of it is. That’s really a uniquely SPA kind of problem. That’s really a 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, can they fall back on nice 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.

[01:22:31.08] So for example, if it’s not visible, we’re not going to run it. Until the user scrolls down to it, that’s when we’ll hydrate it. That’s a really cool, 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 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 much more decoupled, and by result, things that are like really essential can load much faster, because we let you control what loads when and how high priority it is.

Yeah, that makes sense. So there’s this like waterfall that you get with like unbundled ECMA modules, right? You have a bunch of different JavaScript chunks; true loading in parallel - is that even achievable really in the browser these days? I don’t know, you tell me about it.

Yeah, I mean, that 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 blown away all the performance optimizations of bundling and minification. We still do do that. But it’s a really interesting model. Instead of saying, “Okay, here’s your whole page as a single JavaScript bundle”, we’re saying almost “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 too much about it. But it’s a result of us behind the scenes still giving you the model, while handling the complexity of the behind the scenes for you.

That makes sense. So there is some intelligence 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 a trick of how do you talk about your framework when every framework claims to be fast… But what we like to say is it’s fast by default, which I don’t think the other framework can really claim. What we mean by that is 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 gonna rank faster sites over slower sites… And a lot of other frameworks you’re kind of like “Okay, we’ve 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 it should be really difficult. You should be having to try to make Astro slow for it to be slow. Otherwise, just keeping you out of that pit is really a main goal of the project.

Yeah, yeah. That makes sense. That’s really great to hear, and I would say… 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, or put some confetti around it, or something.

Yeah. You have to try. You’ve got to break Astro to break our performance story. That’s our goal.

[laughs] That’s cool, good marketing. And so another kind pitch on the Astro site is easy to use. And I noticed that there is a .astro UI language that’s part of this framework. So can you tell me a little bit about that? And easy to use is a tough claim, because that’s always relative, but… How easy is it? Is it as easy as JSX, where it looks like HTML, sort of, but still comes with its, I would say, dragons? So what’s easy here?

[01:26:02.00] 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. 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, like “Why use this?” “Oh, it’s easy to use” - 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 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 trying to give like basically 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 gonna work just like anything else to generate your UI.

So there’s this idea of bringing something you know, to feel comfortable, pretty much from day one, using Astro. Even if you’re migrating a site, bring that site; as long as there weren’t framework-specific bits, if it’s just a React component that’s like super-agnostic - fantastic. It’ll probably work in Astro, assuming you meet that – you didn’t bring in anything that was framework-specific from the old world.

The other side of that is that 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 these atoms that are responding to state changes… Those were all frameworks that were designed first for the client, which has a much more complex interaction story. And then they’ve kind of been back-ported to the server.

Because we’re so server-first in our thinking, Astro is just a templating 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 like HTML with some 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 a React, but we’ve stripped away all the bits that aren’t really relevant on the server. So you have your 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, honestly, I didn’t even really put those things together in my head… Really, like, when you optimize for server first, and you’re optimizing for HTML, you also by default - it’s just easy to use, because you’re not like, you know… Yeah, reactivity is really where things get complicated, right? That’s like the 201, 301, 401, 501 classes… You know?

[laughs] Yeah.

HTML is like beginner-friendly, but doesn’t hold you back in terms of presenting structurally complex data, or sites either. So that’s like the beauty of HTML.

It’s something that’s always bothered me, like “Oh, this Hello World tutorial… Well, you 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…” 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 in HTML from anywhere, put it in an Astro, that’s a site. You’ve just built a site with Astro, and that’s our Hello World.

Yeah, that makes sense. Fully-featured, but flexible is the other thing. Right? So you hinted a little bit about 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? There’s over 100 Astro integrations to choose from. What are Astro integrations? It sounds like a physics seminar of some kind, but I could be wrong…

[laughs] Yeah, you’ve got to put on your lab coat, put on your goggles, jump into your config files…

Current astral projection for this equation is…

[laughs] Oh, no…

[01:30:08.19] You know, it’s okay. Listen, this is why I don’t like writing – it’s hard to write Astro integrations; I’m sure it makes sense in the context of web development, and in the context of Astro. So why don’t you tell us about what that is?

Yeah, I’m just laughing because I’m never gonna be able to get that image out of my mind for the rest of my life. [laughs]

I’m sorry, Astro integrations…

[laughs] It’s okay…

It’s hilarious.

Yeah, it’s our plugin ecosystem. We really liked 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 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 in Astro. We’re going to focus on content sites, so stuff like RSS feeds… God, what else…? Rendering Markdown… There’s all these nice little – like, very much more coming from like a blog, or like an Eleventy, nice-to-haves that are essential in the content site. So we build stuff like that, and make it really easy to grab off the shelf. And then when you want to use something like Tailwind or React or Svelte, we essentially have not just a kind of plugin, an 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.

Oh, wow.

It’s gonna npm-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 gonna run a big normalization query on the JavaScript community.” Are you like hooking into the public interface, or like 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 SPA, 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 there. I think that’s actually pretty much exactly the magic that we’ve shipped.

Yeah.

The reason 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, and was like “Yup, here’s a component, here’s a component…” It was all frontend focused, and then the “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.