Supper Club × Qwik framework from Miško Hevery, the Creator of Angular

I sure hope you're hungry.

Cool. I'm starving.

Wash those hands, pull up a chair, and secure that feed bag, because it's time to listen to Scott Talinsky and Wes Boss attempt to use human language to converse with and pick the brains of other developers.

I thought there was gonna be food, so buckle up and grab that old handle because this ride is going to get wild.

This is the Syntax supper club.

Welcome to Syntax.

This is the podcast with the tastiest web development treats out there.

I was wrong about what resumability was. We talked about it, I don't know, like, a month or 2 ago, and, we are going through All the, like, different kinds of, like, hydration and and server side and whatnot. And we got to the resume ability one, and Scott was trying to explain it to me, but I just I just wasn't grokking it.

So I thought, like, why don't we have, the creator of quick on, which is one of the frameworks in the space right now that is sort of championing Champion championing this thing, which is, resumability.

So if you are, like, a a React developer or or something like that, you're gonna wanna listen to this one because it's super interesting. So, Mishko Hevry. That's right. How that's how you pronounce your name? You got it on the 1st try, man. I'm very impressed. Nice. Awesome. So, among other things, creator of Angular, Angular JS, and now working on this sort of New approach, new mindset to building applications, both server and client side. So excited. Welcome. Thanks for so much for coming on. Thank you for having me.

So I watched a little bit of the YouTube video. I I went through the documentation, enough to get, like, a good idea, but, like, Not too much because I still wanna ask them some really good questions. So, do you wanna give us a quick, quick rundown or or do you wanna give us a quick I can't.

I'm almost curious. Like, what do you think user mobility is? Like, I wanna hear your side of the story, and then I see to kinda better understand, like, where where thinks where the message isn't getting through. So what what do you think it is? After going through the docs and whatnot,

I think It downloads the HTML and then only downloads the JavaScript to run that that part of the application, whether it's a A counter or a shopping cart or something like that when it's needed. So it's sort of on demand loading both of the JavaScript, but as well as It looks like you can do state, and I saw this amazing example where you literally just copied the HTML, pasted it into another tab, and the thing just Resumed.

Yeah.

How how close am I? No. It's actually pretty close.

I would actually say that's that's that's dead on.

I think the the trouble is that people say like, well, that sounds reasonable. Why can't my framework do that? Right? And so the interesting bits are more about, like, Why other frameworks can't do this? Like, what is it about them? Right? And then once you understand that, there's mobility. It's kinda like one of these things. Like, of course, obvious. Why would you do it any other way? So so it's more like that. Okay. Okay. So into it if you'd like. Yeah. Yeah. Let tell us about it. So the best way I can, I found to kind of explain it is, do you remember when virtual machines first came on to, scene? And one one of the things you could do in the virtual machine is, like, let's say you're on your host machine. Let's say you're on Windows. Right? And you boot up in Linux, and you literally watch in the window As Linux is booting up, so you see BIOS comes up, and then the boot up sequence happens, and then the login screen shows up, and then type in your username and password, and you log in. And then, you know, open up, I don't know, spreadsheet or something and, you know, start typing your expenses. Right? And at any point, You can heat hit the pause button, and the virtual machine saves the full state of everything into the disk into a file.

And the thing that blew my mind when I first saw this is that you can take this file and move it to a different physical machine, Different host machine.

Right? And open it, and the machine is literally where it was. Like, where did you just left over? Like, it just resumed.

Right? What you didn't see the 2nd time you did this is you didn't see the boot up sequence. You didn't see the BIOS come up. You didn't see the login screen. You don't have to log in. Like, you literally It it came up and your spreadsheet was open with the cursor blinking at the next thing you could type in. Yeah.

And and you could duplicate that and send it to a friend. That like, that's how the IE machine is brought. Right? Yeah. Yeah. So the the power of that was, like, oh, great. I can just, like, make Fifty copies of this thing or a 1000 100000 copies of these things and send it to all my friends, and they literally just resume where you left off. Okay. Okay. Yeah. No. No. I I I guess I, for the for the listeners who aren't familiar

with quick at all, maybe maybe it'd be good to give a, Like a, just a a high level, like, quick as a thing is a JavaScript framework to do user interfaces. Is that

So, the best way to kind of describe it is like what other things are. Right? So so if you have mostly React developers. So Quick is just like React.

Mhmm. And Quick City is like, let's say, Next. Js or Remix.

Right? So, basically, the full stack development that people Are used to that they do today in in the quick in the React ecosystem. We have kind of, you know, the equivalent of these things In the quick ecosystem. You know, if you go to Vue, there is Vue and Nuxt. If you go to Solid, there is Solidance, I would start. If you go to SwaltKit, there is SwaltKit and, sorry. Swelt and Swelt kit. Right? And so, all of these ecosystems basically have the same parts. So quick and quick city are the 2 parts that together allow you to build anything you could build on Next. Js, and it's literally equivalent. Like, My point of view is that whatever you can build with React or Angular or any of the other favorite frameworks of yours that you happen to have, You should be also be able to build in quick. So in terms of capabilities, it's in the same category. Yeah. Like, I got the feeling that you'd be able to,

Like, scan the docs in half a day, go through the tutorials, and and you'd be up and running pretty quickly because, like, the big thing is is it's JSX. Right? Like, you're you're using the same

