Evolution of Client-Side Frameworks

[00:00:00]
>> How did we build websites in the past? And I think this is kind of a good history lesson. So in the past, we build websites by using a server side technology like PHP rails. I'm not picking on any of these, right? There's a lot more out there.

[00:00:13]
I'm just saying we use something other than JavaScript to render on a server. And then this actually turns out to be very performant, because the browser just had to show up HTML. There was no JavaScript, and so this is pinnacle of performance, right? The problem is it's not interactive.

[00:00:29]
And so people introduced, basically, jQuery to add interactivity. And this actually was a good solution in terms of performance and the user experience, cuz it was fast, but it was not very good in terms of developer experience. And the problem here is that it's very error prone and you basically have to know multiple languages.

[00:00:51]
And not only is it error prone, but you actually have to oftentimes write the same thing twice. So if you go to a page that shows a list of contacts, the PHP or whatever the server side technology you have has to know how to render those contacts. But then in the client, you wanna be able to add a contact.

[00:01:07]
And now you have a problem of, well, now I have to do the code twice, once on a server, so that I can render the contacts initially, and then in the client, so that the jQuery can add a contact on a client. So now I am basically doing the same thing twice.

[00:01:20]
I have to do validation twice, I have to do rendering twice, I have to do data binding twice, and so this is error prone. And so with current set of technologies, it was all about developer experience. Like, let's improve the developer experience. And so the approach we took with all of these frameworks, and Angular was one of the first ones, I think, was the idea that you have a unified model, meaning, both server and a client are same code.

[00:01:50]
Actually, all these frameworks basically started with saying, let's just do everything on the client. Forget the server, let's just do everything on the client. And then as an afterthought, they said, well, there's a problem, can we do some of it on a server? And because this was an afterthought, it never really lived up to its potential.

[00:02:10]
But the nice thing about this particular world is that it's all just JavaScript. You have no code duplications, there's a unified mental model, everything is in a single framework, but you have this problem, that your application runs twice. It runs once on a server to generate the initial HTML, and then it runs again on a client.

[00:02:30]
And if you think about it, the HTML that was rendered on a server, that HTML can be thrown away because when a client reruns, it will rebuild everything, right? The HTML that came from the server was only there for you to kind of look at something while the page is kind of being loaded.

[00:02:48]
And so we're kind of having this, basically, the problem with this particular world is hydration. Because in order to become interactive, we need to run hydration, and hydration is basically rerunning the whole website from scratch, right? Yeah, we can reuse DOM nodes, but it turns out that if you deleted the HTML, the framework was just recreated.

[00:03:13]
So yes, it can sort of reuse it, so we use fancy word like reconciliation. But at the end of the day, the DOM nodes are unnecessary. If they're not there the framework just recreates everything from scratch. And so, the good mental model is basically, yes, HTML showed up, we're gonna throw it away and we're gonna rebuild everything in the client.

[00:03:31]
And that's exactly what's happening. So what does the future hold? And so, this is where, I think we have a good developer experience, but we need to get better at the performance. And so, the future, in my opinion, is all about keeping the DX we have, but adding a good performance to it.

[00:03:51]
And again, when I talk about performance, I don't mean the runtime performance. I don't mean the performance in a sense of the solid JS, which is one of the fastest frameworks out there. I'm talking about a startup performance. I'm specifically talking about, how long does it take for a user to click on a link and then seeing what they wanna see, the site that they wanna see, and being able to interact with it, right?

[00:04:14]
The problem we have is not how long does it take to add a thousand items in the shopping cart, right? Because most of the benchmarks are like, add 1 ,000 items into something. That's not our problem. The problem is, we can't click on that button to add a single item into the shopping cart.

[00:04:31]
Okay, so there's a couple of frameworks out in this category that are worth talking about. And obviously QUIC, which is kind of what we're talking about today, but turns out eBay has a framework called Marco, which they have not done very good job of kind of telling the world about.

[00:04:47]
But Marco version 6, which is just about to be released, apparently has hydration. I've spent a lot of time chatting with my friends at eBay, and they're doing a lot of cool stuff in that particular department. And they are approaching the hydration story that the Qwik has as well.

[00:05:04]
And there's also Google Ways, Google Ways is an internal framework that is not public.
>> Is this form a first visit perspective?
>> Form of what?
>> First visit perspective, as far as the boot up time.
>> So, everything we talked about for startup performance is both for the first time visit and the subsequent visit, right?

[00:05:24]
So, the first time you visit, obviously, it's a little slower, because you have to download the JavaScript. But the issue here isn't the download of JavaScript, the issue here is the execution of JavaScript, right? So while the cost of the Javascript download might be on the order of, I don't know, a second or two, I'm just making up a number.

[00:05:45]
The execution might be on the order of multiple seconds, like ten plus seconds, right? So even if you do a subsequent visit and, of course, this time you can skip the download of Javascript, it's not gonna make a huge performance impact.
>> And then they're asking about, what about frameworks like Astro and Eleventy.

