Qwik, O(1) Scaling for Frontends and Frontends

Hi everyone. Today I'm going to talk about Qwick and Qwick as a really interesting property, Qwick can be instant, regardless of the amount of complexity of an application. It doesn't mean that the application is a Hello World. But it's a massive application, which enables instant interactivity. And we do this concept we call or when, or resume ability, which I'm going to talk about later.
Part of my job today is to convince you that we can do things fundamentally in a different way that other frameworks cannot do. So my name is Manu, and I'm a software engineer at builder. I work in the open source team. And before that, I've been building the stencil with a compiler and baking SDKs and API for the last 12 years.
At Builder we want to look at performance in a different way, we don't want to look at the typical performance test where we are in there 1000 rows and see how fast it can be. But really, how things scale and big for big customers. So in this demo, we kind of build the same application from one component to add to different frameworks and see how the amount of JavaScript that these frameworks had to deliver.
On the right, we see this graph where all the frameworks, all the current frameworks follow this trend. As the application gets more complex, the amount of JavaScript grows linearly. But Qwick is stable. So you just want to dispute it, just this look, or try to get a really the feeling that Qwick is doing something fundamentally different, that little friend was going to do to achieve this kind of performance characteristic. We look at the web and sites are becoming more and more, they need more and more JavaScript. And this is a fact, from this data from web archives. And we see that the amount of JavaScript has been steadily increasing for the last 10 years. But is this really a problem?
Well, we built this tool called performance insights where you can put your website and I'm going to tell you four things. The first thing is your current performance score like Lighthouse score. But also, if you optimize the images, what will be your score, if you optimize the CSS, which one it will be? And then for JavaScript, if you optimize the JavaScript, what will be the score? We actually ran this at scale, and for the 50 eCommerce sites bigger in the US. And one of the things you want to point out in line over here is that pretty much all of them are in the red area, which means that they are actually very slow. And then we'll see what can be done about it. If you optimize, if this website is optimized for images, the performance benefit is very, very small. If they optimize the CSS, very much the same thing.
This means that they are really doing a good job at optimizing these particular parts. Then when we look at JavaScript, the performance increase is massive, we start to see that the bottleneck is that JavaScript is not any other thing. You might argue with me that this is not a problem for your business. And I get you, this might not be for you. But for a lot of companies, especially the one facing customers, it is. Faster websites means more sales means better conversion. And especially when the application gets more and more complex it becomes a bigger problem. I'm going to argue that this is because there is a system correlation between sites becoming more interactive, and the amount of JavaScript and it would be naive to think that we can go back 10 years ago and make the websites without pretty much static websites. Because the business and the users are not asking for that.