templating language that React is using. Right? JSX, it's hooks, you know, for especially for a React developer. If you come too quick, you look at the stuff and you go like, This is very familiar, and you should be up and running very quickly. And it's kind of intentional. This is not, one of the things is When we were doing this, we wanted to bring something new to the table, and the new thing to the table is resumability.

And so we didn't wanna reinvent the wheel on everything else. And so we were like, what off the shelf components can we grab to make this thing, you know, do its thing so that we don't have to get distracted, And we can just focus on the value add, and the value add is resumability. Okay. Can you give us, like, maybe a couple examples

of components that you might want to make resumable

and and, like, why you would even want to do that? Yes. So so the interesting part about QUIC is that as a developer, you don't really have to think about it. Like, that's kind of the value proposition here is is that, you you know, the easy thing, the obvious thing, the the The the natural thing to do when you're building your application component or what have you is also the performant thing to do. Like, the 2 are aligned. It's not like you have a choice to make. Like, I could do the easy thing or I could do the performant thing, and I'm I'm at the time pressure, so I'm gonna do the easy thing. Right? Like, no. No. The 2 are the same. They they're literally the same.

And so as a developer, you don't really, think about it or choose to make things resumable or not resumable. It's just The property of the system that automatically just happens for your whole application. So you just build an application as you would build any other thing.

And then, the application has these interesting properties, which is that, first of all, SEO out of the box, You didn't have to do anything and just SEO out of the box. Right? So it's it's SSR first.

Then other property you get Is that well, we don't send all the JavaScript over until it's needed.

But now you also need to start doing prefetching, so then make sure if you're like in a tunnel or the connection is, Hick, you know, hiccupy or something like that. You you perform well, so you get, prefetching of the code out of the box. There's a service worker that does that, and that's that's very intelligent.

Code splitting, bundling, making sure that you don't have overly large bundle sis sizes.

So all of these optimizations that normally you have to do once your gets big. They're just part of the how QUIC works, and you don't even have to think about it. It's just it's just there. So is the pitch

You get to write things with a very similar API. It's it's not the same if you if you look at some of the docs, but, like, it's very similar to a lot of API.

A lot of stuff is nicer. Right? So you get a very similar API, but you get a more performant experience without having to really adjust your your, frame of reference that much? That's right. That's that's exactly it. And I think we can go down a,

kind of an example to kind of appreciate, this. So let's say Let's say you decide your application is big and you need to do lazy loading.

Right? I mean, application gets big, and then it it's too slow to load. And, You know, you talk to the experts, and the experts are like, that's easy. Just break up your application in smaller chunks. Right? Yeah. So let's go down that rabbit hole.

Into tooling hell. The tooling hell that's required for this thing. So so you say, well, the first thing you need to figure out is where exactly you're gonna put a boundary, and this is not obvious.

And let's say you find a component that you wanna lazy load. So in React, you would, move the component to separate files so that you can, create a separate chunk, Then you leave behind the lazy, function call. Right? Then you put a suspense around it.

And now in theory, this thing is lazy loadable. Right? So then you start up your application and you realize, actually, bunkers, it isn't because that particular component is visible on initial render.

And so the fact that you made it lazy loadable didn't actually help anything.

Because you see the suspense or lazy loading of components It's only useful for components that are not currently in the render tree. Right? If the component is in the render tree, it's pointless to do the rendering Because, like, it has to be rendered. And so you actually just made the situation worse. Because now instead of getting a single bundle that's all, you know, in line, Now you actually got 2 bundles, and the way React does this is it renders everything up to the suspense boundary, then it, like, gives up, waits for the thing to load, and then starts rendering again, You know, from where it left off, and so now it's doing twice as much work. And I mean, not exactly twice as much, but, like, it's more work than it would just Yeah. Do the whole thing, directly.

And then let's say that this works, then you have another problem, which is like, great, but now I'm in a slow network and, like, this lazy loading really is bugging me because there's a delay, and so now I have to out, like, how do I prefetch these things? And you think you could just add a prefetch tag to the the the, HTML.

Turns out that's broken.

It it kinda works in Chrome and everywhere else. It just doesn't work. Like, it's just a hint that everybody else ignores, especially mobile devices.

So that doesn't work.

So then you have to have some other mechanism for fetching the code, and deciding, like, when exactly should I fetch The code. Right? If I fetch all the code eagerly at the beginning, then that's kinda pointless because, like, that's the same thing as just loading everything.

And so you have all these problems that Arise when you try to lazy load something, and it's not obvious that you even can. Right? So, like, we did a simple example of lazy loading component. But let's say the problem isn't that. Let's say the problem is that you have to lazy load a listener or only part of it or you know, there's, like, gazillion different ways you do that, and then, of course, if you go through all this trouble, you might not actually get the benefit you thought you had. You know, how do you measure this thing? Then how do you move these

boundaries over? It's hell for anybody who is trying to do this. So from the right from the get go, the code that you write in quick is is going to be able to be chopped up and laser loaded as you need it and prefetched and and all of that good stuff. Yeah. So the one way to think about it is,

That we basically, place laser loaded boundaries everywhere. Like, everywhere we could possibly think of. Right? Speaking components, listeners, use effect functions, use init functions. Like, every single thing you could possibly think of that could be delayed loaded, It automatically