[00:06:04]
>> Yes, so those are good questions, what about frameworks like Astro and Eleventy? So, frameworks like Astro and Eleventy basically say they wanna move away from JavaScript as much as possible. And their point is, how about we just don't have JavaScript. So they're kinda going back in past.

[00:06:24]
And the point I'm trying to make with Qwik is that like, I don't wanna give up on the amount of JavaScript we have, we need that JavaScript, but we just don't wanna download it all up front. So the way Astra, for example, deals with it, is they break the application into, Those islands, and then they can lazy hydrate those islands.

[00:06:43]
So with Astro, the debate isn't about the amount of JavaScript that needs to get downloaded, the debate is about like, when exactly am I doing the hydration work? So you're pushing the hydration work into later point in time instead of doing everything up front. So a framework like Astro, the debate is about not if I'm gonna do hydration, it's when am I gonna do the hydration, right?

[00:07:09]
That's one point. The second point with frameworks like Astro is that, because they break up your app into small islands, these islands are essentially independent applications. And now you have to have an inter-island communication problem that you have to solve. And so, I don't wanna think of my application as many, many small applications, I really wanna just think of it as an application and I want to just be able to do all of this stuff.

[00:07:33]
The other point is, with Astro, you actually have to set up your islands by yourself and kind of do everything. So it is definitely a step in the right direction, but I don't think it addresses the application problem space that we're trying to address over here. And I wanna point out that we are not the first ones to think about this problem this particular way, there were others before us, right, and I wanna give credit to them.

[00:07:55]
And the biggest one is Google Wits. So every time you go to Google Search, the Google Search page is actually running on top of Google Wits. So the framework that the Google search page is built with is Google Wit. And part of was our open source. So for example, one part is called JS Action, that thing is open source.

[00:08:12]
There is a, templating system is open source, so it's not all of it is proprietary, some of it Is open source, but kind of the most bits are proprietary to Google. Now what's interesting about Google Wits, is that if you go to the search page, first of all, you will all agree that Google is amazingly fast, right?

[00:08:34]
Second thing is, you cannot get into a situation where you wanna interact with Google search which page before it's ready? Like that just doesn't happen. And the last thing I want to point out is like people often says like, Yeah, but it's like a search page. It's like simple.

[00:08:48]
I'm like, have you looked at that thing? Like if you put in like, a plus b equals seven like it shows you a graph. You know, if you search for a movie, it like shows you a movie listing and then you can scroll Through the carousel. Like, there's different queries.

[00:09:03]
If you search for an address, there's a map that's actually scrollable in there, right? There are pretty complicated use cases hidden inside of the Google search thing that is powered by Wiz. Now, Wiz was built about 10 years ago. And. The ideas are kind of similar, but the way it actually works is quite different and one of the things about Wiz is that because of historical reasons, because we built ten years ago, or about a decade ago, the developer experience is not the best, right?

[00:09:36]
But the end user experience is amazing. Right. And so the thing that we want really is how do we marry this? How do we have an amazing developer experience that we're so used to, but how do we have this performance that we want? Right? And so my argument here is that the future is about having both a good dx and good performance.

[00:09:57]
And so how do we merge basically, the rendering and inter Interactivity into a single framework, which is the DX that we have before and have a unified mental model, right? Which we talked about about how there's one state and all the parts, but kind of we only run the app once.

[00:10:12]
We don't have the problem that when we show up to a particular website, there's this huge amount of JavaScript we have to execute because a huge amount of JavaScript Is what's killing us, right? And and the problem is you can't optimize. You can't make it to execute the JavaScript faster, that's not a thing we can do, yes.

[00:10:28]
>> Yes, I have just one question, how do you see the MFA architecture, which is in trend these days?
>> Yes.
>> I mean, complex e-commerce website has multiple MFA and then-
>> Yes, I think that that's a great question. So, microphones are, I think are super cool, we can actually get tomorrow into, I have an awesome demo of building a e-commerce website.

[00:10:51]
And that demo is made up basically of, the header gets rendered on a separate URL, the the hero section gets rendered separately The shopping cart gets rendered separately. And then it all gets assembled into one piece. And then the nice thing about it is that Quick is really good at hosting multiple, essentially Quick containers, we call containers, on a page.

[00:11:12]
And the Quick knows how to wake them up in the correct order and how to interact with one container before the other container is ready. And so. All of those things are things that Quick is kind of almost made for. And the reason for that is because Quick App can be serialized into just HTML.

[00:11:29]
And because it's just HTML, it's really easy for a microphone to just concatenate a bunch of HTML together into a final product. Something that's not possible with existing technologies because existing is a mixture of JavaScript and HTML and CSS and loading strategies and order matters and all of these things, and becomes kind of difficult.

[00:11:49]
And so quick makes it easy.