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,