Qwik and JavaScript streaming with Tony Alicea === [00:00:00] Hello, and welcome to PodRocket, a web development podcast brought to you by LogRocket. I'm Noel, and today we are joined by Tony Alicea. Tony's a Udemy and Pluralsight instructor, director of education at the Smith Group. He's here to talk to us about QUIC and JavaScript streaming at large. How's it going, Tony? Good. How you doing Noel? I'm good. Yeah, ~this is a, ~this is an interesting one. I feel like QUIC is on some people's radars a little bit, but there's not a lot of people like jumping in super deep and checking it out yet. I'm curious to hear you advocate for it and convince us why we should be checking it out. Maybe, yeah, let's just jump right in. Can you explain we mentioned JavaScript streaming. Can you explain what streaming is and how that fits into the way that we deliver? Code to the front end traditionally. Yeah. And when we talk about JavaScript streaming, it's a metaphor because when we think about streaming technically, we're typically saying, okay, we have some information and we're feeding [00:01:00] it to you piece by piece over a period of time, but it's usually continuous. So like you watch a video and you buffer the stream and the stream is coming and the bits are coming in. The broad concept is that you're not consuming everything at once. You're not downloading the whole video. You're getting pieces at a time as you need them. So the idea of streaming JavaScript is not that we're going to thin piece by piece, like line by line, but rather that we're only going to give you the JavaScript that you need or may need. At the moment that you need it or right before you may need it. That's the idea. How is quick unique in this regard? Because it feels like we're hearing this story across the board with like selective hydration or partial pre rendering or all these other tools that are coming out, like this is the same thing that they're trying to bite off what is quick doing differently. See, that's what's interesting. Yes and no, when it comes to the same thing and I think as we talk [00:02:00] more about the details of quick, to give it a general overview, if you think of a stream as a hose, we're shooting JavaScript to the client and saying, download this, execute this, what most of the other technologies out there, like islands or react server components, it's almost more like water balloons. They're saying, here's all this JavaScript. And when you need to throw it at you, boom, you get all of it. And historically, when we've tried to limit the amount of JavaScript going to the client, it's also in involves a lot of developer. Intervention. I'm going to bundle these together. We're going to split the code that I download on the routes. We're going to hydrate an island when it's needed, but it's still this idea of we're separating and thinking about it, right? We're consciously thinking about all this. What QUIC is doing is saying we're going to break down the application into these really small bite sized chunks, which [00:03:00] are basically responses to interaction, that's most of what an app is, right? We're either delivering content or we're interacting with it. And so the idea with quick is that this is all automated. You write code, it's split up for you and it's delivered or prefetched as needed according to the interaction. The baseline I like to think about is most of the time we're talking about JavaScript frameworks, we think in terms of The server and the client, and we think of them as two separate systems. For example, Hydration is we're going to run the components on the server, generate HTML, and then we're going to run the components again on the client, execute the same code, figure out where the HTML is compared to the components, get all of the event listeners up so we make it interactive. We treat it very much as two disparate systems. With QUIC, the way I explain it, is that you think of the server, the client, and the user as one complete system. So [00:04:00] the server delivers something, the client deals with interactivity, and the user is making choices about actions, what they need. So if you think of it as one complete system, hydration would be, I'm going to run code twice inside my system. Which doesn't make a lot of sense, if you really think about it. But what QUIC is saying is we're only going to Run code once with something they call resumability, and we're only going to grab the code that we need based on the choices that the user is making at the event level at the application level. What am I actually doing as a user? If I load a page and I never do anything, I shouldn't load a ton of JavaScript, right? That's the idea. Or if I have a big dashboard, And I have 27 widgets. I should only load the widgets that I see on the screen or if I actually ~click a button ~in Eastern Iraq with, I should only be pre fetching those things. I shouldn't be pre fetching the JavaScript for three clicks away, right? Because I don't need it. I might never use it. I need convinced on [00:05:00] resumability and like how this magically works because I think the first thing that pops into my head, how do we know what the user is going to interact with on a page, because like , one could argue that we're hydrating everything right away because we want to make sure that when that click occurs, we are ready, right? Like the thing that is supposed to happen happens extremely quickly. How does this kind of resumability concept solve that problem? And is there any trade off there? I think a fundamental difference between what Qwik is doing and everybody else is doing is that Qwik sees the DOM and HTML as a messaging system, as a way to transfer information, right? We avoid the DOM and a lot of other systems. Like it's a behind the scenes thing and don't think about it. But with Qwik, what Qwik is saying is, hey, HTML and the DOM is actually Metadata, right? That's its whole intention. That's what it's there for. So why aren't we using it? So once you say, okay, we already [00:06:00] have a messaging system between the server and client. It's HTTP and we're delivering HTML. And we already have this object structure in the client that can hold information called the DOM. We can take advantage of that. So with Hydration, we're saying, I'm going to give you all the code. And you're going to run the code again. And with RoomZoomAbility, we're saying, I'm going to give you the information that you need via the HTML to know what pieces of the HTML map to what component. And because of that, I never need to load all the components to figure out which piece of the DOM belongs to which component. So if I don't need to do that, I can just say, here's your HTML. And what Quick has, they have something called the Quick Loader, which is basically a global event listener. So that's, you get one event listener added. It's a, it's one kilobyte of code. You don't even load the entire Quick framework until you actually start needing to do something. You just [00:07:00] say, here's your code. Here's an event listener. Now, what do you want to do? And then when you click on something, at that point, now, you have resumability because in the DOM, is information about, oh, hey, this belongs to this component, so now I know which component to go grab. Or, usually, in reality, in production, ~what they, ~what Qwik will do is it'll say here's all the possible interaction points at this moment. It will prefetch, not execute the JavaScript, just download it or get it from cache. And the reason that's important too, is I think it's again, it's including the user in this concept, right? Because what happens, we get this load and now the user is pondering what to do. A human does not behave in terms of milliseconds, right? It's not three milliseconds until I figure out what I want to do. So there is a buffer window in the system to prefetch. What might need if you include the user in the system, so we say, okay, here's a page. Here's [00:08:00] what's visible. Here's everything they could possibly do right now. I'll prefetch meaning download or from cache. But I'm not going to execute, because execution is more time, execution is more battery life, execution is more load on the client. And when I click on a DOM element, like a button, I already know, because of resumability, which component it belongs to. And then, I can then execute that particular component, which has already been prefetched, which is extremely fast. Because we don't have to do the HTTP call. And you can also bundle these prefetches together. So it's not like 30 different prefetch calls out.~ out.~ Quick is going to bundle them together and say, Okay, here's what you might need. Grab it. And resumability also allows something which is really impressive and changes that idea of server client boundary because it serializes closures as part of the resumability. Meaning that if I have a on click function and it references a variable that was set on the [00:09:00] server, right outside of itself, which is very common, like increment account, right? The count is outside set on the server somewhere and the click event is updating it the javascript is loaded. In the client, but then a different piece of JavaScript, the onclick event is loaded, and that is a closer reference. The problem when you lazy load, the problem when you load these JavaScript files separately is you lose closures. You lose access to information of other variables in the other JavaScript files. So what Quick does, it says, we're going to store those closures in the DOM, In the information in the HTML being sent back. So when you load a component, you do a click and it increments a count. Even though count was loaded as a separate JavaScript file, essentially, it behaves as if it was all one JavaScript file. And the cool thing about that is that it splits your code for you. So you get the benefits of the code splitting, but you can write your code as if it was one JavaScript file. And that is very unique. And that [00:10:00] breathes all of this power, because then you can even have these interactions across the server, across multiple files on the client, and you, the developer, don't have to add mental load, add a mental model, add foot guns to these ideas. You're just saying I'm writing code. And quick is handling the performance part for me. It really struck me and interested me because I've always felt, and I've been doing this for a long time. coming up through, vanilla JavaScript and all these things, all these steps that we've gone through jQuery and knockout and all these things. And quick, I feel is taking lessons from all of that and saying, if we were to start over from scratch, hindsight is 2020, knowing that we want to not download all this code at once, knowing that we want to render on the server sometime, how would we do that without asking so much of the client without downloading so much code, without causing so much network activity, all those things. Yeah, so resumability is [00:11:00] essentially, I don't have to load the framework. And all of your code again to figure out what I'm supposed to do in the DOM. That information is in the Dom and then we go from there. I want to circle back to the convenience of not having to think about closure and encapsulation and all that stuff. But let's stay on this point. Is there like talking about like being able to take all these learnings, all this stuff we've figured out over 15 years of web development and frameworks and stuff. How is this actually benefiting? The user, what is the difference in a quick app? Not the developer, but as a user, how does it feel to use a quick app versus something that's. Like rehydrating, like a server side rendered React app. Yeah. I've spent part of my career as a user experience designer. So this is a high interest to me and accessibility Part of user experience is understanding that the average user is not on a developer machine running on a fiber network, Right? You can go to, whether it's a [00:12:00] developing country, whether it's rural United States the processor speed, the battery life. The internet speed is wildly divergent, right? So for saying user experience to my mind, I've worked in that arena for such a long time. I think all users, right? Not just some subset on some high speed connection. So for the, especially for those users, there's the impact of one, the immediacy. Of the initial load because we're not hydrating, we're not running code and hydration can range, right? If you have very little JavaScript code, then maybe your hydration doesn't take very long, but if you have a lot, it's going to take longer. So the scale is to how much code that you're writing. So let's say I build a quick app that has A lot of interactivity on that initial load. The initial load is the same no matter what. It's 01. It's, here's your HTML, here's your quick loader, which is one [00:13:00] kilobyte of JavaScript with a listener, and that's it. It doesn't matter how much JavaScript code you have on that initial load. Any load of any page is going, that initial load is faster, quick often shows off the lighthouse scores. Unquick applications, because they're just like 100, 100, 100, 100. Why? Because you're not loading any JavaScript, barely. Then for the user long term, over the life of the application, if we think about the app from a user experience designer's perspective, an app is a graph of interactions and responses. I click a button. Now here's the new page or state of a page that I'm in, et cetera, et cetera. And I work my way across that graph. I may come back in a circle. So in most applications, in most systems, even the ones that are trying to limit how much JavaScript is loaded, the user, if you look at the totality of how much network bandwidth am I using, How much battery life have I used? It's a function of routes. Usually it's these big groups of graphs, [00:14:00] including ones that I never touched a quick app. If you go back historically, someone starts the app and ends using the app. You're basically going to see a line with little prefetch branches of just the things that they did. So piece of the graph that's been downloaded is much, much smaller. Now what's the impact on users? Well, In some countries, we can stretch it along, right? For your average user, let's say in the United States, it's faster, less battery life. If you're not on an unlimited data plan, you know, it's less data. Uh, It's less intense on your machine. And it's not because of anything the developer thought about. It's just because they use Quick. In other countries. paying for internet is much higher cost. It just gets worse and worse for people depending on where they are in the situation with the internet. So somebody's on a four year old Android phone on 3G that they're paying for. This is a massive difference, right? So it's beneficial to, across the board, ~and the ~Depending on [00:15:00] your situation and what country you're working in and who your customers are and all that the benefits just. Rise over time I think the second point is a pretty easy one to argue in that in most react apps, there's a lot of that. Like you end up , executing a lot of code regardless of how quick That initial load is. I am, curious more on your first point there. you pointed out how the hydration step is expensive and all that stuff. But I imagine a lot of react developers, especially ones that are thinking about this and this is where they spend a lot of their time. They're like wait a second. Like in my initial load, I'm just sending HTML and CSS, maybe a little bit of JavaScript that starts kicking off the hydration process. So my initial load shouldn't be that much slower. Is there anything to that argument or is this mainly in the case of react apps that haven't gone through all of this process to, get them highly optimized yet? in the end, the cost of hydration is about how interactive your app is. So even with react server components which is the big talk and I'm, I'm not here to say all these other frameworks are [00:16:00] bad, I'm teaching react currently It's not that, but the reality is react server components. When can you use them on things that are interactive? If you're making Facebook. Great react server components can be awesome for you because all that text, all those images, you don't have to do the hydrate. You don't all that's a great. But if you're making a dashboard, there's a limit to how much react server components are going to be useful to you. So oftentimes on the Internet, we argue without context, right? So a react dev making a static web page might argue. I have one button on this page and my hydration is not a big cost. Okay. Maybe in that case, but guess what? You're downloading all of react source code just to make that button work. And that's a lot of source code. We've kind of normalized the idea. of how much I have to load just to make a button work, right? So there, there is a cost there. But~ if you~~,~ as you add [00:17:00] interactivity to anything web page wise, most of these other solutions, like react server components, like islands, their effectiveness drops, the more interactive things become. And that isn't happening with quick because there is no hydration in the first place. So I think it's a fair point for some, let's say somebody's listening to this and they're like, I worked really hard on this and I thought carefully about my network structure and I've optimized everything and it's working really fast. Great. I'm so sorry for you that you had to do all that work just to make something fast. You shouldn't have to. These are tools. We've added these layers of abstraction to HTML, CSS and the DOM JavaScript engine. That's it. We've added all these layers of abstraction and we've pulled ourselves so far away from it that we've normalized things that if we did it manually would seem inefficient and would not make sense. If I was doing this all from [00:18:00] scratch, pure vanilla JS, all right I'm going to do it on the server, and then I'll run it again on the client, and I'll download all my code again on the client, and if we were writing all that, we'd be like, there's got to be a better way to do this, but the reason it is because all of these approaches react is was the spa days when everything's a spa, right? So now we want to do server rendering, and we're doing it on systems that weren't designed for it. Hydration is glue, right? So I can force something to stick together that never was designed to stick together. And if we were starting over from scratch, I don't think we would invent it. I think we would figure out something else. And that's, what's interesting to me because the question has been, what is the something else? And resumability, I think is a very compelling answer to what is the something else? The point you mentioned there, which I want to dig into a little bit is like the empathy you feel for these devs that like to create, it feels like now to create a rack react app that is highly performant. You have to be very [00:19:00] conscious of it, like at every step of the way, right? Like it's a lot of work, like instrument, everything. Do you think? That is in the same vein and this is the best possible outcome based on the foundations of react. This is just going to be how it has to be. Or do you think that we'll be able to get to a version of react eventually that kind of feels more like this? Or do you think that we do fundamentally, we need to rip off that bandaid and there's framework changes that need to happen. Yeah, in my preparation for when I'm teaching react right now, I went through all of react source code, which was like a fun exercise, right. and to dig through everything so I could explain it. And it's fundamental to react, it's fundamental to a lot of these JavaScript frameworks, they are designed to even react server components. Let's say, for example, people will say, Oh now we could think server first. No, you can't. Because how maybe on the initial load, it's HTML. But if you rerender a server component, what happens, it's delivering this payload to the [00:20:00] client, To allow the react client to complete reconciliation on the client side. It's fundamental to react client side Basically react server components are saying how can we render on the servant partial server partially? And then continue performing reconciliation like we always have On the client. So it's still shoehorning in, right? And that's not a criticism, because how else are you going to do it? You're dealing with the fundamentals, right? And yes, it's beneficial. But if we were to start over, would we do it that way? So I think that, yeah, with React. You're not going to get resumability and react easily. Like you're not going to get server rendering and client rendering that doesn't involve hydration easily. The entire fundamentals of the system is here's my react elementary, and this becomes a fiber tree and I compare it to the dom. And now I know what updates I make and that's it. And top down, that's one of the things people loved about react. it's one direction is top down and I see what's happening. My components are updating and that, that was [00:21:00] great, but if now we're saying. Oh, we need to make it more performant, which is really what happened a few years ago, right? With all of these, all the frameworks realize we're actually slow, Yeah. Yeah. need to render some things on the server. And then everybody goes, now we're going back to PHP. It's both, right? It's, we need some things on the server and we want some things on the client for good reason. But now I have to me, the developer, I have to swap my mental model hat. All the time, right? Wait, is that a server problem? how do I make that faster on the server? Wait, no, that's the client. How do I make that faster on the client? A real abstraction, which is what a tool of framework should be hides the details from you and lets you reason only on the things you really want to reason about. So I always say a steering wheel on a car is an abstraction. I don't reason about how the wheels turn. I reason about should I turn left here? That's the only thought process that I have. That's a good abstraction, but what if I had to go, okay, but in order to turn left [00:22:00] first I have to prime this thing over here so that the, Oh, that gets some oil onto those gears. And then I have another button. Okay. I want to make sure these gears connect right now. You're adding all of this stuff and to get really good at it. Now I have to make, I have to do the timing really well, and I've worked for five years on this. And my timing is amazing on turning left and my gear ratios are amazing and great. But should you have to do that right? It's a derivative of the fact that we're doing things that the frameworks weren't meant to do from get go. And if we could say, Hey, the frameworks are meant to do that from get go, we could end up with the steering wheel. You've touched on something interesting there and that devs like react feels good because the mental model is relatively simple, right? Like it's not that hard to jump in and start doing. Do you think that we getting into this performance optimized development experience? Do you think that we're saying it's necessary to have a little bit more. Control yielded to the developer to like make these decisions. Therefore we need new abstractions. Is the problem that we're trying [00:23:00] to fly airplanes with a steering wheel now, and we need to be like give somebody something else. Is that what's going on? I think that's a good illustration. Whenever the model starts to get leaky It's a sign that there's a problem, right? And now we have leaky abstractions everywhere. Once you've added the server to the model. empowering developers to think about apps instead of performance, we all only have so much mental, emotional, and physical energy. As people, as humans. So I'm doing my job. I'm devoting mental, emotional, and physical energy to getting this app built. The more I have to devote to performance, when the UX person comes and says, this isn't very accessible. I'm like, Oh, I don't, I'm not going to have to do accessibility too. Oh, I don't want to think about picking my HTML elements. Just do divs, man. I don't want to think about CSS. Oh, it's not because. All devs are uncaring about accessibility. It's because they're loaded [00:24:00] down with just getting it to work well. So if we can offload. All of these plates that are spinning that a dev has to figure out. Now they begin to be able to focus on the things that I think a dev should really focus on if we're using a good abstraction. Implementing a good user experience code that's easy to read and maintainable accessibility, making, thinking about all of our users the future devs that are going to have to work on this, how can we make that easy, all these things that we would rather think about. And, maybe some folks enjoy the performance to me, you might get an endorphin hit from that, right? Like I made those little adjustments and I feel good about it and that's fine. But if there's other sources of that as well Hey, look, I just made this accessible. And this person over here can use the website so easily. That was really cool. We watched the usability test and then bam, they clicked through and hit the checkout button, twice as much as before, because I made this work so well, there's lots of ways that we can get [00:25:00] value from what we do. And sometimes I feel like the pushback sometimes it's because people have invested so much time and energy in learning something that now they're getting value from being good at it. So if you're getting good at figuring out performance, you might actually emotionally be like, ah, I'm good at this. I can make this work. It's okay, great. You're a smart person. It would be great to apply those smarts elsewhere. If that makes sense. I think that there is something to that argument. I think as devs, even as much as we like to talk about how much we like to research and study and focus on change, there's still the eh, I don't want to learn the new thing. There's mental cost due to stepping into a new framework. Talking about the burden on devs. Yeah, it can be tough. what does quick ask of the developer, like if they're a reactive, they're super, they've got it all figured out. What do they have to question and relearn and, reconfigure their assumptions about if they're switching to something like So I really enjoy what quick has done about this because react is so embedded in the ecosystem, right? You have things like solid, which are just, if you're in react, it's pretty easy to move to solid. [00:26:00] So quick followed , that same mindset quick. Components return JSX, under the hood, it's not going to be the same as react, but from a developer standpoint you're writing components, you're returning JSX. It's a very similar experience. Quick uses signals similar to solid. So that's also a familiar experience. Quick has these things they call quickifiers. So let's say you have a react app. You can pull your react app, wrap it in these quickifier functions and essentially turns react component into an island and you can actually communicate across the island. So what you can do is say, you know what this piece of my app, we're going to start in quick, but I already have a bunch ~of ~written in react. So I'm going to quickify my components and react, get the benefit, at least of that initial, it's not as fine grained as quick is because quick will go down to just like the click event functions and things like that, but you're getting some immediate benefit. And then over time, now you have the ability to piecemeal move your components to cost. So the upside is. [00:27:00] All of that. It's actually pretty easy to jump into QUIC if you're used to React or you're used to Solid. The mental model shift, I would say, is serializability of things that are across the client server boundary. So if you have something you're capturing in a closure or in some way with the code that you're writing, because the code that you write in QUIC You can have the server and the client code in a single file, right? It's not like you have to have all these different pieces and say, which one's the server and say, what's this one? The client, you have a server dollar sign function. Okay. That's going to be a server. This is going to run the server, things like that. So you do have to think about if it passes through HTTP at the fundamental technology, we have to be. Able to serialize it to something that can be sent as text, right? But funny enough, the same is true with react server components. Like you can't pass props between client and server in react server components that aren't serializable for the exact same reason. So this is just something that devs are going to have to [00:28:00] learn anyway. If they're spa devs, they came into the industry, just building spas and they're not used to servers. Everybody's going to have to think about that, but it is something you have to think about with quick. I wanted to circle back to that closures thing. And this was the kind of point that I was going to ask about, is this sounds neat and great if we don't have to worry about side effect weirdness and state and stuff like that. But then my question is is that not error prone? Are there not problems that can easily be stumbled into? And is serializability really the big thing there that one's got to contend with? I think serializability is the big thing. Now quick does serialize things that the browser doesn't natively. So they have tried to serialize as many different things as they possibly can. So it actually is more than you might, if you were just doing vanilla JavaScript, which is really cool. As far as like easy errors. I can't say that I've run across anything that made me think, man, I really had to have my mental model straight. And ~I~ I don't understand this. That happens more with things like React I like to say you should make it hard to do the wrong thing and [00:29:00] easy to do the right thing. Like you should accidentally fall into the right path. It should be really hard. I've done, a lot of work in a lot of frameworks. A lot of frameworks have a very broad API where you really need to understand how things work under the hood to not hit a foot gun. I feel like Quick, because it's abstracted that server client connection in a really clever way, you tend to be able to write code more the way you normally would at a very simplistic JavaScript code than you would otherwise. So I think on balance, at least in my experience, I'm less prone to do something weird, right? I'm more prone to just say, okay, this is happening. I'm writing this and quicks encapsulate this for me. The only thing I would say is that everything in quick is asynchronous pretty much. So that means they do have a couple of caveats and they have tooling for that canceling the default [00:30:00] behavior of a click, for example, because everything is loaded asynchronously. That's actually problematic. So quick provides a way to do that. That may not be standard to what you're used to. That's in their documentation. the two areas is because everything is lazy loaded or lazy executed is really what quick likes to say because they load prefetch and they execute As needed, right? Gotcha. Because everything is lazily executed, you are going to have synchronicity things that you do, you might run across and serialize ability. I would say those are the two big things. But people that I've talked to who are building apps and quick, their general statement is I got things running so much faster. Like I just Hit the ground running and built stuff. And I think that's due to it actually, in my opinion, being a good abstraction. I've been asking a lot about what makes it difficult to make the switch. If one does make the switch, what are some cool things that like one just gets out of the box [00:31:00] easily beyond what we've talked about already or with very little work, like what are some cool benefits to this abstraction that quick brings to the table? If you go online, you can find quick demos, right? Of things like only loading the JavaScript when the component comes into view. If I never scroll down, I never load the JavaScript. Like you don't have to think about that. You don't have to write any code for that. It just happens. So that's really cool. One thing that is super fascinating. Is what they're calling quick insights. So me as someone who straddled the developer and user experience line. That communication and thinking the same way. user experience designers are thinking one way about an app. Devs are thinking about another way about an app. And making that communication is hard. I work for a company called the Smythe Group. the UX and the dev folks do really good job, But it takes a lot of experience to figure that out. I've worked with a lot of dev teams and UX teams, and we go out and work with those teams where how do they interleave? Okay. So quick insights says, look, as people are moving through this graph of actions, [00:32:00] we actually know. Like analytics. We know what bundles have been loaded. The bundles are named uniquely. We know what the bundle, the component is in. And then I can then say, hey, 90 percent of your users load the bundles in this order. When they click this button, 90 percent of the time the next bundle is this code, and that code. So guess what? We're going to bundle all those together on the prefetch for that particular button. So now my dev concern lines up to my user experience concern, which is what the UX designer would call the user flow. What is the series of things and where is it problematic? Is it problematic because it's slow? Is it problematic because it's confusing? Oh, hey, this is a really popular path. How can we optimize that? How can we optimize that from a usability standpoint? How can we optimize that from a dev standpoint? So this idea that when you break down your app code automatically into these [00:33:00] chunks are part of the response to what the user is doing. You can then reverse engineer what the user is doing and optimize your bundling according to every individual choice the user makes. And you get that out of the box. And I think that's really cool. Nice. How does that work? Like with your host, how has that analytic data ~like ~sent up to then inform that bundling decision? Cause presumably there's some server logic that needs to happen to make this tick. Yeah, so quick has an option where you can do it manually, and then they're also providing a service. It's still early days, but the long term idea is that you will be able to host quick insights on different platforms and then be able to make those adjustments that for example, if you're running quick by a Viet. you can see all of your bundle names and you can say, I'm going to pull these into a single bundle. And then it's like a configuration setting that you can do. Is that analytics step or like the optimization of those bundles? Is that happening in real time? Or is that like happening at build time based on [00:34:00] telemetry data? That's been sent back historically. Yeah, so it's happening at build time. That's my understanding anyway. So it's not something you're going to do when you initially release. But this is very true. And this is why I say it ties the devs to the user experience designer. The devs, it's now working and I'm going to walk away from the app. And now the user experience designer is saying, Oh, please, can we go fix that usability problem? Instead, the UX and the devs are both interested in how the users are using the app after the app is released for optimization and performance. Now they both can say, hey, we watched this usability test, and everybody goes this direction in the app. Is the bundle telling us the same thing? Yeah, okay, we're going to work on this and the dev can Update the bundles. And it's just a more unified experience I find for post delivery. That kind of then brings me to my last real line of questioning here is how are quick apps typically hosted? What are the requirements here to get this kind of server side, client side streaming thing that we're talking about working? Yeah it's pretty much, they have [00:35:00] adapters for, different hosts, Netlify and et cetera. But really you need JavaScript running on the server and JavaScript running on the client. And that's really it, because the optimizer itself that is breaking up your code because you're writing your code and then there's a rust application that's written in and rust that goes and. analyzes your code, breaks it down, but what's actually delivered from the server is just the JavaScript that's running. Cool. Awesome. We've covered a lot. Is there anything else you'd implore? Listeners to go investigate on the quick side. Like how would you tell people to jump in and start exploring? Yeah, good question. I would hit the documentation. in the documentation there is a whole section where you've got videos and podcasts out there that people have talked about React. I have ~a~ a video on my YouTube channel where I explore how it all works under the hood. How the optimizer works and everything else to get a good mental model of what's actually happening to your code. There's a playground that you can go look at [00:36:00] and see what happens to your code, what the bundles look like if you go to Quix documentation. So documentation is a great start. They also have a great discord. I'm active on it. Where, you can ask questions and guys like Misko Hevery and other guys are out there answering questions. So yeah, it's a pretty cool spot If you're interested and have some questions to ask. Cool. Awesome. Is there anything else you'd ask people to check out that you're working on or Sure. Yeah. You can head to my website, anthonyalisea. com. A L I C E A. I've got a new course on React, funny enough. We're at understandingreact. com where we dive into the source code of React so we get a proper mental model. And you can check out the Smythe group, which is where I work with smythethesmythegroup. com for all the things that we do for dev teams and for clients. Yeah, but that's about it. And I encourage everybody to check out Quick. I think it's an important step in the web development history that we've got going on. Thank you so much for chatting with me, Tony. ~ ~this was like a super academically interesting conversation and it was cool to just learn more about what's going on with quick.[00:37:00] Awesome, Noel. Thanks for the great questions.