The other thing I want to say is that this is a systemic problem, not like some websites are faster, and some are slower. All the applications getting more complex at some point are becoming slower because of the amount of JavaScript. One of our core principles is biller and Qwick is don't blame developers for what they will framework to. And this very interesting concept because the whole ecosystem, the whole front end is full of best practice. Your developer should do this in react. You should do this in a different way. That's why it's very slow. But it's not true. Frameworks or leading developers to these bad patterns. And sometimes frameworks itself have this, they are the bottleneck. And that's what is happening literally, the current trend is linear is going up because the current frameworks are ON, but we can do something about it. What if the frameworks were 01 we can immediately blame this relationship. So you can do business and users can still keep building more and more amazing websites, interactive and complex without real meaning that the performance is going to get Everest and worse and worse.
At Qwick, we solved this with fundamentally two main things which resumed mobility and progressiveness. To understand that we need to kind of get a feeling of what's the problem today. So, current frameworks really started as SBA, they started to think that the framework that is going to execute in the browser is going to do its thing. And the user will interact. At some point later, as an afterthought, you were like, actually, is it good to arrive in the server for SEO is good, because you send the HTML already made? So it's visually instant, that this HTML that servers send is that you cannot interact with it. Because frameworks were not thought about.
The framework executes in the server, mix HTML was what is happening here, send this demo. And at that point, the browser needs to hydrate, which means like adding the listeners, adding life to the HTML to interactive, remade the state, that means you have to replay everything, you have to download all the components in the page and replay all the logic. And at that point it is when these are interactive. Resume abilities, they take this concept, which doesn't make any sense, and do something like you know what it's logical, it's like you're watching a movie, you stop the movie, and you can just continue, you don't have to go from the beginning. So this is what is happening in Qwick, is like a virtual machine, that the application runs on the server is paused, sent to the client with all the server license state. And the application resumes instantly and executes without having to do all this work.
I love this analogy from the CEO of Builder. And what's happening right now is that, using the server side cake baking analogy, the server is making a cake and making a case preparing everything. But instead of sending the cake to the user, it's actually taking a screenshot or a photo, sending the photo with instructions. And when the user gets up, it tries to bite it, but he's like, come on, it's like a picture. It's not an actual cake, right? The browser needs to go to the first ingredients, bake the cake again, compare it with a picture and say, Okay, now you can interact, now you can eat it. And this really doesn't make sense. And in the future, more and more frameworks, solving this. We are in this state, not because we don't know better but because it's a learning process. Right? In the past, it was actually very performant. But it was a problem, right? We're not going back to that. At the beginning, we have maybe you use PHP or Ruby on Rails, you render stuff. And then you will use jQuery to add interactivity. That was actually very performant. But it has this low development error prone duplicated logic, it was not good for developers.
So then the system generation was like, no, let's make it amazing, let's make it easy to website at scale in complexity. And that's what Angular view as well as react does, we have a unified model, you don't have to build an application in different silos. The problem is that all the server side is an afterthought, the nice hydration, the application needs to run twice. And the future which Qwick includes some other framework like Marco, which is also giving a talk in this conference. Following the same ideas not going back to your query is following the same ideas of when you find a model, but then solve the problem of the double rendering, which is solved with persumability.
I made a lot of claims here. So I'm going to show you. And let's start with some of the principles and super simple, Qwick application. So I'm going to show here, and here we see. I just have a world and we take the HTML is just HTML, there is no JavaScript, this I guess it's not impressive. At least we'll start to put some JavaScript here. If I put console log and say render, we will see that the console log is here, but only mean the SSR means that this console log comes from the server. It happened here it paused and nothingness security neckline. Again, not very impressive. But let's put some events. So I'm going to put the on click. And I'm going to say I want to put console lock. Click. So what we see here now is that it's realized this special new attribute. And not only that it injected the SPS of JavaScript, but specific JavaScript is fixed is always less than a kilobyte. It doesn't matter that they have a million components or just one right, it will only render that so let me just put it back on, and know what happened there. So if I do that and I interact with it.
Nobody's wrong, the click handler runs in the client, but not the SSR. This code never even runs the client, never. And you may think that this is easy, right? And this is actually what is happening here, the optimizer is taking this code, and it's splitting it into small chances. So we have this one, which is the click and the rendering. And, but what if we do something like const, and he puts some variable? So Manuel, my name, and I put it here. And then I'm going to click. And it works. It says click, Manuel. But again, it didn't execute this code. So that's weird. How is it possible? Well, the optimizer and kind of the innovation here is that we can realize closures, which is what allows us to write code like in React, but we have the scalability of the restroom mobility of Qwick.
We're going to go into focus because we have a lot more to talk about. The next thing is Micro front ends. A Qwick has a very interesting property, Qwick is HTML centric, it doesn't depend on execution of JavaScript, it doesn't depend on the state that lives in JavaScript, that allows Qwick applications to be composable. At the document level, you can have several servers generating different parts of HTML being combined to a single document. And everything works. Because every Qwick application is a container. It can be built by different teams, different versions of Qwick and less, less blurred. So you have this app. And you have this demo called container. So containers is a demo that we will use in collaboration with Klopfer. And see all these links, they are actually independent applications, there's an application that comes from this worker, and H worker, that's the footer. This one is the body. And I believe this is the header, right?
So all these applications are interactive by themselves. But at the same time, if we look at the code, we can put them all together in a single application, and it looks like this. All these applications are being combined at the document level. And the thing that is worst is that all these containers live here, actually, they can be nested, you have the body container, and inside the body container, there will be this one over here, which is another container, which is worse compiled by this version of Qwick. But this one was compiled with a different version of Qwick. And not only that I can interact with this container, and notice that they become resume, while the previous container, even the parent one still pause, didn't download any JavaScript.
And I'm going to show you this. So if you open the Network tab, we refresh. There is no JavaScript. And when I point this out, it even works with JavaScript disable. So if I disable JavaScript, and refresh. All this still works. And they are coming from different workers that you can deploy by independent teams. Let's go back. Another thing we had with data driving bundling. In Qwick, you will notice as here that I want to specify how this is handled, I don't have to write manually Dynamic Input. Developers don't have to change because it's impossible for the developer at scale to know how an application is going to use, how application needs to be bundled, instead, Qwick by the for the splits everything as much as he can. It mixes as many entry points as possible. And I'm going to show you how we can actually use data driving, getting real traffic information from the website to re bundle and re optimize the thing.
So, we have the doc site. So I'm going to show you the docs. So this application went to open on incognito, so it doesn't cache and I want you to see several things.
So the first thing that's happened here. Let's put all this demo and let's do it again, right? Because as usual the frickin demos is a pain.
So another very interesting thing that we can do at Qwick is data driven bundling, you will notice from the code here that developers don't specify how applications are bundled, they don't have to manually write dynamic import and make the bundles because this is a really a very hard problem to solve, especially when application gets very, very complex. Instead, what we think is that this bundling and these professions would be driven by traffic for data driving bundling, that means using real traffic information to rebundle the application, and when this optimization, different layer, so I'm going to show you this demo, we have the dark side and the dark side going to open incognito and put it here. I'm going to open the dev tools first. And I'm going to pay attention to something that happens here.
In the dev tools, you will see that there is some downloading JavaScript, but this is a prefetching. Notice that the code has been downloaded for the ServiceWorker. Why are we doing this? Well, we are doing this because we want to have instant scalability, we can detect when this code is needed. So when we interact with it, the code was already cached by the server. But let's find a case where the performance was not very good. So I'm going to clean this and I'm going to interact with the search. Notice that he had to download a lot of code and this interaction requests so many little chunks. And after running testing, we find out that we don't have to do that.
So in Qwick, you will see that all the little symbols come with this hash. So a dealer, we collect this information we generated. This is going to be automated, but for now, for demo purposes is just automatic. So what we are doing here and I'm going to stop it and re-bundle it. We are saying look at these symbols, they actually belong to our goal here. They are all together. So let's see what this looks like. We're going to close this and see when he's ready. I think he's ready already.
Okay, so now, when I interact with it, it only downloaded three files. And all these three files were already pre cached. So you will have instant interactivity. Notice here that you didn't have to change a single line of JavaScript, the print still says something like even like a different thing can do. So it's very, very cool at scale. Some of the other things I want to show is that Qwick can do. It's not a goal, but Qwick can load react some of the principles and like pretty primitives of Qwick can allow Qwick to partially hydrate Qwick. So in this demo. We have really good Qwick react. We have a three year yes, which is 3d library using react. And you have a canvas, we have some stuff some boxes, and we also have an MUI which has the most popular react component library for react and having at the bottom here and pay attention to this we have this Qwick Ify until that converts this React component to a Qwick component.
But the thing is that by converting into a Qwick component, this code will never run in the browser. So I'm going to show you this, it is very interesting. So you just refresh, and there is no JavaScript being downloaded. So let's crawl and see what happens here. We have three years. And nothing really happens here. Why? Because three years actually needs to run, right? You have a three web component every three years using WebGL. So you actually need to hydrate. So by doing this now, when we interact here, I'm going to, we need to also enable JavaScript because we disabled before that's why it was not working. So let's go here, put Network. And still no JavaScript. But as we scroll down, react works and you can interact with it.
Again, you can decide if you don't put the client visible, then this component will always be dead. And it will be here a canvas network. Offering the frameworks all one thing are not new like this is actually an idea that's been around for four years, especially Google's been for eight years, our internal framework called weeds. And it powers the most complex products at Google that require it to be extremely fast. We're talking about Google Search, Gmail, Google Photos, the problem is that to build with it is a pain, you have a deeply capital backing in Java business logic needs to be public, it is not nice. So not even Google uses it for all the projects. Because all one framework is still really hard to build, Qwick solves that.
Amazon, the same with Amazon, claimed many times that they cannot use the same frameworks to make the front page. And that's kind of what we are trying to be on Qwick. We're trying to solve these, we try to bring these innovations that these companies, these extremely big companies use for extremely rare projects to everyone. This is an analogy from the back end cap theory. And I don't need to explain it. But basically, the idea is that when you make a website, you want three things. You want capabilities, you want a lot of functionality, tons of interactivity, user customization, AV testing, a lot of things that a business, or application needs. But you also want to be fast, because that actually leads to sales, better UX. And not only that, you want your developers happy, you want to be able to build Quickly iterate. And the idea that in real businesses, I'm assisting a lot of these because we built over for real businesses. Websites are not only owned by developers, they are also owned by marketing by designers make the chain so this part of this.
Right now you cannot have all of them. If you choose performance and capabilities, you will be neglecting the nice to build API. So you will have something like the query plus, so every customer stack, that's what Amazon does. If you want API plus performance, then you will lose the capabilities, you will have something like MPAs, Astro eleventy. And if you want an API that means something nice to build is to be out and capable you will have next year's view Angular, but you will destroy the performance on scale. What we solve as a biller is how we can have all these things because real businesses cannot only care about performance.
So our current stack is biller is this tool that companies can use to integrate with the resistance stack. That means like react application, react components, and allow all hands development. Not only that, but integrate extremely efficient AV testing user personalization's. That means that they want to sell different contents for people in different regions, or if they're male, or female.
And then Qwick is our solution for first party code is how you put all this complexity in application and still can be fast. And in the third place, you have party down, which is also real business, they need third parties. They need Google Analytics, they need metrics, full story, all these things that they slow down your website. So party time is our solution to put it in a web worker, but being able to run transparently. And for us, that's kind of the whole vision like how will this thing work together to achieve and solve a problem that previously was unsolved? So thank you very much. And please I'm available at Manu Martínez Twitter so please follow me and ask me questions whatever you want.