I just got curious about Qwik, so I just started to read and research this new framework, so let's take a first look at it.
Qwik brings an entirely new rendering paradigm to the table called "resumability", which eliminates the need for Hydration.
Hydration is the technique used by almost every framework in the community to make server-rendered websites fully interactive.
To understand what makes Qwik special, we need to understand the current problem of existing frameworks, the key to a performance lighthouse score is to use less JavaScript, but the problem with web development is that to implement the features your customers want you need more JavaScript but to make your site fast you need less JavaScript. This reminds me the "The chicken or the egg causality dilemma".
In almost every existing framework, you start with a big amount of kilobytes of JavaScript out of the box, let's take for example a react app application, you will need react and also react-dom and then you start adding your code, and this size starts to increment, the size will scale of based on how much your application code you have in the page.
Another reason for this slowness is because on the initial page load the frameworks need to hydrate the DOM and rebuild/bootstrap the entire component tree from the ground up, it's like watching a movie that can't be paused, if you need to restart the application by hitting the refresh button in the browser, it needs to re-execute all the JavaScript from the beginning to get back to where it was.
Frameworks like Astro.js has recognized this problem and use a technique called "Partial Hydration", to selectively hydrate the DOM, but Qwik cuts out hydration altogether, like is not even necessary, it delivers instantly interactive HTML, which means in theory you should be able to get a perfect lighthouse performance score, no matter how big and complex your JavaScript code base is.
That sounds too good to be true, but how Qwik solve it 🤔?
The key innovation here is that a Qwik app can be fully serialized as HTML, in other words at any moment you can hit the pause button and capture all the data and closure in the application and represent it all as an HTML string, that's huge for server-side rendering because by the time that HTML gets to the browser, it's just pick up where the server left off without needing to execute any JavaScript at all and that's what they coined the term "resumability".
Another thing that makes this magic possible is lazy loading which is built in as a primitive part of the framework. To understand it, let's look at some code, at first looks like a react app that uses functional components and JSX, but what's the deal with this dollar sign? It represents a lazy loaded boundary and what you will find is that everything is lazy loaded and that even includes things like event handlers that are close over the state of the application, that's kind of crazy because how does this chunk of JavaScript know the state of the application? if it's lazy loading.
You can see in the network, we will found zero JavaScript on the initial page load and the JavaScript will be loaded until we click the button and it contains the code we want to execute and also has access to the lexical environment to update state that might be share by other components, which itself comes from another lazy loaded chunk.
The takeaway here is that you don't need to load any JavaScript until the user interacts with the UI.
If we take a look at the build result of our application, you will notice a ton of tiny chunks, less that one kilobytes each, instead of a single large bundle and because of that, Qwik can scale infinitely and you can add more JavaScript to your app and it will create another tiny chunk.
This was my first look at Qwik and I have to say that I really like the approach and will like to try it more with more complex use-cases.
Resources
Thanks for reading.
Top comments (0)