Qwik introduction
Modern frameworks face a big challenge of performance, they are not on top of what companies are looking for.
Some of these frameworks have adapted performance as the real utility of them, for example, Svelte, but none of them have reached the real expectations because they are looking to make web apps faster in the run-time, but no one is looking for the source of the problem.
Here comes Qwik, which adopted a different approach, the focus shift from "doing faster" to "doing less”. It’s a key difference that will change the game. Ultimately, the fastest tool is probably the one doing the least amount of (repetitive) work.
Qwik is a framework created by the creator of Angular, Misko Hevery, with a collaboration of Adam Bradley, who created Ionic, and Manu Almeida, who created Gin Framework.
These are pioneers of web development. I don’t think we are dealing with just another javascript framework. Maybe we should be prepared for a new framework that will change the paradigm.
Why Qwik?
Qwik comes with a clear goal: achieving top performance, perfection, 0 javascript, and pure HTML. Yes, we are here. It’s time for that. Qwik is trying and also succeeding to go beyond what other frameworks can do.
The last framework that came with a new concept was Astro, which introduced partial hydration, a revolution in javascript frameworks.
For example, if we have a page that starts with a text that does not need javascript, we load nothing, but if we scroll down to a component that needs javascript for the interaction, we hydrate the page with the needed javascript.
Qwik killed the game, with no partial hydration but zero hydration and 0 javascript on the first load.
For instance, if we have a form contact at the bottom of a page, Angular, React, or VueJS will load the javascript needed on the first load, Astro will load it if we scroll down, Qwik will load it only and only if we click on the send button of the form, it loads javascript not when we have the form in front of us but if we interact with it.
Qwik key concept
Qwik, the HTML first framework’s philosophy is clear: make the fastest possible time-to-interactive (to do it faster by doing nothing).
The framework delays the invocation of the javascript as much as possible and invokes it only what is absolutely needed. The focus is on the first load.
As such, it only loads pure HTML. To achieve this, Qwik is based on an important concept. In this paragraph, we will dive deep into it.
Resumability
The modern frameworks now compete to improve hydration. Qwik is unique in that it has resumability.
The name of the concept gives us a perception of what we are talking about, “stop/resume,” resume the application where the server left off in place of replaying all of the work.
Serializing event handlers is the key to stopping and resuming the application. But doing this is not something new, we did it before through jQuery.
For example, using pure javascript. The difference with Qwik is that working on Qwik is like working on React, it has adopted the modern DX.
If we try to think deeply about the figure above, we will understand the reel problem, scaling. If we have an extensive web application, it will take a lot of time to load with hydration.
Even with Partial Hydration, it will be challenging to scale, Qwik with the resumability only loads HTML, which does not take a lot of time.
It’s a fraction of a second and you have your application loaded in your browser.
Prefetching
To be precise, Qwik will not download every file only when you click, but after doing the first load to show the page (that is interactive), the framework will start automatically downloading the code necessary fo the web app using a service worker, and it will store it in the browser's cache, so we will not send a request to the server every time, but it will grab it instantly from the cache, if the code is not downloaded yet it will download it from the server, and that's what we call prefetching.
So when we say "load the javascript" we are talking about getting the JavaScript code from the cache and executing it only when we need it, other frameworks download and execute the JavaScript code in the first load, and that's what cause a lot of performance issues. Qwik is interactive from the first load without the need to wait for all the javascript to be downloaded.
Qwik City
On the 1st of May 2022, Hevery said in a podcast that their goal is building a router that offers the capability of doing MPA (multiple page application) routing with the benefits of SPA (Single page application) routing. In other words, doing MPA rooting without refreshing the page.
Only render the parts that need refreshing. That may sound like fiction, but it’s already done, they did it, and its name is Qwik City.
So Qwik is a mix of server-side rendering and client-side rendering. It takes advantage of the two of them.
Qwik City is the meta-framework designed for Qwik, like Next.js for React.js. The routing in Qwik City is so simple, it’s based on the structure of our directories in the routes directories.
src/
└── routes/
└── some/
└── path/
└── index.tsx <https://example.com/some/path>
With our 0 javascript meta-framework, the application is loaded without a single javascript dedicated to Qwik city, but there is more than that. It also offers:
- Directory-based routing
- Nested layouts
- File-based menus
- Breadcrumbs
- Support authoring content with .tsx or .mdx file formats
- Data endpoints
Conclusion
Modern frameworks download all the javascript, and after that, they execute all of it.
Qwik downloads a little bit of javascript, and it doesn’t execute it until we need it. The framework is changing the mental model.
We think that Qwik will be one of the pioneers in the JS frameworks. It has improved startup performance, which is a real problem of modern frameworks, but with Qwik, it’s not the case.
Let us see the future and stay tuned because this is our first article about the framework, and of course, it’s not the last. In the coming articles, we will dive deep into the core concepts, and we will do some examples of building Qwik applications.
This article has been reviewed kindly by Mr Havery Misko (The creator of Angular and Qwik), we thank him a lot for his contribution.
Top comments (9)
Just my two cents, but (at least for the time being) I view this more as a modern static site generator with good support for client side interactions, than as an alternative to frontend frameworks. Yes, there are similarities in terms of form factor, with code looking (for better or worse) similar to React - but the execution model is totally different, and that's not just an "optimization".
It seems like a good choice for websites - but doesn't make much sense for heavily interactive applications, in my opinion. You'll only add a lot of network reliance, a ton of HTTP requests, potential delays and instability - for an application, waiting two seconds for it to load and launch is not a problem, and it's more important the app stays fast and responsive once it's running.
For something like e-commerce, where load times are crucial, I'm not even sure if I'd pick this. You would get more control with a straight forward MPA approach, a lightweight UI framework (Preact, Solid, etc.) for interactive areas on the page, and carefully loading what you need, when you need it.
It definitely fills a new niche though - I'm sure there are projects where this might be the best choice. 🙂
I see this confusion a lot about lazy-fetching and constantly waiting on the network. It is not what actually happens. Navigating to the site will caues eager download of all interactions so that even if you loose network connection the site will continue working.
I think that Qwik excells at highly interactive applications. The more interactive the more it shines, as it loads less than CSR equivalent.
Thank you for your comment, it's an old Article that i wrote, i just republished it here, so to answer your question, Qwik will not download every file only when you click, but after doing the first load to show the page, the framework will start automatically downloading the code necessary fo the web app using a service worker, and it will store it in the cache, so we will not sent a request to the server and wait 2 secondes every time someone click on a button but it will grab it instantly from the cache of the browser, if the code is not downloaded yet it will download it from the server, to have details here is the explanation of how this prefetching works: qwik.builder.io/docs/advanced/spec...
(just updated the article with that part)
Yes, effectively a re-implementation of browser native prefetch - this optimization is available to an MPA as well. 🙂
We tried prefetching, but it did not quite work, and so we had to build the Service Worker builder.io/blog/code-prefetching-i...
Nice
🙌
Qwik excels with the e-commerce constraints and high interactivity apps – and more than any other SPA/meta frameworks I've been working with the last 15 years.
If generating static content is an option, it's not its strength.
Also, it won't play nice with offline mode.
🤷
The latency of downloading chunks happened to be an issue to me, that was during its beta though. First/ since then, the pre-fecthing strategies improved well. Second/ new paradigm new way to reason about.
It's still at its early stage, so there're obviously things to polish.
💎
That being said, reaching 100% to lighthouse with no effort is very profitable.
Running seamlessly backend and frontend code is also very profitable.
Nuxt and Next are still behind regarding the code extraction and resumability – despite being backed by huge communities and companies.
I'm quiet excited about that piece of technology!
Сongratulations 🥳! Your article hit the top posts for the week - dev.to/fruntend/top-10-posts-for-f...
Keep it up 👍
Article could use some editing.