Episode 77 - Qwik with Miško Hevery
Miško Hevery explains how Qwik's resumability model eliminates hydration entirely, enabling near-instant web app startup performance.
Episode Description
Miško Hevery explains how Qwik's resumability model eliminates hydration entirely, enabling near-instant web app startup performance.
Episode Summary
Miško Hevery, creator of AngularJS and Angular, joins the show to introduce Qwik, a web framework built around the concept of resumability rather than hydration. He explains that existing frameworks discard server-side knowledge about components, listeners, and state during the transition to the client, forcing redundant work that degrades performance. Qwik solves this by serializing both application state and framework state into HTML, allowing the client to continue exactly where the server left off—much like resuming a virtual machine. Hevery contrasts this with React Server Components, which require developers to manually designate server and client components, whereas Qwik components seamlessly transition between both environments. He introduces the concept of containers—independent sub-applications on a page that enable fine-grained routing and state preservation during navigation, blurring the line between single-page and multi-page architectures. The conversation also covers Partytown, a tool that moves third-party scripts to a web worker to free the main thread, and how Builder IO's visual editing platform motivated the creation of Qwik to deliver fast e-commerce experiences. Hevery argues that slow websites are a systemic framework problem, not a developer failure, and that resumability cannot be easily retrofitted into existing frameworks.
Chapters
00:00:00 - Introducing Qwik and Its Origins
The episode opens with Miško Hevery being welcomed as the creator of AngularJS, Angular, and now Qwik, the framework he's building at Builder IO. Anthony notes that Qwik has been one of the hardest frameworks to understand, likely because it represents a genuinely novel approach to web development rather than an incremental improvement.
Hevery traces Qwik's origins to a talk he gave at ng-conf roughly three years prior, where he argued that better startup performance required fundamentally rethinking how frameworks handle lazy loading. Qwik emerged from asking what web development would look like if applications could "sip" JavaScript incrementally rather than downloading and executing everything upfront before becoming interactive.
00:02:04 - Resumability Explained
Hevery introduces the core concept of resumability using a VMware analogy: just as you can save a virtual machine's state on one physical machine and resume it on another without rebooting, Qwik serializes the full state of an application on the server and resumes it on the client. Unlike hydration—where the client must redo work to recover component hierarchies, listener bindings, and data relationships—resumability means there is simply no redundant work to perform.
He explains that Qwik serializes two distinct kinds of state: the application state that developers think about (like a to-do list) and the framework state that tracks component relationships, subscriptions, and event listeners. Because all this information is embedded in the HTML, the application can be paused and resumed across any boundary—server to client, tab to tab, or even into local storage and back—without re-executing any code.
00:06:08 - Comparing Qwik to React Server Components
Hevery contrasts Qwik with React Server Components, describing RSCs as a halfway solution. In RSC, developers must explicitly label components as server or client, with rigid constraints on each: server components cannot have listeners or state, and client components cannot render on the server. This hybrid model introduces new complexity that developers previously didn't need to manage.
In Qwik, components begin their life on the server—setting up listeners, collecting data, and handling events—then seamlessly move to the client to continue executing. The framework also performs an advanced form of tree shaking based on which components actually need to re-render on the client, meaning static components never ship their code to the browser at all, reducing payload without developer intervention.
00:10:32 - Use Cases, SPAs, and MPAs
Chris asks what types of applications Qwik is best suited for, prompting Hevery to address the long-running SPA versus MPA debate. He argues the distinction exists only because traditional frameworks force the router to live exclusively on the server or the client. With Qwik's architecture, an application can start as a multi-page app for the initial load and seamlessly transition into a single-page app for subsequent navigation, preserving state across routes.
Hevery introduces the concept of containers—independent sub-applications that can coexist on a single page, each with its own build and deployment lifecycle. Containers enable a routing model where the outer shell retains its state while inner content is replaced with fresh HTML from the server, letting the framework intelligently decide whether it's cheaper to execute code client-side or simply fetch pre-rendered HTML, potentially served from a CDN.
00:18:49 - Builder IO and the Business Case for Speed
The conversation shifts to Builder IO, the visual editing platform where Hevery works. He explains that Builder IO lets engineering teams give marketing a drag-and-drop editor with registered components, eliminating the cycle of engineers building increasingly complex configuration levers for content changes. Marketing teams gain full creative control within a sandbox while engineers focus on product development.
Hevery connects this to Qwik by explaining that Builder IO's e-commerce customers need fast sites for conversion, yet virtually every production website scores poorly on Google PageSpeed. He argues this is a systemic framework problem rather than developer incompetence—if no production sites achieve green scores, the tooling is at fault. Qwik and Partytown together address both first-party and third-party performance bottlenecks, making speed a competitive advantage.
00:25:25 - Partytown and Third-Party Script Performance
Chris highlights the real-world impact of third-party marketing scripts on page performance, noting that even sites that achieve perfect scores lose them once tracking pixels and analytics are added. Hevery explains that Partytown moves these scripts to a web worker, freeing the main thread, and the key innovation is making asynchronous cross-thread communication appear synchronous to scripts that expect it.
The technical trick involves exploiting synchronous XMLHttpRequest calls to block the worker thread while the main thread resolves DOM queries, making the experience transparent to third-party code. Hevery notes this approach consistently yields around a 20-point improvement in PageSpeed scores. The discussion touches on Partytown's integration with Next.js and potential WordPress adoption, emphasizing the broad ecosystem impact beyond JavaScript frameworks.
00:31:18 - How Qwik Differs from Preact and Other Frameworks
Chris asks whether Qwik's React-like API makes it a Preact alternative, and Hevery clarifies that while the surface API is intentionally similar, resumability imposes constraints on what can be stored in state—promises and other non-serializable values won't work. This means existing React applications can't be trivially ported, though the developer experience is deliberately kept close to minimize the learning curve.
Hevery emphasizes that Qwik differs fundamentally because it takes responsibility for bundling alongside rendering. The optimizer component automatically creates fine-grained entry points for every component, listener, and effect, enabling the lazy-loading behavior that makes resumability practical. Traditional frameworks treat bundling as someone else's problem, which limits their ability to achieve the same granularity of code splitting.
00:35:13 - The Future of Qwik and Qwik City
Looking ahead, Hevery discusses Qwik City, the meta-framework layer that will handle routing with seamless MPA-to-SPA transitions. He expresses confidence that resumability represents a breakthrough that competitors cannot easily replicate, arguing it would require such fundamental breaking changes to existing frameworks that the result would essentially be a new framework anyway.
The conversation wraps with discussion of community building efforts including a Discord server and conference tour, the Builder IO website already running on Qwik as a proof of concept scoring 100 on PageSpeed, and a teaser about Mitosis—Builder IO's tool that writes components once and generates native code for React, Angular, Svelte, and other frameworks. Hevery's socials and project links are shared before signing off.
00:45:00 - Closing
The hosts wrap up the episode with brief closing remarks after thanking Miško for joining the show. The conversation concludes on a positive note with an open invitation for a future return appearance.
Transcript
00:00:00 - Christopher Burns
Hopefully you enjoy being here.
00:00:02 - Miško Hevery
I'm sure I will.
00:00:12 - Anthony Campolo
Miško, welcome to the show.
00:00:14 - Miško Hevery
Thanks for having me.
00:00:15 - Anthony Campolo
You are the original creator of Angular and now the creator of this new framework, Qwik. And I believe you work at Builder.io. Is that correct?
00:00:24 - Miško Hevery
That is correct, yes. And technically, it's AngularJS first and then Angular, so there's two frameworks in there. But it's confusing, I know.
00:00:32 - Anthony Campolo
That's right. Yeah, we're really happy to have you here. We've had so many framework authors on the show already, and I know Qwik is one that has been the hardest for me to kind of wrap my mind around. And I think that's because it may be the most unique and the most revolutionary in terms of what it's doing. So I'm really excited to dig into it and talk about what it is. But I'd be curious to hear a little bit of the background of where it came from, and if that was wrapped up in your work with Builder.io, or what the origin of Qwik itself was.
00:01:01 - Miško Hevery
Yeah, those are all good questions. And you're right, it is very different, so it's kind of hard to wrap your head around. I think the origin of it came about three years ago when I was at ng-conf and I gave a talk. In the talk, I basically said that if you wanted to have better startup performance for your web apps, we have to get better at micro, fine-grained lazy loading and think about what kind of things we would have to do to a framework to allow fine-grained lazy loading. And Qwik is essentially the extension of that. Qwik is all those learnings and all those ideas of starting with: what would the world look like if you didn't have to download all the code ahead of time and execute it all ahead of time? What would I have to change so that we could sip on the JavaScript rather than gulp the whole big thing at the very beginning of the application to get things going?
00:01:45 - Anthony Campolo
Yeah, that's great, and that makes a lot of sense. And when I hear something like that, I know a lot of people like me will think of partial hydration. But I also know you will specifically say this is not partial hydration. This is something else entirely. Resumability is, I know, one of the terms that you're using to describe this. So could you talk about what resumability means in this context?
00:02:04 - Miško Hevery
Yeah, I think the easiest way to understand it is to remember when VMware came out with virtual machines, and it was just so bizarre that you could boot up your Windows inside of a host environment, open a bunch of apps, and then save the VM, move it to a different physical machine, resume it, and continue exactly where you left off. So you would skip the boot-up process and you would skip opening the applications. If you're in the middle of writing a document and save the VM, move it to a different physical machine, and resume it, you would be in the middle of writing that document. Just continue typing. That's the mental model of resumability, is that if you look at existing frameworks, what they do is they run a whole bunch of code on a server and they generate HTML. And then a lot of knowledge about the framework, what I mean by knowledge is information about what the components are, where they are, what the boundaries are, and where the listeners are.
00:02:52 - Miško Hevery
All that knowledge is kind of thrown away. And then on the client the framework has to redo all of this work again to recover all of this stuff, and partial hydration or lazy hydration, etc. are just different ways of saying when the work needs to be done, but nobody is arguing whether the work needs to be done or not. Whereas if you go to Qwik, the work fundamentally doesn't get done because on a server we collect all this information, we serialize it into HTML, send it to the client, and the client can literally just continue, just like the VMware example, where the server left off without any work being redone. And that's the key difference: there's nothing redone. We're not arguing about whether we're going to do it eagerly or late or together or in parts. There's just nothing to do. And that's why the word hydration doesn't fit there, and it's better to talk about it in terms of resumability. And this trick, by the way, can be done multiple times, right?
00:03:41 - Miško Hevery
Normally we go from server to the client, but there's nothing that stops you from pausing the application again and going to a different tab, or saving it to local storage and then resuming the tab later on exactly where you left off. So there's more to it than just hydration.
00:03:56 - Anthony Campolo
Now that you're describing it that way, it sounds to me a little bit more like the way I heard React Server Components first described, because that was about doing as much as you can on the server and then streaming it, but I think you would still end up doing some sort of hydration. So it sounds like this is taking that model kind of to its logical conclusion in terms of, what if we could really just get it to be completely resumable? How do you achieve that architecturally? What do you do to do that exactly?
00:04:23 - Miško Hevery
Yeah, so there's two questions in there. We could go down that path of React Server Components and how it's different. Maybe we'll revisit this later. So the question is, how do you achieve it? And the answer is kind of obvious and yet very difficult. It's obvious because, well, you just have to save all of the state of the application. And the thing is, the reason it's hard is because there's two states, right? There's the state of the app as the developer sees it. If it's a to-do list and it's a list of my to-dos and whether or not the to-dos are done, that's the way I think of it as a developer, the state of the app. And that's one thing you have to save. But if you're a framework author, you also have a different state in your mind. And what you mean by that is, what are the components? What are the relationships between components? Where are the listeners? If this listener fires and modifies this data, who do I have to rerender?
00:05:04 - Miško Hevery
So there's a secondary set of information about the component hierarchy and the things that the framework keeps track of, which you don't usually think about because, well, you're an author of an app, not an author of a framework, but there is this state as well. And so what Qwik knows how to do is serialize both of these. It knows how to serialize, obviously, the application state, but also the framework state, and not just the framework state but also the listeners that go with it. So at any point in time, you can call pause on a Qwik application, everything gets serialized, and then the HTML that you have fully describes the state of the app. Then you can move this HTML anywhere you want, whether it's from server to client or from tab to tab, or just temporarily save it somewhere, it doesn't matter. At some point you're like, I want to resume it, and so you say resume and all of the information is there.
00:05:51 - Miško Hevery
And so you literally just continue where you left off. You don't rerun any code. It's just there because what would you be rerunning? You already know the relationship between components. You already know what component is subscribed to which data model. All of this information is already there. So there's nothing to redo because you already have everything.
00:06:08 - Anthony Campolo
Okay, that's really interesting. And just so we don't lose the thread, let's talk about the react server component stuff. And then Chris can ask some questions.
00:06:15 - Miško Hevery
Yeah. So React Server Components, I would say, are kind of halfway compared to what Qwik is. And the biggest difference is that in React Server Components you choose your component and you say, this is a server component, this is a client component. And that component can never move. If you declare something as client, it's always going to be client. It will never be on a server, and vice versa. If you declare something as server, it can never become client. And there are constraints, like server components cannot have listeners, they cannot have state. Client components can have state and listeners, but they can't be rendered on a server, and so on and so forth. So you kind of have this hybrid world where half of the app runs on the server and half of the app runs on the client. While you can do amazing things with it, I'm going to say that this hybrid world is actually a complication for the developer because previously developers didn't have to think about this distinction and now they do.
00:07:01 - Miško Hevery
Now they have to understand, like, oh, this is server, this is client. I can't just call into it because that's a different thing. And there are all kinds of implications that make my life as a developer a little more complicated. So the thing with Qwik is that the component starts its life on a server, so it executes on a server, on a server that can collect data. It can do all of the things that it needs to do, whether it is setting up listeners. And I know this is kind of bizarre that you can set up listeners on a server, but yes, in Qwik you can do that. You can set up listeners, you can set up events, everything you need to do, and then the application or the components move to the client and continue their execution on the client. And that's kind of weird, right, to move something over, but that's kind of what you get. And so the advantage of that is you don't have to have two different mental models of, is this a server component, is this a client component?
00:07:48 - Miško Hevery
Because it's both. The other advantage we get is that Qwik understands the relationship of components and when the components have to get rerendered and so on and so forth. And because of that, we can recognize that, oh, this component actually will never rerender on the client because for whatever reason it doesn't change. And because of that, the code will never download. It's not like you start execution and then all of the code moves to the client and continues on the client. It's more like you start on the server, and then you recognize that certain components just don't need to be on the client. And so when you move things to the client, you only move the pieces that actually need to be there. And so it's a form of tree shaking, but tree shaking not on the level of who calls who, but more on the level of which components need to rerender when which data changes. And that's a very different way of thinking about it. So obviously we have the basic tree shaking, but this is a whole new different kind of tree shaking that can only exist once you rerender something on a server and say, okay, well, this component will never change again because it's maybe a shell or maybe it's a list of comments or something like that, and so it just doesn't get shipped to the client.
00:08:52 - Christopher Burns
This is actually really, really interesting. I've been exploring multiple frameworks myself of late. I'm very much a React developer through and through, not because I don't like other frameworks, it's that a lot of the time I don't have a need to use them, if that makes sense. React is kind of the tool that fits everything. And a perfect example is that recently at my company I've been building JavaScript SDKs, and I have a pure JavaScript SDK and a React SDK. When you build them, the difference in size is that the pure JavaScript SDK is, I think, like 3 kilobytes or something tiny, but then the React one was like 200, 300, 400 kilobytes, way larger. And when you compare the code, it's that level of abstraction you have with React. Yes, the code is a lot easier to write than pure JavaScript, but the pure JavaScript one is a lot smaller and a lot more efficient at what it's doing.
00:09:53 - Christopher Burns
So with that, I've been exploring multiple other libraries, like importing this standard JavaScript SDK into Svelte and Vue and other libraries, and really been able to play around with more frameworks of late. Something that I think is really interesting is that whenever I look at a framework, it's like, what is this for? Who is this for? What's the best use case for it? That's really my first question. When I go to pick up something like Gatsby, even though it's React-centric, I think I'm going to build a marketing website or a blog or something with a unified interface that I can easily build loads of pages with. What's the first thing that comes to your mind when you think of a Qwik website or application?
00:10:32 - Miško Hevery
It's a great segue. So first, I'm actually a fan of React. I know it's a weird thing to say for an Angular person, but I think React got a lot of things done correctly in their DX. The fact that a lot of people are moving toward it, I think, speaks to it. So as far as the DX of React, I think they got a lot of things right. When we did Qwik, we actually tried to mimic as much of React as possible, and this was intentional. Qwik is such a different way of thinking about what an app is that we didn't want to also be like, oh, well, now you have to change the way you think about building apps. It would be much easier if we could just say, React, great, all the mental models that you know from React translate over to Qwik rather well. If you look at a Qwik app, you don't even have to squint very hard and you're going to be like, oh, this looks just like React, right?
00:11:13 - Miško Hevery
And again, it's not a coincidence. It's a complete intention to get there. So you're now asking a slightly different question, which is, what is the preferred way of using Qwik? And I think the world is kind of split into two camps, the SPA camp and MPA camp, the single-page applications and the multi-page applications. The multi-page applications are really, as you pointed out, the Gatsbys, the static site generators, where you generate things ahead of time. But really what the difference between SPA and MPA is, is where is the router? Is the router in the JavaScript on the client? Then you have yourself a SPA. Is the router on a server? Well, then you have a multi-page application. The implication of that is that every time you click on something, you do a full page refresh and therefore you don't have an easy way of moving state from one page to the next page. And that's what makes an MPA more favorable toward static documentation websites, right?
00:12:11 - Miško Hevery
Or e-commerce websites. The movement of state is what makes a SPA a lot more favorable to purchasing your ticket or going to check out your bank balance or things of that sort. And there's been this huge back and forth going on in the industry about MPAs and SPAs. And the thing with Qwik is I'm looking at it from the point of view of Qwik, and I'm like, I don't actually see the distinction because the distinction only exists because you start the router on the server and then you have no way of moving it. But with Qwik, why can't you start the routing on the server? Why can't the first page be an MPA page, but the subsequent pages be SPA pages? Why can't you just seamlessly transition from the MPA to SPA so that you don't even have this discussion, or even have to talk about it? We don't quite have the whole routing thing figured out yet. We have it figured out. We haven't implemented it yet.
00:12:59 - Miško Hevery
And so there's a lot more work. And there's this follow-up thing we're trying to do called Qwik City, which has the routing thing in there. But the basic idea is that you should be able to start your application as an MPA and then just transition into SPA without the developer even having to think about it. If you ask me what kind of apps Qwik would excel at, it's actually both. It is both the documentation, like Gatsby-generated sites, but also full-on applications which require state transitions and state to be present as you go from route to route.
00:13:29 - Christopher Burns
I think something that a lot of people forget is, how do pages actually refresh? When you open your developer tools and you see, oh, it's refreshing the whole page, what does that mean? Well, that means HTML is coming down the line, like a whole new HTML bundle is coming down the line. But then when you navigate in a SPA, it's just JavaScript. It's just sending more JavaScript. And it's such a different way of looking at things that sometimes I feel when you're really new to the industry, it's actually really hard to understand the difference and the pros and cons to each, and why you should pick one framework over another. I know so many people are always quick to get on, not necessarily a bandwagon, but just use X because everybody uses X. But why are we seeing this whole renaissance of frameworks that are all trying to do different things better than the other ones? It's because X is great for the big companies, the companies that have a lot of staff who can maintain everything.
00:14:24 - Christopher Burns
But when you want to build something really small and move really, really fast, other frameworks are starting to look like very good options. One of the biggest things that I thought was really cool, what you brought up, transition of state, something that always comes to mind, and obviously it's quite a new thing when you're talking about snapshot management and moving things from server to client, is Xbox Quick Resume. You can close a game, turn off your Xbox, come back to the same game 30 days later, and just carry on. Five years ago, consoles couldn't do that. Games couldn't do that. But we're getting to this point where we can virtualize games. And why can't we do that with websites? Why can't we do that with everything else? It shouldn't seem that hard in my head. You just pause everything and then move it across and resume it. Why does it need to do everything else the server did before? And one of my big questions is, does that mean that it heavily implies ESM usage because they now use the same bundle compilation?
00:15:22 - Miško Hevery
Ah, yeah, ESM. So it gets complicated. We actually have to build two systems. We have to run the build twice, once for the server and once for the client. There's a lot of nuance as to why that is. I don't know necessarily whether this would also apply to something like Deno because it's a lot more ESM-centric. But as of right now, we do actually have to build that system twice, once for Node so that the server can run, and then we do another build for the client. All of this is done in Rust, so it's super fast. You don't even have to think about it. It's pretty seamless. You reminded me of something, and I wanted to add to it. Qwik has one more new concept that other frameworks don't really have, and I think it's relevant to routing and how Qwik works, so I want to jump into it. The concept, we call it containers. And the way to think about it is when you have a normal application, you have a single app on a page and that app controls everything.
00:16:15 - Miško Hevery
Qwik actually has this concept of containers. And what containers essentially are are smaller apps that you can have on a page. So you could have as many apps on a page as you want, and the containers have a way of talking to each other, etc., but each container is a separate build. So you could have a large team of people and be like, oh, I'm doing the settings page and I need to do my own pushing, my own rollback, etc., whereas I'm doing the landing page or something like that. And they're independent. Now, the reason why this matters is because imagine the routing situation. What you want in a router is, the first time I navigate to a page, I want the server to send me nothing but HTML and no JavaScript. So you get the HTML. Well, there's a teeny tiny bootstrap loader we can talk about later, but for the most part you get no JavaScript, so you just get HTML and your whole page shows up, and now you start interacting with the page and different parts of the page start waking up.
00:17:08 - Miško Hevery
What I mean by that is we unpause them, right? We do the resume on it, but we don't have to resume the whole page. Instead, we can resume individual islands, and these islands are called containers. And what's interesting about it is, imagine you have one island that's on the outside and another island which is on the inside, which you're presenting kind of like in routing, the static thing that is always available, that menu system. And then the outlet is where you have the inner stuff. When we navigate to the first page, you get both of them together. But now you want to do a route transition to the next thing. If you do a full HTML to the server, you're going to lose your state. But what you can do is send the server a request saying, I actually want to go to the second page, but I don't need the whole HTML. Just send me that little thing inside the center.
00:17:49 - Miško Hevery
That's all I need. And then the server can respond with the HTML just for that chunk, which you can innerHTML and replace. And now you're in this situation where the outer application has already resumed, so it has its state and the state hasn't been destroyed as you navigate to the next page. But the inner one, which represents the outlet of the router, that one was a brand-new app that downloaded, and so it still has to resume because you have to start interacting with it. But by breaking this thing up like that, you get into this nice situation where you get to decide what's more efficient. Is it more efficient to download the code and then execute it all, or is it more efficient to just download the resulting HTML and then resume where the HTML left off? Because it's not just a question of whether it's cheaper to execute here or on a server, because the server can cheat. A CDN can just cache the whole thing.
00:18:37 - Miško Hevery
And so you are sending a request to the server. So it looks like the server is doing work, but the server can just respond with a CDN-cached response saying, yep, here's what you need. You can keep going. I'm not sure if that makes sense, but it is kind of a different way of looking at it.
00:18:49 - Christopher Burns
Yeah, that does make sense. A massive inspiration for Qwik seems to be Builder.io, the company that you work for. How does Builder.io come into Qwik? Was Builder.io built with Qwik in mind, or was it a chicken-and-egg problem? What came first, the product or the framework?
00:19:07 - Miško Hevery
The product definitely came first. Let's do a little overview of what Builder.io is, and then we can see how it all fits in. So you have a problem, which is that you're building a site and you're an engineer, and the creative folks or the marketing folks always come in and they say, you know what, we're going to have a sale, or I want you to change this thing on the homepage, or whatever, right? As an engineer, you want to create stuff. You don't want to constantly tinker with, oh, now the sale is different, this changes, this thing changes, right? There's a lot of content management systems out there that allow you to basically set up levers for the marketing folks that they can play with, and then you as an engineer don't have to go and update this stuff. Oh, you want to change the sale percentage? Let me give you a lever and you can do whatever you want with it.
00:19:45 - Miško Hevery
And then I don't have to be bothered. The problem is that these levers get continuously more and more complicated, right? Like, oh, you gave me a lever to change the sales. Great. But now I have two sales going on. I need a different set of levers. If the engineer designed it around the idea of only one sale at a time, and now marketing says I'll have two concurrent sales, the engineers are like, ah, I have to redesign it and move things around. What you discover is that over time, the kinds of levers you give to marketing get more and more complicated, and in the extreme, eventually you end up with a schema that is so complicated that it is essentially HTML. You basically say, just do whatever you want. What Builder.io is, at first it may look like a CMS system, but actually it's a drag-and-drop editor that the engineer can embed into their website.
00:20:31 - Miško Hevery
And the idea is that marketing wants to change the homepage or the banner page on the top or the hero image or something like that. Instead of engineering always changing it, say, you know what, how about I just give you an editor and you can do whatever you want inside that box. You just knock yourself out. Now, the place where it gets super interesting is that the engineers essentially are giving a sandbox to the marketing people, saying, you can do whatever you want in here, but engineering can also say, I'm going to register a set of components there. So if marketing says, I want to show you shoes A and shoes B, I don't want to recreate the product card for shoe A and B. Instead, I just want to use a component that already exists in the backend, because presumably this component has hovering and clicking and rotating of the shoes or whatever, right?
00:21:16 - Miško Hevery
So you can register components with the system, and then marketing can just drag and drop them and then data-bind to them, etc. In other words, you really are giving marketing a full-on editor to your codebase. And so that's why it's not really a CMS system. It's something completely different, but it's extremely powerful, because at this point marketing decides, I want to run two concurrent sales. Not a problem. You own the box. You can create two concurrent sales. And as an engineering team, I don't have to do anything special or extra. So now they can do A/B testing concurrently and so on and so forth. Okay, so how does Qwik fit into this? Customers have existing frameworks. So they either have a React stack or Next.js or Gatsby or Jamstack or SvelteKit, whatever they happen to be using. And we know how to interface with all of them so that all of this works.
00:22:03 - Miško Hevery
But the thing that we discovered is that people are always worried that incorporating technology like this will make their site slower. While we don't necessarily make your site slower because, at the end of the day, we generate the source code that runs in it, so it's no different than you actually writing it yourself. The problem is, the existing sites are already kind of slow. If you look at the market and randomly look at Nike or Amazon or whatever, you're going to discover that just about everybody is in the red on Google PageSpeed scores, right? Some companies that have money can afford to be in the yellow, like Amazon. Nobody's in the green. No production website is in the green. It's just not a thing. It just doesn't exist. You could say, well, the engineers are just idiots. They don't know what they're doing, right? It's easy to say, but then presumably you're saying, great, but some other engineers are not, and they know how to do it.
00:22:53 - Miško Hevery
But if it doesn't exist in the wild, if a perfectly performant website doesn't exist in the wild, then it's probably not the engineers' fault. If you had sites that were fast and sites that were slow, then you could say, oh yeah, the slow sites, clearly somebody messed up. But if everybody is slow, then it's a systemic problem. It's not a problem of an individual team. Our premise is that actually the frameworks were not designed for this, and they are the ones leading you down a particular path that ends up being slow. What we want is to go to our customers and say, you know what, we have this unbelievably fast way of doing e-commerce. Not only can you fully customize everything you want on a web page, but you're going to be faster than everybody else. This is where Qwik and Partytown come in. Partytown for third-party code, and then Qwik for first-party code, to make it super fast because it's resumable, right?
00:23:41 - Miško Hevery
So the amount of code that you actually put in there becomes faster. You start with a small box on your website saying marketing can own this, and then you realize, oh, that box made the site go faster. So now you make the sandbox bigger and bigger and bigger. And as you make this sandbox bigger, your performance is actually increasing because that particular box can do resumability. So this is the angle that Builder is taking with respect to Qwik. And also the reason why Qwik is looking into ways to know how to interface with React. So if you have a React website, we can add Qwik for the orchestration, but you don't have to rewrite everything, so there could be a bridge between the two. Does that answer the question, or is it too deep?
00:24:25 - Christopher Burns
That perfectly answers the question. I do want to quickly talk about Partytown as well, because this is also something that I've experimented with myself. I've given it a look, and I have had websites in the green in production. It's only when you start introducing all the marketing scripts that the marketing teams want that it gets tanked down from green to yellow to red, because you know you need your Facebook pixel, your Google Tag Manager, your A/B test, your pop-up widget, your 20 different tools. And it's like, just stick another one on the website and stick another one and stick another one. It's like, we've got this new tool, it's a referral program, stick the SDK onto the website, and it just keeps building and building and building. Something needs to manage all of them, keep them all in check, and make sure that they don't necessarily stop the work on the main thread. I think this is actually a really important thing, because then you put all these scripts onto the website, you run your Lighthouse score, and literally the top ten errors are like, I have no control of that, I can't do anything there.
00:25:25 - Christopher Burns
Oh, it says load this script in a different format. How? I'm pulling it off their website. And that's not even speaking about version control of these scripts. Most companies don't even version-control their scripts. They're like, we just host it under m dot website, go get it. The world is completely in this area of web scripts. I've been learning a lot about it. It's just like the Wild West, and UMD script bundles need to just get out. I hate UMD, it's the worst. But I notice on the Partytown pages it mentions Qwik. Is Partytown actually built with Qwik?
00:26:01 - Miško Hevery
No. Those are two separate things. But if you pop up a level higher, again, Builder has customers that are e-commerce websites. For e-commerce websites, speed, how fast can I go and show you the shoe so that you can push a purchase button, determines a lot of your conversion rate. So the faster the better. What Builder is, is we're trying to figure out how to make this thing go as fast as possible. And as you point out, there are two problems. One problem is the framework you're using that wasn't really designed for this. We can talk about hydration and all that stuff, why it's kind of difficult. The other problem is the third-party scripts, and you need to solve both. What I find super fascinating is, let's say you make a blank page that has nothing on it. Of course it gets 100 out of 100 on Google PageSpeed.
00:26:45 - Miško Hevery
Right. And then you add Google Analytics. Well, you're still going to have 100 out of 100, but you're kind of on a precipice now because Google Analytics by itself essentially ate all of the allotted time you have for bringing your page up. So now you add Facebook Pixel. Well, now the two of them together got you over, right? So no site alone, no content, just adding these third-party scripts alone will get you off of 100 out of 100 by themselves. And this is why Builder cares about this. It goes down to our bottom line, which is we want to have a product for our customers that they can be super successful with, and speed is a key thing to it. Partytown basically says let's offload everything we can off of the main thread. Or rather, to step back, it's due to the way JavaScript was designed. JavaScript is single-threaded, so we're in a world where CPU speeds have kind of stalled. What I mean by that is CPUs are getting faster, but not by increasing the clock or by doing more per clock cycle.
00:27:46 - Miško Hevery
The way we're getting faster is by adding more and more cores to the system. So now we are going faster through parallelism. We kind of maxed out what we can do on a single core, but that doesn't help JavaScript because JavaScript by design is single-threaded. What do you do? How do you offload things? All these scripts need to get a hold of this thread. And so Partytown is just a way of getting these scripts on a separate thread so that they can execute on a different CPU, on a different core, and don't hog up the main thread. Not only is it on a separate thread, even if it isn't, we can slow them down so they don't execute all at once. We can say, yeah, yeah, we'll get to you eventually. There's no reason why Google PageSpeed needs to be the first thing loaded, right? I think it's more important to get the page up and running so that the user can interact, and then download and run the Google Analytics or the Facebook script or something of that sort.
00:28:36 - Miško Hevery
What Partytown does is this particular thing: it just moves it over to the web worker. Now, this is not a new idea. Everybody has thought of this. Why is Partytown special? Well, because nobody actually knows how to do this. The idea is simple: move things over to the web worker. What you discover very quickly is that all these scripts need to have access to the DOM. They need to read your cookies. They need to set up listeners, do all kinds of things. Because they're in a separate thread, they don't have access to it. Now you can say, no problem, I can build a proxy and the proxy can communicate between the two sides, except that the APIs for the communication are asynchronous. And so the code isn't written with this in mind. When Google Tag Manager says, what is the title of the page, it expects synchronously to have the answer to that question. If it's running on a web worker and sends a message to the main page saying, what's the title?
00:29:24 - Miško Hevery
And the main page responds with, you know, this is the title. This is done through asynchronous communication. And this asynchronous communication means that it is not compatible with the way Google Tag Manager was written. And so the whole trick of Partytown is that Adam Bradley has figured out a way to make that call in a synchronous fashion. How in the world? Well, there's a lot of hackery. It turns out there are two ways of doing it. There's something called Atomics. They're not quite ready, so they don't quite work the way you want them to work, but that's the preferred way. And the hacky way we have is by exploiting the fact that XHR has a synchronous way of making requests. I have no idea why they put it in there. It seems like a horrible idea, but we get to exploit it. So using XHR, we can make a request block the thread in Partytown, figure out what Partytown is asking for, so in this case let's say it's the title of the page, send it across, and then continue execution so that from the point of view of the Partytown script.
00:30:22 - Miško Hevery
It looked synchronous, and that's the magical part. So we can do that. We can basically take all the scripts and move them over. And if we have done that, we see pretty consistently that you can get about 20 points on PageSpeed just by doing this. So it's a pretty big deal.
00:30:34 - Christopher Burns
Yeah. And we've seen, I believe, it's in beta with it being included into Next.js. I saw that there was a pull request for WordPress performance. And this is something that we over in JavaScript land tend to forget, that there's a lot of websites out there that if they could just install a plugin to get 20% better page speeds, it would save so much energy in the world, so much bandwidth and everything. So it's a really good cause. My other question is going back to Qwik. Something that you said in the beginning that I've been pondering for a moment is that you said the APIs are very reminiscent of React. So does this kind of make it an alternative to Preact? And how is this different from Preact, if Preact is a cut-down version of React?
00:31:18 - Miško Hevery
It is similar. It is not the same. The basic gotcha is that when you have a resumable system, when you can serialize everything into HTML, you can't serialize everything. There's only certain things you can serialize. Clearly strings, numbers, etc. serialize well. Maybe you can serialize objects, but can you serialize a promise? No. And so there are certain things you just will never, ever be able to serialize. What that means in practice is that let's say you have a use state API in React and you push a promise into the use state. You can write it, nothing stops you, but there's no way that this could ever work, right? Because what does it mean to have a promise on a server and then move it to the client? It just makes no sense. So while the API looks very, very similar, it is not exactly the same. And the developer has to participate. You can't just take any webpage where anything goes and put any state you want into the system.
00:32:13 - Miško Hevery
And now the system says, actually there are constraints on what you can and cannot do. I think it is unlikely that we will ever be able to take a pure React application and move it over and just have it run without any sort of changes, but it is pretty close. The other thing that Qwik does, which is kind of different, is that frameworks normally say, I am responsible for rendering. Bundling is not my problem, lazy loading is not my problem, and so on and so forth. Qwik actually goes a step further and says, no, it's not just rendering that is my problem, but the bundles are my problem too. And the reason why this matters is because if you want fine-grained lazy loading, you need to have lots of entry points into your system. If all you have is a single entry point into your system, that doesn't really help with lazy loading. If the main entry point to your system is, you know, hydrate the app or start at the root component and do all the stuff that you need to do.
00:33:02 - Miško Hevery
This will never lazy-load. You need a framework that also helps with creating entry points, because the bundlers can do their job of creating lots of bundles, but they all require lazy entry points. If you don't have entry points, nothing goes. Qwik is actually two parts: one is the runtime, and the second one is this thing we call the optimizer. What the optimizer does is it rearranges the code such that you have a lot more entry points. Specifically in the Qwik world, every single component is an entry point, and every single listener inside of the component is an entry point. Every single use, event or watch or use effect is an entry point. As you are writing your application, you don't think about it. You just kind of write your API the way you normally would, but you're actually creating lots and lots of entry points for the system. These entry points are what allow the bundlers to have this property so that the system can say, oh, this component doesn't have any listeners.
00:33:53 - Miško Hevery
It's a static component. It will never rerender on the client. How do I not include it? Well, you're not included because the bundling system already knew how to cut it out. In a normal React world, let's say you have a top-level component that is static because you have a bootstrap that says, hydrate starting at the root. The root and everything below it has to come along, right? There's no way to just be like, oh yeah, these three over here don't matter, it's only the children that matter. There's no way to do that. So the mental model shift here is that Qwik's job is not just to be the runtime and the DX, but also to think about the server and think about the bundling and think about how you make all these things happen. This is why it's so hard to talk about Qwik, because people are like, oh, well, I know React, Angular, and Svelte and Vue or whatever, and they're all fundamentally the same in the sense of the envelope of what they care about.
00:34:41 - Miško Hevery
And because the envelope is the same, you're like, oh, the DX changes, it's a different way of doing the same thing. It's like, no, no, no, no, no. Yes, the envelope you're used to is about the same, and it's probably the closest thing to React. But really you need to step back a few steps and not just think about the DX of building it, but also think about how you bundle it and put it together, and figure out which part needs to be downloaded first and which part needs to be done later. All of that stuff together is the thing that now Qwik is. It's a different thing, and the client-side rendering is just one part of the whole thing.
00:35:13 - Christopher Burns
I think, yes. I guess my last really big question about Qwik is, where is it today and what is the future? Is it going to be just a framework, as in the React, or will it expand to be the Next.js that obviously includes all the other kinds of things around it? We spoke about all the things Qwik can do really, really well, but how can that also influence other frameworks? And would you like to see some of Qwik's features shamelessly ripped off in other frameworks?
00:35:45 - Miško Hevery
Copying is the best form of flattery or something like that. I butchered it. I think Qwik is very, very different. And not just... it's different, it solves a particular need. If you're an e-commerce website, you want to be faster because that is a huge amount of revenue that you're foregoing, and you're putting pressure on your engineers, but your engineers...
00:36:03 - Speaker 4
are like, oh, this is the best...
00:36:04 - Miško Hevery
we can do. We don't know how to make it faster because our frameworks are not helping along the line. And so we are in a situation where everybody's website sucks equally bad, and so it's a stalemate. Now imagine Qwik comes onto the scene and says, actually, if you build a website with Qwik, it's about the same amount of work, but you can pretty much get 100 out of 100 without much effort. It's a huge thing, and it will change because, from a business point of view, if your competition is building using Qwik and you're not, they're getting fast scores and you're not, and then Google search engine optimization says, if I have two companies both selling shoes and everything else is the same about them, I'm going to serve up the one that has a higher PageSpeed rank because that's going to be a better experience for the end user. So now you have huge incentive on the business side of things to be like, yo, we need to get our site speed to go up.
00:36:58 - Miško Hevery
We are in a stalemate because nobody knows how to make it faster. The moment somebody can break through the barrier and figure out how to make it fast, all of a sudden you have competition going on where you try to figure out how to get there. This is the thing that I'm really hoping Qwik will spark. Now, will other frameworks be able to do this as well? I don't want to speak for other frameworks. I don't know what they can and cannot do. But my opinion is that it is not something you can bolt on after the fact. My opinion is that if you wanted to get resumability into existing frameworks, you would create such huge breaking changes that you would, for all practical purposes, create a brand-new framework, because you're going to be creating a brand-new framework, right? It's going to be a hard sell to do that because all of a sudden the ecosystem doesn't come along and so on and so forth. While I would love for others to go and shamelessly steal whatever Qwik is doing, I don't think it's going to be as simple as people think.
00:37:52 - Miško Hevery
And I love watching Twitter because people are like, hey, we'll add that feature next quarter. I'm like, no, you're not. You haven't thought about what the implications of this particular thing are, because it is not as simple as you think. But anyways, yes, I would love them to all get there. I feel like there was one more question that I forgot to answer.
00:38:06 - Christopher Burns
The other part of the question was, where does Qwik end and potentially another framework can bolt on? Almost like React and Next.
00:38:14 - Miško Hevery
Ah yes. So we're actually looking into this right now. So Qwik is kind of like React in that sense. That's a good comparison. But again, the difference is that Qwik worries about the server-side rendering, the bundling, and all the other bits and pieces that React basically says are not our area of concern. But you still have the problem of routing. This is the routing we kind of talked about, what we can have. So if you look at something like Next that's on top of it, and most other frameworks have something similar, I think Qwik will have something similar as well. We're calling it right now Qwik City. And it is this idea of having a framework and a renderer and specifically the router, where you start as an application and seamlessly transition into a SPA without the developer having to do anything. The idea is the developer writes their code as they always have, nothing special about that, and yet the emergent property of the system is that they're going to end up in a world where they start as an MPA app and immediately transition to a SPA.
00:39:12 - Miško Hevery
What that really means is that they start as an MPA, and when they transition to a separate route, they get to keep their state. They don't get to blow away the state that they had. And that's really what it comes down to. That also means they can do transitions and animations and all the other stuff with it. So yeah, Qwik City is the next thing to work on. It's already checked in. It's not yet made public, but it is the thing that drives our homepage for Qwik. It doesn't yet do the transition, but it's the next thing on our list. And containers are kind of the magical part in how the whole thing comes together.
00:39:43 - Anthony Campolo
So I noticed you also have some starters. Do you think those would be good for someone who's totally new to the framework to kind of get going, or would you point them to like, kind of read the docs first? Like, what's a good kind of entry point?
00:39:54 - Miško Hevery
No, I think the starters are the perfect place. The starters are the place to start, and then go check out the getting started documentation, etc., and then go from there.
00:40:03 - Christopher Burns
I don't have any more questions right now. I'm sure Anthony has loads, and he could talk about the past all day as well.
00:40:12 - Anthony Campolo
I thought that was really good. You have such an awesome perspective on the whole history of the web. It's been really cool talking about these ideas, because it's a lot like when we have people like Ryan or Dylan on, where they've been in the guts of the APIs and the browser and the frameworks and the applications and how all that fits together. So I think this is really exciting. I'll be curious, do you know anyone who's created a full-stack project with it, like with a database?
00:40:40 - Miško Hevery
No, it's something we're working on. With Qwik we are still very much in the early phases, but we do have, for example, the Builder.io website served by Qwik, and it is one of the places where you can demonstrate, hey, before the best we could do was 60 out of 100. Now we can do 100 out of 100 on this particular homepage. And this is a real homepage, right, with analytics, Intercom, HubSpot, and all the other good stuff that you need for having a real site. But yeah, all the other pieces are coming. Not there yet.
00:41:06 - Anthony Campolo
Awesome. And then are you doing like, community building efforts around it as well?
00:41:11 - Miško Hevery
Yeah, we have a Discord. I'm going on a tour actually this summer through lots of different conferences. We're going to be talking about that. The main thing I want to do is really build up awareness that the way we are building sites isn't working, and there are better ways. And not only is it not working, we are in this really strange world where when the site is slow, we blame the developer even though they had so little choice in this. They had to use these third-party scripts, they had to use these particular frameworks, and so on and so forth. Really the only thing they got to do was put in the content, and yet now it's slow and it's their fault and there's nothing they can do about it. My other favorite thing is you go to Google PageSpeed and you feed it your site, and the website says, you know, download less JavaScript. I'm like, gee, thanks. That's great advice. But what exactly am I supposed to do to download less JavaScript?
00:42:02 - Miško Hevery
Right? All these frameworks eagerly require JavaScript to be present. Third-party scripts require JavaScript to be present. We all know what the problem is, and yet we have no way of influencing this.
00:42:12 - Christopher Burns
And it's not only that, we'll be putting a lot of web agencies out of business. They'll no longer be able to say, I can beat the previous agency's page scores.
00:42:20 - Miško Hevery
Well, that would be a good problem to have, right?
00:42:22 - Speaker 5
A very good problem, for sure.
00:42:24 - Anthony Campolo
Is there anything else you'd like to let our listeners know before you sign off, and then let us know kind of where your socials are as well?
00:42:31 - Miško Hevery
I think that's it. I'm heavily on Twitter. QwikDev is the social handle on Twitter for the Qwik project. Builder.io is the website where we create the cool way of doing content management that really empowers the marketing people so that the developers can focus on the cool bits of making the actual interesting sites rather than endless A/B testing and changing of your sales and so on and so forth.
00:42:55 - Anthony Campolo
And here's a teaser for likely a future episode. Your company has built another framework. Is that correct? Called Mitosis.
00:43:01 - Miško Hevery
Oh yeah, Mitosis is, right, the secret sauce, how we generate the editor for all of the frameworks. Because if you're using React, we have to give you a React component. If you're using Angular, we have to give you an Angular component. If you're using Svelte, we have to give you a Svelte component, or Qwik, right? And so that would be completely unfeasible for us to write all of these things by hand. Instead we have Mitosis, where we get to write the components once and they get generated for all the different platforms, which is kind of mind-blowing. Basically every single framework is supported by it. And this is how, as I said, we can interface with our customers. Our customers can do any framework they want and we can just interface with them.
00:43:41 - Christopher Burns
That very much seems like a dream. As I said, building your own SDK, if that's something you've never done, it is interesting when you have to start thinking about how X plays with Y. Like 95% of the time, your React SDK is going to be a lot different from your standard JavaScript SDK. And that's just today. If you want to build components out in their native framework of choice, like a model in Vue, it's completely different from a model in React. So it's something that could actually bridge the gap. If you just write it once and it runs everywhere, that would be very exciting for sure.
00:44:14 - Miško Hevery
Not that it runs everywhere, right? It's that it generates the code for the other place. So it's not like a least-common-denominator thing. It's the actual code that you would write by hand.
00:44:24 - Anthony Campolo
Well, thanks so much, Miško. I really appreciate having you here. Hopefully we'll get a chance to talk again.
00:44:28 - Miško Hevery
Thanks for having me. Anytime.
00:45:00 - Anthony Campolo
Sweet and good.