Hello everybody, and welcome to another episode of JavaScript Jobber. Today you have just me Dan shap here, your hostest with the mostest, coming to you from Tel Aviv, and uh with me, it's Hi Resnick coming from Israel Awareness Israel. Remind me please vision Zon vision that Yeah, yeah, a town and uh. We are both here today to talk about all sorts of JavaScript related goodness, specifically about the Quick framework, about JavaScript streaming and lots
of other great things. Before we start, Shy, maybe you can introduce yourself. Yeah, sure, and we could also play out all the other voices that people are used to know hearing, like Chuck and Jane. Yeah, it's just the two of us here to day. That's okay. They will have pomo. Hey, I'm Shy Resnick. I'm part of the Quick team. Also the founder of highersio, where we make web development fun and efficient by courses and consulting and such. And yeah, I run the larger
JavaScript meetup group in Israel, over eleven thousand developers. Yeah. And also as a hobby, I do improv and stand up and stuff like that. I like to do entertaining talks all over the world about JavaScript and trying to make it less boring. Yeah, that's me. JavaScript is not boring. JavaScript is the most exciting thing ever. Yeah, yeah, yeah, I totally agree, depending on which topics I'm guessing. Yeah, it's so exciting
that we're in the process of replacing it with typescript. Well, it is kind of the same, right, Like I wouldn't mind if typescript was. But yeah, that's a hot topic. I've heard several interesting points in this regard. One A J likes to refer to to typescript as a super set of a subset of JavaScript, which means that it's a totally distinct programming language.
And the other interesting point I made, I think it was from what's his name, Mario Kalina, I think is the guy is the main one of the maintainers of node Matteo. He says that because every different configuration of every different thing you put in tis configure basically creates like a different programming language. So JavaScript isn't so Typescript isn't really a programming language. It's a multiverse of programming languages probably, but hey, it helps with the enterprise scale refactoring,
so I'm happy with it, that's for sure. Yeah, I'm wondering how many of your consulting gigs are helping companies transition from jobscript code bases to typescript. Oh no, I think more by this time most of of the you know, our industry are in typescript. I think there was a time, you know, ten years ago or something like that where people still debated whether it's typescript or flow, or like whether we should stay with Vanilla.
I think by this point everybody kind of understand that, you know, if you want to do, if you want to save a lot of time, and you know, have a cleaner code base in terms of like understandability of you know, what this code actually does. I think typescript is the default. So oh yeah, I totally agree. It's just that taking any existing large scale JavaScript code based and transitioning it into Typescript can be a challenge.
So I'm wondering how many organizations are still stuck with either actual JavaScript code basis or code basis that they have theoretically transitioned to typescript but in reality are mostly untyped. Yeah. I don't have the statistics, but I'm guessing like you still have a you know, project with only Jaquery or just vanilla JavaScript. Pretty sure they're there in the wild, but don't knock jaquerry. The new version has just come out. No, then, wasn't an yeah totally for
it, But yeah, that's so typescript. I think it's kind of the standard these days. And you know, what's not yet the standard? What's not yet the standard JavaScript streaming? Glad you asked, And that's what we're here to talk about. Maybe we'll make it a standard. Yep, yeah, I hope so yeah, so so yeah, that's ah, where do you want to start from the beginning, like beginning it seems like a good Yeah, beginning seems like a good place to start. Yeah, okay,
cool. So I was born in in nineteen eighty three. No, so what kind of wait a minute, you are you? Just you made the Big four? All yep, yeah, I'm all still and you still have your hair. Yeah I look sixteen, I know, but I'm all older
at least. So yeah, it's kind of like the whole jobaskul, like streaming a metaphor kind of ties to you, like my whole journey with with Quick, which was a weird journey, how I got introduced to it and also how I ended up joining the team and helping like weird journeys, can you can you elaborate? Yeah? Okay, So I think three years ago or something like that, I talked with Michele Heavry, who created Quick and also Angular. We've been friends for a couple of years. Ever since.
I gave him a funny T shirt at Angie Conf on stage a grand guy. I really like it. Yeah, yeah, is awesome. I gave him a T shirt saying transclusion, I don't think it means what you think it means, or something like that. You keep using that word about the weird choice of words in Angular JS. And ever since then we we became friends and and say staying in touch and we talked just just before he left
the left Google to join a new startup called bill Loreo. He shared with me that he's working on this new cool framework called Cute and I was like, cute, Yeah, but you spell it qoot and I said cute. I said, no, cute And I was like, Michico, we need a different name. I will need to digress you. There was this movie like I don't know a few decades ago about this band. I think Tom Hanks was the director or he wrote the script and the name of the band
was. They decided to call themselves the Wonders. It was like a band in the fifties, but they wrote it like one, like the word the number one, so everybody would call them the own leaders. So eventually, so eventually the record label change their name to be one the Wonders, like spell normally and normally. Yeah. Yeah, So that that that was like,
you know, the the weird naming decision at the beginning. And it showed me a demo he said, you want to shore sea Demon if you know, mischo is very excited about showing the beats and pieces of hout the technology works and such. So it just like threw all this information on me and hours at the time like focused solely on testing and TDD and helping companies with that, and I was like out of context of all like you know,
the meta framework you know game back then and all that stuff. So it started like like showing me that if you create all these like files manually and encode all the information in the HTML manually, and if you do all this manual stuff, when you load the app, it will be instant. You have no you'll have no delay, and you could just do it. And I looked at it and I could only understand like twenty percent of everything said it said, But I got it that there's some innovation here where you
and code stuff in the HTML. Like that was something that I didn't really see before about like framework state that the HTML remembers from the server. So I said, like that that's cool, Like it's very innovative, and he said like, okay, so you're ready to you know, write some content about it or videos or you know, like join. He sent me like a link to get up right away, so you know, maybe I could
contribute and such. And I had, like I had this intuition, you know how you have this intuition where you cannot explain but you just feel if it's like the right thing or the wrong thing, or like you know, how you feel about it. So I was like, I was like,
yeah, I'm not sure. Like I was like, yeah, I'm super busy now I have like courses to create and such, and it's it's a hard thing, you know, because you know, it sounds it sounded innovative, it looked innovative, but I really like something felt wrong, and after the fact, I thought with myself like what what made me like say, not really? And I realized that it was the whole manual thing like I
needed to do. You know, if you go through the history right and you see, I think you've been the talk where I went over like, you know, the history like the last twenty years of web development. So we saw, I showed her that, you know, we go through went through the cycle of you know, user experience and you know, developer experience right like we should, by the way, we should probably put a link
to the talk in the show notes afterwards. Yeah, now there's an updated version of it that I did in JS world from last month supposed to be yeah, waiting for them to release the videos, but but yeah, but but in short, it was basically, you know, if you think about the last twenty years, we've went through you know, the the MPAs to the to d HTML and then you know spas like single page apps and then hybrid apps with like you know SSR and the new hydration and such, and
every time it was like user experience and developer experience basically fighting, you know with each other. You want more features, but then you're you know, taking taking a loss on the user experience side. And which basically means that how fast that that users can you know, reach their goal. Basically,
yeah, I know what you mean. It's kind of it's it's also this whole transition of going from websites to web apps and what does it actually even mean to be an app on the web, and of course going from desktops to mobile. There were a lot of transitions going on more or less at the same time that all got in the way of providing you know, holistically good experience to end users and simultaneously making things, let's call it manageable for
the developers exactly. So that that was like, that was their conclusion that I got to, which is, you know, we strive with all these transitions for apps. We wanted to have a desktop like experience like for the users, right like something it opens right away, you stay in there, it remembers what you typed, you know, and all that stuff. You can go back and forth and such. But it wasn't enough like just you
know, focus on that experience because developers. You know, what I realized is that developers care about this stuff like user experience as long as it doesn't interfere with their development experience, right Like if you ask them to do these extra steps, they will only do it if they have to write. It's just like some of the developers were testing. They test after the fact because they have to or the you know, it's it's not really part of the
process because it's extra steps. And when you don't see the benefit of it or you don't feel the pain yourself, then you just like you know, want to focus on what you In other words, what you're saying, is that real lazy? Of course? Yeah, yeah, I think it's a good thing though. Yeah, for sure. I like to say that software development is one field where procrastination is often a good thing because maybe you'd end up not having to do it at all, exactly if you wait long enough,
maybe the browsers will implement signals for you exactly. So so coming back to that point where I said Michico, I said to Misco like, well, I'm not sure and such. It was because I had this intuition because there was like the developer experience was lacking, right, Like I had to do all this manual stuff, and I thought to myself, well, nobody will want to actually do that to just shave off like a couple of milliseconds
of the loading time. It's not really a big problem. And I don't know it wasn't excited about it. Now, Like a year went by and I offered my help along the way in terms of like advice and trying like ideas and all that stuff, but it didn't have really time to get involved. Here went by and because of COVID, we start doing remote talks in our meetup group. So at one of those remote talks, I invited Michko
to speak about We had a meet up about like future frameworks. So we invited Mischko to to speak about now quick not cute but still spelled wrong though
yeah, still with a twist. Yeah. So I invited to talk about that, and I was like in a much busier time at my life, even like you know before when we talked, like a year later, I was super busy, like managing a business and uh, trying to to to juggle between like course recording and new clients coming in and employees and everything together and you know, having a family and wife and two kids and and so I was like late in the evening getting a call from my wife like are
you coming home? I need help? Uh, And I was like, damn it, I forgot that we have this meetup today with Mischko and we're supposed to like come online and join us in a in f an hour or something like that. And she was like, okay, I will take care of the kids. Okay. Uh yes, shout out to Naga, I
love you, thank you. So so we had this meetup and in that meetup, he showed quick the new version and he went through all, you know, the explanations and stuff, but he showed something completely different than what he showed me a year before, because he said, well, you just write these JSX and that's it. Everything done is done for you and you can just like you know, get the instant loading app. And I was like, hmmm, where are all the manual like writing of stuff and you
know, inventing your own like file names and stuff like that. And he shared that, you know, during that time, he was joined by two brilliant developers, Adam Bradley and Manual Media. Uh they are brilliant, by the way, I totally agree. There are two of the most amazing developers that I know, Yes, exactly, and and they they both came from
Ionic and created Stencil together. Uh. So they got excited about He got them excited about cute or quick, and and and and there they got excited also about the potential to automate stuff like not just getting the result, but also not just getting the user experience, but also getting the developer experience. So that's exactly what they did. And one when he joined, he created
a compiler called the Optimizer. Basically it took all the manual steps and codify them and wrote a tool that does that for us automatically, like all the you know, extraction of files and renaming of things and really really hard problems to solve, and how to extract closures into their own files, which is also a very difficult problem to solve. So together the dream team, you know, solve that problem and create it the new version that he showed in
the mediup. And I was like, now it's interesting. It's more interesting. I was still busy with all the stuff, but I took a mental note and said to myself, well, I will check it out, like I will take my site project. I agree that it's kind of necessary for for something like quick to succeed to be developer friendly, because at the end of the day, if the goal is to get good performance, but I have to work really hard for it as a dev then I might as well
work really hard on it from react or something. You know. It's like the benefit of something like quick from my perspective, and I think Mishko has also presented it this way is essentially falling into the pit of success. Is I want to have the same challenges that I have working development, you know, doing development in other frameworks, maybe even less if possible, but the same at the most, but automatically end up with much faster web applications or
websites. Exactly. That's the low like the barrier of entry at least should be exactly at least what you're used to, if not way better, you
know, way simpler to develop. Even so, and one of the advantages that that the team had back then in their disposal is that they were starting from scratch basically, so they just could like take inspiration from different solutions and starts start from that point, like taking reactivity, although it was really essential part to you know, be able to do all this stuff, but also like looking at all this like tiny developer experience happiness that you got from different
frameworks and bake it in into this framework to make sure that you start your starting point is amazing. And so I took that, you know. A couple of days later, I took a side project, you know, a website that I had and you know, with like a little bit of interactivity and refector it just just as a POC, just to test the water, let's say. And and then I deployed it and you know, test it
on the paste peed stuff like to see the result. And I got like nineteen nine on ideas or something like that, and it was it had javas created, had like stuff in it. And I was like what, Like I couldn't believe that I just wrote JavaScript and I got this score without manually optimizing anything I used to, like you know, like rap stuff with like you know with rappers to yeah, cashing and all the against that we that
we do exactly. So I had this emotional you know wave coming through, like you know, again this intuition again struck me, but this time on the positive side and on the negative side of like wow, if I have this feeling, it's like I want this to be my future as a web developer, Like this is what I want everybody to have to experience so this
must be the future in terms of technology. And when I looked more into it and spoke with Mischko and all that stuff, he said that, you know, in order to bring it to all of the rest of the firmworks that we need to make a lot of breaking change, breaking changes in the ecosystem also like the API and all that stuff. So it's basically it's very very very hard to do and will be like you know, you know, like like in the past, nobody likes the big migrations and stuff like that.
I spoke about this with Wishko as well on occasion, and he basically said, I think that initially when he came up with this idea of streaming or resumability, I don't think he was using the terms yet at the time, but as an alternative to hydration. The problem that he was really looking to solve was the performance cost of hydration, which we might you know, touch on it a little bit. I've spoken about it in the past,
but it might be worth part to speak about it again. But he thought about initially doing it, I think in the context of angular and he very quickly came to the realization that it was just not doable without changing not only a lot of Angular internals, but actually changing the API or or the the way that you actually use Angular. That it couldn't stay Angular, that it would be like that transition from Angular we want to do all over again.
So you might as well start with something fresh. And as you said, you know, picking JSX, it basically looked at what was the kind of effectively industry standard at the time still ongoing. Yeah, the most popular, which is the React and basically embracing Embracing that as like you know where to start in terms of, you know, what the developer experience kind of feels
like, even though it's it's not exactly the same. And we can touch about other differences between React and quick in terms of you know, the the
primitives and the developer experience. Yeah. Yeah, So so basically, well this is a good point because that's that's basically how I came into Like once I had this epiphany, I went to like I schedule a call with with mich Coin and told him, hey, like I want to help, Like I remember when you asked me like a year ago, and I didn't have time right, Like, I was busier, but I know I had a
wife that was you know about the divorce before taken yet another project? Yeah, jokingly, yeah, but but yeah, but I was still like having this you know, invisible force, you know, pulling me towards like, hey, I really want to get involved. I want to be part of
it. And I, as I said in the beginning, I come with a lot of experience in like creating communities and make and and being part of, you know, multiple communities along the years since the nineties, and seeing what makes a good developer community and what makes uh, you know, a bad community bad let's call it less less successful? No I I specifically,
I'm not talking about existing developer communities. I'm talking about communities in the past that I was part of which were very toxic, toxic and they are not existing today because of that. So that's why I call it bad. Uh So I and and and in between you have always like you know, nothing
is perfect, and you have in between. But I learned lessons from it, and I really really wanted, you know, for quick, to have a very friendly community and very helpful and very beginner friendly, and and and and and in places that people feel comfortable asking questions in and helping each other and grow and I knew that it also will help growing the framework in terms of the ecosystem, because people will not feel much better stuff. Undoubtedly,
promoting a new framework is an uphill battle. First of all, we're kind of spoiled for choice. I think they're like, what eight major frameworks, maybe even more, and you know, I'm calling them major frameworks. But the reality is that React, for now at least, remains the undoubted king of the hill. I think React represents, you know, just React on its own has as many websites I think in the Google Chrome user experience reports
all the other frameworks put together. So undoubtedly, pushing or promoting a new framework is, like I said, is an uphill battle. And yeah, did you, by the way, did you actually joined the royal or did you stay? So you're kind of like a contractor a helper. No, I wasn't so so, as I said, I had a business and employees and you know, obligations and all that stuff. And I looked at it.
You know, from the beginning, they talked about the project as a community project, like they needed it for you know, their products and and and that's why they invested in it. But they always talked about it as you know, being a community driven project, and uh so I said, like, hey, I would join as a community I don't know devl or you know, contributor to the community because because the team was small at the time, they didn't have anyone you know, focus on that because they were
like working very hard on getting to you know, version one. So I started helping with you know, writing the community values and making sure that everybody feel welcomed, and you know, started creating these groups and highlight certain people who are you know, extraordinary in their contributions by creating the quick heroes and
community leaders and meetups all around the world. And I was focusing on mainly on debt and also started I knew that in orders, like like you said, it's an uphill battle, and I came at it from a different perspective
in terms of like, let's say, the other solutions. I view all of the other solutions and it wasn't a pun as one big Javaskist family basically because I come from many the Angular community, which is also very friendly and very supportive, and I have lots and lots of friends there, and I see other communities as well which are very very friendly and very helpful and everybody basically is working towards the same goal, which is meant to make sure to
make our lives better. So since the beginning, one of our values that we're said, we said, what was making sure that people in our community don't you know, talk badly about other frameworks or solutions. Uh. From this this mindset of one big joba skied family and everybody hates you. I actually, I actually was like in just in just World in Amsterdam last months
when I gave my talk. It was mainly I think view developers and lots of the view ecosystem projects like nuts and WAT and uh, everybody was so so friendly, gave me the same exact vibes and feelings from the Angular community, which mostly you know, have been to the Angular events. So that was another confirmation that we're all just one big JavaScript family. And you know, people are arguing over developer experience in terms of syntax and stuff like that,
which is fine. Everybody has their own taste, but together we can, like you know, march forward as a group and try to make the web better. So I help, I offer my help with that and start
getting more and more involved. And one of the things that offer to help with because I have a lot of experience in creating courses and education and such, I noticed that the way that we are explaining quick is lacking or it's too complicated, and we're losing I felt that we're losing a lot of people along the way who are not yet experts at you know, JavaScript or the firm or the ecosystem and all that stuff in order to understand like why is
it cool? So me and Michico recorded a free course, a quick introduction, and we recorded it in one day, but then it took me like five months to re record parts after Like the more I learned, the more I saw how we could simplify stuff. And that's where basically the JavaScript streaming metaphor came from. It's the metaphor of streaming came from Mishko at one of
the talks that we gave together in Poland. But I was I insisted into trying to name it JavaScript streaming so we could explain the metaphor and then to try and explain the metaphor to the viewers. Okay, so you know, just like what is it? So remember back in the day, we wanted to, you know, see a movie. We had to download the entire movie gigabytes a file. Yeah, I'm old enough to have been there.
Yeah, and before that with vhs and all the stuff. But anyway, I wanted to legally, of course, download the entire video and uh yeah, legally, and just to see the end of the right the movie ors or to continue where we left off. But today we're not doing that anymore most of the time, right, we have something else. Right, we have streaming. Yeah, so we have Netflix and YouTube, and it's really easy to jump to the end or to the last point where we stopped and
just to continue watching that. And that that metaphor, in a very simplistic way, is the metaphor behind the innovation behind quick and so in order to like just compare it, because you asked about the hydration just in one sentence. Hydration is basically the act of rerunning the JavaScript framework on the client side after like to make sure that the HTML that gets produced by the server, which is done by the server side rendering in technologies like you know next JS
or next or any hybrid technology that runs like renders on the server. It produces an HTML which has no logic in it, and then the framework needs to rerun again on the client and in order to make this page interactive. That's basically, yeah, that's the funny thing is and a lot of people I see still don't understand that point that when you use service. So I'll pull back just a little bit, if you excuse me, just to give
a little bit more context. When people moved to frameworks like React, the initial the initial approach, or Angular, the initial approach to these frameworks was to actually do all rendering on the client side. So in the very old days, we would render everything on the service side using something like PHP and
send it down and then augment it with jQuery or something like that. But if we wanted something that was really a more sophisticated application like behavior and we needed much more sophisticated interactions, we needed something like an Angular or React.
But what we ended up doing is doing all the rendering on the client side, and then we would initially just deliver a blank page, then download all the JavaScript, then download all the data, then run the JavaScript produced the UI, and only then would we start downloading things like fonts and images and
stuff like that. So the downside with this approach was that we had the blank page effectively for a very long time at the beginning of the process, and this was especially bad on mobile, where things are obviously slower, so people would literally look at the blank white page for multiple seconds, even longer
in some cases I've seen longer. And then we got as a SR like you mentioned, which basically said, okay, let's take this JavaScript and react and run it on the server produced HTML, and then instead of sending down a blank page, we'll send the initial view from the get go. But like you said, you got just essentially an HTML. It's like a picture
of the website rather than the actual functioning website. And the crazy thing is that hydration process that in order to make the page actually interactive, we had to effectively regenerate that initial HTML on the client side, so we still had to download all the JavaScript, all the data rerun it. The only benefit really was that the user at least had the page to look at while all
this stuff was going on and perceived performance. Yeah exactly that if it happened quickly enough, then by the time that user actually tried to interact with the page, hopefully you know that that hydration process will be done and the page would actually be functional so the user wouldn't actually notice that that delay. Yeah, and now I was challenging, like, in the course that you created, by the way, you could find it on quick school dot com.
It's free. You can just watch it on that course. I'm challenging. I actually challenged Misko about this point, and because he was saying the same thing. He was saying like, well, you know, people can wait for like thirty seconds to interact with the page. And I was like,
get out, Like nobody's waiting for thirty seconds. And I actually experienced it later on myself by waiting being with a low reception or something like that or connectivity and waiting for like some very very simple page with some interactivity to load, and it was taking forever and forever to load. And I was like, nope, not but even if it's not forever, even if it's just
a couple of seconds. So you know, before I'm currently working at Next Insurance had nothing to do with next JS, and prior to that, I worked at WIS. And at WIS, when when you're looking at the website on a mobile device, you usually have a Hamburger menu. It's really common in a lot of websites, but for the hamburger menu to work, it used to require the hydration to finish, so you would get the initial view of the page with the hamburger menu, but before the hydration actually finished,
that hamburger menu wouldn't actually do anything. So you it's it's worse than a slow website is from my perspective, it's a broken website because the users tap on that hamburger and literally nothing happens. And you know, that's like the worst user experience that there is. Or think about a website. I go like a mark, like you know, a product page with a purchase button.
Then you click that purchase button and nothing happens. It's like the worst possible experience if I, you know, click a purchase button like once, or I'll be afraid to click it twice because I'd be thinking, I don't want to purchase this product twice. Yeah, a tow card like twice, and yeah and yeah and and I basically just bounce so so and and and
the and the point and the point here. Like another realization that I had is that you don't see it when you're developing locally or you're just testing out
like a small demo. It only bites you when you reach a certain point of an app size, And then it becomes an issue because then all of the dependencies that you added to increase your or to improve your developer experience, like this NPM package does this, and this MPM packages does that, and you combine all of them, and all of a sudden, this is part of your global share dependency that needs to get downloaded as the first dependency for
the hydration to finish up on every page. Then it becomes a nightmare to try and then analyze the bundle and see what are the biggest NPM packages that you can maybe replace. I don't moment jes with date functions to like to make it more functions and all that stuff. Right, what we said about falling into the pit of success, it's this. This is exactly the opposite of that. It's literally falling into a pit of vipers. Unless you actually
invest potentially significant effort. By default, you'll end up with a bundle that includes everything. And that bundle, by definition, can be you know, pretty big. You know, I've seen multi megabytes of bundle, you know, if that is it compressed and whatnot? Still multiple megabytes yep, and
ties it back by the way to the metaphor of like video downloading. This is you as a user downloading the entire video just to hit play and you know, waiting all this time just to have the video playing or do something right. Yeah, and comparing that with streaming, which is basically how quick works. This was like when I, when I, when I try to you know, looked at my definition of like the generation of you know, technology innovation in technology. I was like, you know, generation one was
the NPA that you talked about with the pitch pin or rendering. Generation one point five was you know, adding a bit of JavaScript on top of it, like the dynamic htmail or something like that that we call it. Generation two was single page apps, and generation two and a half because it was again a laying a layer on top of you know, the single page app
was the hybrid. At least, those are my definitions. It's not like scientific Now I try to think about like, Okay, what's coming next, and what's coming next should should be a completely paradigm shift, you know, compared to what it's It cannot be just an improvement over what we already have.
It needs to be something completely different, and it took me a while, but when I realized how quick works or how JavaScript streaming works, I realized, hmm, we have not we have in this a completely different paradigm shift. And then it hit me why what Mishko was talking about about the philosophy of automatic automatic optimization basically that you get up all the automization, but
automatically done for you. So if you if you want, we can dive into how jazz stream So we said, just to kind of put the point of where we are, so we said that we regular SSR. The problem is that you get the initial rendered view in the HTMIL really quickly, but then you have to, like you said, like downloading the entire movie.
It's like getting the first frame of the movie. You see the first frame of the movie, but to see the rest of the movie, even the second frame, you need to download the entire movie and wait for the entire movie to finish downloading. And that's what you get with most frameworks that use
hydration. Now. I've actually given a talk at at react next conference, for example, talking about various different strategies that some frameworks have come up with in order to address this cost of hydration like you might get something like progressive
enhancement, which means that some functionality can work before hydration actually happens. Or you've got technologies like React server components where you can specify that, you know, some components being essentially static don't need to hydrate, but anything that is
dynamics still does need to hydrate and stuff like that. And what you're saying is that with this JavaScript streaming approach, you're getting rid of hydration completely altogether, no hydration anymore, but you're still getting all the benefits that you can build interact and you can build web applications that are as interactive as you know, those classic single page applications written in React or view or whatever. So can you elaborate on how this magic kind of happens? Yeah, yeah,
yeah, definitely. So just like in video streaming, Okay, when you have like a big file of video, you want to chunk it into packets, right, this is basic when you upload the video to YouTube. This is what happens behind the scenes and through the technology of the server and the client, it gets streamed, it gets chunked into encoded into a format,
and then chunked into packets. And then these packets are being streamed at the client the like based on the point that of the movie that they wanted to watch, and it gets buffered right when you post the movie, it actually buffers the next couple of packets or the next, i don't know, twenty to thirty packets in orders for you to have like a smooth experience, so you won't have like the you know, loading spinner every time you want to
watch it if you have a slow connection. So that's the same way that Quick and with the quick optimizer, the compiler that manuro works, you write your app in a very familiar developer, very familiar syntax and developed development experience. Sorry, and then Quick in its syntax, comes with the built in markers that you don't need to really think about most of the time because it's
just built in the in the syntax, which are dollar signs. Mainly, instead of a component function, you have a component dollar function and that's it. You just have to use that. You don't have any other choice. But this is a marker for the compiler to know which functions it needs to extract into these packets, right like this tiny chunks of JavaScript, and you can think about all these functions has been extracted into different tiny files automatically.
Now it's it's smarter about how to bundle different stuff together. But conceptually you get this packets on the server on build time. Okay, it happens.
So basically what you're saying is that you've got this thing that's kind of a cross between a compiler and a bundler, which does essentially a static analysis of the code, and the code also includes hints or directives or instructions, so some of it is basically just looking at the code, but some of it is looking at special directives that are embedded within the code, like the component dollar that you just mentioned, and using this information, this compiler stash bundler
is able to break the code into pieces that are effectively can be streamed essentially
independently I guess of one another when they're actually needed. Yes, And it's not really a bundler, it's more of like an unbundler or an extractor, right Like it's the opposite of a bundler because it just takes the code and knows how to break it apart into these packets and also how to create two different versions, one for the server side rendering and one for the client or the client that needs to be So I use the term bundler because most of
us, when we deploy code into production, we are used of, we're used to using this thing which takes a lot of JavaScript files, the source files, and then generates from them, usually a lot fewer numbers of files that are actually JavaScript files that are actually delivered, you know, having really
funky names with hashes and whatnot. And what you're saying is, in this case, it's not really a bundler because the number of files that you know, the sizes of the files were put aside the number, but the sizes of the files that get generated are actually often smaller than the original source code files that we created independently. I'm not talking you know, all of them
together. I'm talking independently even each and every file, because you're just looking at you know, like units of code that needs to need to be executed together. Yeah, yeah, exactly. So you extract all of these into
different tiny files. And so the reason we needed bundlers to make, like to concateinate everything into or to bundle everything into you know, fewer files, is because of the limitations of you know, HDP we we like, we didn't want to you know, load all these files together because then it will get blocked, and you know, we have a bad user experience onloading time, so we wanted to chunk it into into a single download, not to pay the cost of the extra like you know that. And also the fact
that you know a lot of the code usually works synchronously. You know, you have you have function A calling function B. Then function B needs to be bundled with function A because the assumption is the way that the code works is that they need to be able to run together. Yeah, exactly or
totally correct. So so so getting back to so you so you have this packet on bill time, it creates all these you know, packets, and it and and it creates like a manifest of like in the basically a map where you know which which location you know, like the packets map, let's say, and then it takes it and when the user requests a specific route quick then on the server side analyze which route it is and produces instead of a let's say, a static HTML which just like a freeze frame of the
you know, of the first frame of the video, it creates what I call a smart HTML, meaning the HTML that knows all of the interactivity points of the possible interactivity points in that page. And it analyzes the this like packets map and realized, oh, these packets belong to this page. So it create a set of instruction and encode it into the HTML for the browser to know what to do next, like how to preload these interactivity points or
packets or necessary packets. Now, then it sends that only that HTML over the wire. The user then loads it in the client and then starts the next thing, which is the buffering part like the video. Right, so quick spins up a service worker or basically utilize the service worker and hance it off this list of the tiny packets you know, list that it needs to buffer or to pre prefetch in the background in a separate thread, right,
so that way it won't block. If the user wants to, you know, interact with the page or something like that, it won't get blocked.
So you basically buffer all these pieces. And then the last point of this metaphor or of javaslipstream is that now when the user will interact with the page instead of lazy loading the piece, like let's say it like clicks the button and add to the card right like your example from before, Now instead of waiting for that code to load only on interaction, the code is already there because of the service worker. So then a Quick also does something that no
other solution does, which is called lazy execution instead of lazy loading. So you just execute that code on demand. And because everything in Quick is basically set up to work a synchronously, that means that it could do it in every different point in the app, meaning that not thing gets hydrated or loaded on demand when the page loads, but every single event in the page could conceptually become the initial main method or the entry point to the app to start
the execution of just those parts of the app. Now, Quick actually smart enough to also buffer the next couple of pages, so you always get a smooth interaction, so just to complete it instead of it's more so, a website is not like a linear video, right, It's more like a quest.
Well, depending on the user, you know events, yeah it you know, you choose your own adventure thing, right, So if you click on if you start your life on the card page, let's say, or you click on that button, you will end up totally different in a different location, so quickly smart enough to know how to buffer in three dimensions in terms of like where the user, so they always have a smooth experience, just like a single page app, but everything will be super super efficient and
the developer won't have to think about any manual optimization. That's the philosophy behind quick and behind Java's restriction that I think that's a really important point, because so a couple of important points. Actually. So one thing is actually our last episode that we recorded was with the Rich Harris, the creator of Swelt, and it's not something that we spoke about with him, but I recall him saying I think it was him that kind of had this critique of lazyloading
things. They said that he often browses while he's commuting on let's say the subway, whether there's little or no reception, and he opens an article and when it lazyloads stuff, he just loads it before he goes on on the train, and then because it uses lazy loading, by the time something is needed, he doesn't actually have the reception, and then that stuff doesn't load. So you're saying, in a sense, you're doing lazy loading and lazy
execution. But because you're using this prefetching mechanism or pre loading mechanism with a service worker, the stuff will be there when it's actually needed. So it's downloading in a non blocking way. It's not blocking execution or responsiveness until it downloads. But it's also not just being loaded lazily only just when needed. It's it's being loaded as soon as possible without blocking. So that's that's a
really important thing. And the other important thing is when I was at WIS and we had one of the problems that we had was that you know, WIS is a website builder and you have like in the wigs editor, you could pick from hundred of different types of components like buttons and menus and sliders and galleries and whatnot. And one of the problems we had was that the initial implementation downloaded all the possible we bundled together all the possible components that you
might have on the page. Now, that kind of worked initially when wigs had a few dozen components, but then wigs had a few hundred components or a few thousand components, and it got to the point where it was ridiculous. So we had to start thinking about how to break it up, you know, understanding which components go together, which components need each other, like for example, a menu item is needed by a menu and so forth. But we effectively, we kind of automated it, but we had to do
all the heavy lifting ourselves, Like you know, we as wigs. We could invest a lot of developer and developer resources into it, but it was something that we as wigs needed to do. We didn't get it out for free from the frame work. What you're saying is that with quick you get
all this goodness automatically. And it's even lower than the component level. It's literally at the let's call it an event handler level or function function level or function level that if you need that function, that function will only will only be downloaded if not when it's needed. No, I'm not phrasing it correctly. It's bundled separately so it can be downloaded all on its own. It will be and it will be downloaded in a non blocking way so that it
will be available when it's needed. Yeah, you can think about it as eager buffering and laser execution. Okay, that's how that's that's the right, A cool way to phrase it. Yeah, Yeah, because it's not so eigger loading is like we all like you know that all these have this connotation of oh no, it will block the website. So that's why I call
it eager buffering. So it's it's more obvious that it's not blocking, you know, the main trend and uh and lazy execution because then yeah, we only execute that code because part of the execution is also what blocking you know stuff, So uh yeah, that's uh, that's so the philosophy behind quick, which is automatic optimization, you know philosophy, I think it's it's one of the most you know, important things in a in a technology, Like
if you have a good philosophy, all of your technical decisions basically are drive or being drived from that philosophy. For example, implementing a feature that will turn something into a more manual optimized way is against quick philosophy, which is automatic optimization. So we will think really really really really hard before we'll introduce another you know, you know feature into quick which will make it less automatic
automatically optimized or auto optimized. Now that's what like, when I think about you know, the future and where things are headed in terms of like the different solutions I think that everybody is working towards a future where they want to you know, automatically optimize as much as possible. I think that currently quick in terms of the technology because it because it didn't have the baggage from like
you know, supporting like backpoar compatibility and all that stuff. It was in a unique point to both improve the developer experience but also make sure that things are being done automatically, you know, as much as possible. And that's why I think that Quick currently has you know, a doorway to a much
faster future which everything is automatically optimized for you. And what I showed in my lest lecture is kind of another epiphany that we got by thinking about how we can take this philosophy and this innovative you know, paradigm shift and actually imagine how the future will look like using those tools. So do you want to hear about like, yeah, sure, I'd love to hear about the future. Does it involve Does it involve AI taking over the world? Yes,
of course the future is AI and we won't have any jobs. And that's basically the well, well look at it this way. You know, our fear today is that AI will take our job. Our fear, like a few decades ago, was that AI will will terminate us. So well
it first it will take our jobs, then let's talk. But yeah, so yeah, obviously, you know, AI is a big important part of our future, and I think that, you know, it will be an interesting next couple of years to think about you or to see the devolvement of frameworks and how they better comport incorporate themselves with the use of AI and large
language models and such. Now in quick for example, since the Get Go ever, since we realized that well things could be broken down into a function level and could be buffered and or in a predictive manner, uh sort of say so, Mischko and the team actually started talking about and speaking about this idea of what if we could you know, getther or you know, track anonymously, not with any identification details and such, only the hashes of these
packets like for users in terms of like which packet gets loaded before which packet, and that way we could take this information, feed it to a model and and build the most optimized order of packets for each page, meaning that if you land on the card page, everything gets buffered in the perfect way. So the users will always hit the cash and not delay when the you know, when you need to load. So that's that's that was a dream, you know, a year ago. Now it's a reality. It's called
quick insights. Wow. Yeah, and uh it actually has been used in the quick Dogs. So quick Dogs UH is using quick Insights, which which is you can you know, you can think about it and unless this needs to happen per website, right, it's on a peer website level of course,
yeah, spa website app based. So if I'm let's say I'm using something like a quick city, you're saying you're using like built in telemetry, as it were, to gather information from the field about you know, that particular website in which order the various UH downloaded packets are being needed, and then optimizing the order of delivery to match to best match the order in which
the packets are being used. It's like an elevator anticipating which floor it will be needed at and trying to be as close as possible to that floor by the time that it's needed. Yes, and and basically this is what we call predictive buffering, like it tries to predict based on the average usage.
Oh, these packets goes together with those packets, so let's make sure that they are either bundled together or loaded just right after or buffered just right one after the other, so they will all be there because this is the most likely path that the user will take right. So up until Quickly Insights and the farmak did it in sets of euristics where you know, if it's below the fault, it will you know, put it after and we will buffer
the stuff above the fault. But now it's a reality and using that, you know, I I looked again at the lecture or talk that we had in our meetup where Misko visited us, you know, to record the course on the Quick School, and we did a meet up about quick where he revealed for the first time Quick City to the world and announced that the you know, they build a meta firm work in the In the end of the event, we had a talk by Benjamin Greenbaum, very you know, another
brilliant developer. H you know, he's a core team member. No, the very very experienced developer who did like half parody half truth talk about the future of frameworks, like how like the framwork of twenty thirty that was like basically talk about and it was a half parody because it took like a framework and imaginary framork called quicker, and it showed like, you know, all the possibilities that what we'll do in you know, a couple of years and
with you know, lots of ideas there. And he didn't I don't think he knew at the time that Misko has been thinking about this like quick Insight thing like and thinking about how to do that, but a lot of his ideas who look looked imaginary. Now we started thinking about them as reality because quick Insight already works. And then we thought, okay, we have those statistics, so what else could we do with those statistics? Now, mind
you, those are statistics based on the function level. That means that you could theoretically it's not currently being worked on, but theoretically you could produce automatic and tw ntests because you know the set of actions and their order that the user are taking. Maybe you know, so you could potentially create or get to a point where you can generate automatic and to end tests another thing that no developers don't like to do. But now based on the actual user usage
of your app and not just you know, you making up stuff. And then we thought about what if we could take those tests and use them as a feedball club for the AI model to now automatically optimize your code base for you, meaning seeing which code parts are not being actually used in production and removing them, creating an automatic A B test with them to see if they are needed or not, and then just eliminating code from the code base.
Another AI team member that could like you know, refector your code and all the technical death death that you have, you know, to refector stuff to make stuff cleaner. You know, you could use all this stuff and feedball club based on this ability, because again the ability of javaskip streaming to track
stuff on the function level which wasn't possible in an automatic way before. So these are the kind of stuff that we are thinking about in terms of like when you think about the future of the web and the future of the framework and what else we could leverage and such. And I would love for all the solutions to to to have this, you know, so we could, like I said before, we are all one big Javasy family of web developers.
I want everybody to experience this automatic, you know, feeling of I can just focus on building the features and doing like cool stuff in the UI or the server and stuff, and not worry about all the you know, the stuff. So we're we're coming on close to the end of our episode. Before we finished, though, there's one issue that I would like to address and and hopefully we can do it fairly quickly, even though I think
it's a non obvious issue now I suppose. So here's the thing. Let's say I'm a person listening to to this podcast and I'm saying, Wow, this is really great. I'm really excited about the vision in that these guys at quick have all the cool technologies that they're creating, AI whatnot, and I really want to start leveraging that, especially since we already have a React
application that is using hydration. And if you're using hydration, then by definition, you have like poor startup performance or loading performance unless you take proactive steps in order to remedy it. But here's the thing. I've got this existing code base. It's written in React, because you know, React, like we said at the very beginning, is like the King of the Hill,
more or less like all the other frameworks put together. And how do I get from this existing code base in React to leveraging the capabilities of quick Do I need to wait to a new project or is this something that I can gradually transition to? What? What what steps can I take? Yeah,
so that's a great question. And up until now, so since the beginning, we had the ability of quick a fine React components, mean you can feed you know, quick We have a quick React integration package and you could basically get a function that takes a React component and quick affies it, and that make the means that you can like use your existing React components inside of your you know, quick wrapper or quick application. Now there are other strategies
that you can use. Uh, so far we had the challenge of So we had this from the beginning, and I helped a bunch of companies use this strategy in terms of like that's the surgery that they chose to use. But we kept getting you know, more and more demands too, Like people really wanted to take advantage of quick in terms of like because if you do the quickifying thing, you still are you know, you have like delayed let's say hydration, but you still are suffering from the same you know stuff that
you described. So what we focused on is to work a lot hard and with a lot of community members to make sure that we are building also native solutions too quick for a lot of stuff, for example, a UI component library, which which is fully accessible and you know has also the best of you know, the the developer experience innovations that we saw from like a project
like Shatsien. Uh So we created quick UI in order to you know, remedy that and also invested time in helping other community projects in order to make sure that So the first part or first step is to quickify your existing component. The next step would be probably to place them with the native to quick components for example, that you can leverage the streaming ability over your app and
slowly move. But this is now like from from this point onwards, this is one major key thing that we want to educate about, like taking all of the lessons learned from you know, the past year and a half of applications, doing that and starting to create migration recipes on how to do this stuff and just like started the process. So we don't have it ready yet, but but yeah, that's that's definitely one of the key things that we want to you know, to focus on. So you could do that.
You have the ability to do that with Quickify, but we want to have a more optimized, let's say, or education material because you have different strategies for different scenarios, no microphone tans and how to re rep stuff and you know all that stuff. So yeah, that's what we're going to focus.
I think another important point which I mentioned was that if you're using hydra, if you're if you're not using hydration, if you're building let's say, a dashboard that is part of some sort of I don't know, a legacy an enterprise, legacy application or whatnot, and you don't you don't care so much
about loading performance, then it's a different story. But if you if you're in a place where you're leveraging hydration, you're using something like a meta framework, an xtras, a remix or uh Knox or whatever, and you're using hydration, then you should be caring about the hydration costs, the hydration time, and then you and any solution that you might be looking at. B it reacts over components, be it u islands of hydra, whatnot. All
of them come with a certain amount of development and cognitive overhead. So it's not like you're going to be making able to make any of these transitions for free, and if it's going to cost you, then you might as well be looking at something that's probably going to give you the most bang for the buck. And you know, Quick looks like a really good candidate in this regard. Now, before we finish, let's say I've listened to this podcast.
Sounds really interesting. I want to to kind of get involved in the quick community to learn about this, you know, to be able to start playing with it, to get the relevant resources and whatnot. What's the best way to go about it? Okay, so good question. First of all, to learn about it, you have we our website now it's quick dot dev or we have the the free course that I mentioned quick school dot com where mid mich Core goes deeper into the details behind it and exercises and all
that stuff. And to be involved in the community, you go to quick dot dev slash chat, which will take you to our discord. Come say hi. We have lots of you know, helpful and friendly people in the community. If you have questions, people will help you. Our goal now is to make sure that as many companies are successful using Quick and implementing quick because, as you say, you know, if you have already a lot of things to learn and a lot of manual optimization to do to get in
order to get to those performance it will only scale. So you think you need to think of yourself which solution will scale better with time in terms of like, you know, like when the app will reach to fifty megabytes, one other megabytes and such. Would you like to be in a position where you upload the video to YouTube and then you need to manually cut the video on YouTube and choose which part the you know delivers to the kind or just
upload to YouTube and have it automatically down for you. I think that's the decision that a lot of CEOs and decision makers need to think about where they evaluate, you know, the next project. So come get involved if you need help, d M me or anyone on the team and we'll we'll get We'll get you help and yeah, up and running and make sure that you're successful. And if people do want to d M you contact you in general, what's the best way to find you specifically so you can stock me in
the street or Twitter, shy, underscore resling or on discord. I'm always on Discord on the on the Quick Discord and you could DM me there or yeah, Twitter or you know, quick school or high Rest dot I and all the stuff that I'm involved. So the last thing that we'll do, as we always do on this podcast is the picks. Yeah, I forgot to remind you about it, so but it seems that you've come prepared, so I'll give you a little bit of time to prepare by starting first.
So I don't have a lot in the way of picks for today, so I have just the one thing more or less. So I'm not really big into anime or stuff like that, but it turns out that I found this series on Netflix, which I like, and it's actually the Wikipedia page says that it's an anime influenced fantasy science fiction television series, so it's it's animated and it has a kind of an anime style, but apparently it's not exactly
anime if it's anime influenced. It's called called My Damon, not Demons Damon. It's spelled d E m o N, so it's My Damon and it's like about this world in which, as a result of some unexplained occurrence or accident or holocaust or whatever. The monsters called daemons have kind of infiltrated our existence and people really lose them and hate them. But on the other hand, they're very useful because they have these kind of weird capabilities, like to
negate gravity or do sleep or turn invisible or stuff like that. So people use them. But there's this kid who adopted one, and he actually really loves it for some reason. But of course they are being chased and he's on the run, and it happens in Japan. Because anime, the artwork is really great, uh. And also the stories are so far are pretty good. I'm enjoying it. So as I said, it's called My Damon
and I'll put the link in the show notes. And that's more or less my pick for today because I didn't come very very prepared in this regard to our episode, so Shy, maybe you can, you know, provide a bit more good choice. I also wanted to pick, but I will pick Matt Damon. The actor is not an anime, but it is a good actor. I like him. Uh. I also have a good Nestix show that me and my wife are watching now. It's called The gentleman. Oh
yeah, I actually picked it a couple of episodes back. It's yeah, very very good. Yeah, it's actually it's a it's a Guy Ritchie show inspired by Guy Richie movie. Yeah yeah, yeah, yeah, it's have that distinct taste. We didn't. We're now getting to the last episode of the you know, the first season, so no spoilers, but that's that's that's one of my picks. An other pick that I want to pick is something about Angular. So Angular signals and the new versions of Angular are amazing.
You should you if you have an Angular app, you should totally upgrade and use them. It makes the development experience super great, very fun to work with. So yeah, I want to give a big shout out to the team who worked hard on implementing it. I wanted to also pick a Solid Start, which reaches you know, almost one point zero. I think our CEE now also a team who worked super hard on getting there. So shout out to Ryan Carneato and the team. Oh yeah, Ryan Carneato is
a good friend. We've actually had them on on this podcast several times. So if people are interested in and you know, all the exciting things going on Solid, they can listen to those episodes. We probably should have them on the show again as soon as they finally released version one. Yeah, definitely and totally love this guy. And and also yeah, I wanted to you know, re mentioned maybe some of the stuff that I said QUICKI dot com, with school dot com, all the stuff that you know you need
in order to be successful with Quick. We now had also a big announcement that you know, Quick is becoming more community driven project, meaning that we'll start seeing more activity and more you know, more companies supporting Quick, and you know, lots of the great and exciting things that you know, our community members have been asking for quite a while we now to to see. So we're now we're now doing all the stuff that we're waiting to do.
So yeah, exciting times and I can't wait to see what the future bring us. Good luck. So Shi, thank you very much for coming on our show. I've had lots of fun and you know, thank you very much, and you know, probably have you on again the next time. There's something really exciting happens with Quick, and you know, with all the community effort, probably exciting things are ahead. So thank you very much, Thank you very much. John It was a pleasure. Thanks bye everybody,