Qwik, O(1) Scaling for Frontends and Frontends
Qwik, O(1) Scaling for Frontends and Frontends
Frontend frameworks, and SPA's in general, trade great DX against poor UX in terms of loading time and performance. But as frontends scaled, the DX benefits also suffered because, as a monolith, it became difficult to isolate sections of the code to enable teams to work in parallel without impacting each other.
The new generation of frontend frameworks solve this problem by using a fundamentally new paradigm called Resumability and leveraging HTML, blending the lines between SPA and MPA
1. Current frameworks scale linearly, future is constant.
2. Business can deliver massive amounts of interactivity without hurting performance
3. Developers can focus on authoring component without worrying about the performance
4. Microfrontends becomes trivial, allowing multiple apps to be deployed and build independently.
5. Partial hydration of React and other frameworks
This paradigm shift aims to build extremely complex applications that scale without performance degradation and negative trade offs of developer experience, this is part of our mission at Builder, where we want to allow businesses to ship fast, extremely complex and performant sites.
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 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.
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.
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.
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.
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.