Qwik vs Angular
How Angular fares in comparison to Qwik when it comes to Resumability, Progressiveness, and Reactivity.
In this post, I would like to compare the top three concepts in Qwik “Resumability, Progressivness and Reactivity” with Angular.
First things first. What’s Qwik? Qwik is a frontend framework specifically designed for not only optimising the initial load performance but also the amount of JavaScript that has to be loaded in order to be interactive.
Resumability
Qwik does not use hydration but resumes the processing that has already been done on the server, on the client. Therefore, Qwik apps are instantly available, without downloading all the JavaScript of the current page.
That’s pretty awesome. Why? Because all the other frameworks need to not only download all the JavaScript of the current page but also execute the templates, and rebuild the listeners as well as the component tree.
To put it in a nutshell, with Qwik the work that has been done on the server can be resumed on the client. It is like a VM image that can be transferred and executed on some other client. How does this work exactly? Qwik serializes the data and puts it in the HTML. Thus, Qwik has to specifically make sure that everything is serializable.
So, what does Angular do regarding this topic?
Angular supports destructive and non-destructive hydration. What’s destructive hydration? The DOM generated by the server gets destroyed and the whole component tree will be re-rendered. That’s a first approach, but not the best one. Therefore, Angular has introduced non-destructive hydration with Angular 16. So, what’s non-destructive hydration? With non-destructive hydration, the HTML generated by the server can be re-used. This means, that the DOM will be traversed, event listeners be attached and the data bound to the component tree.
Progressivness
Qwik only downloads the bare minimum of JavaScript that is necessary for the current page. Moreover, just 1Kbyte of JavaScript is needed to be interactive. All the other parts are downloaded on demand. As a result, as soon as the user clicks on a button, the necessary JavaScript to handle this click will be downloaded. In the example beneath, the Closure within the onClick will be downloaded. How does Qwik know which parts have to be lazy loaded? All parts that have to be loaded on demand are specified with a $-sign.
Which concepts does Angular use?
Angular does some research on progressive and partial hydration. Therefore, not a large bundle but several small ones would be downloaded, similar to Qwik’s approach. However, time will tell, when and what Angular adds to their core. So we have to wait for the next Angular versions.
What should we do in the meantime? Well, there are service workers, which would be the first step to creating a progressive web app. Angular also provides a schematic for this approach.
Reactivity
Qwik uses Signals for fine-grained reactivity to update only the relevant component templates.
How does this work?
Qwik does not use registrations of listeners or a compiler, but proxies. The proxy creates serializable subscriptions and uses this information for the re-rendering. In the example beneath, useStore creates such a proxy. As soon as the user clicks on the button, the proxy notices the state change of count, invalidates the Counter, downloads the rendering function and re-runs the rendering.
How does reactivity work in Angular?
In Angular with each change, the component tree will be traversed from bottom to top and the affected components marked as dirty. Then Zone.js kicks in and executes a tick, which re-renders all the previously marked components.
Therefore, in Angular, we have coarse-grained change detection. However, we will get signal-based components and fine-grained change detection in future Angular versions [2].
Summing up
Qwik homogeneously combines server-side rendering (SSR) with the rendering on the client. Only the bare minimum of JavaScript necessary for the current page will be downloaded. Therefore, the initial load performance is extremely quick. Only 1 Kbyte of JavaScript has to be initially downloaded.
Angular, on the other hand, provides mechanisms to optimize the bundle size and create progressive web apps, however, one might manually add or implement these parts. Moreover, non-destructive hydration is a great feature and optimizes the initial load performance. However, I am looking forward to the research on progressive and partial hydration.
💡 As an aside, for big Angular projects or even for migrating your old Angular codebase, consider using tools like Bit to apply a composable approach to developing your apps with independent components.
Learn more:
Qwik has some awesome concepts, however as Miško Hevery, creator of AngularJS and Angular, is one of the minds behind Qwik, I personally find it strange that the syntax is so familiar to React and not Angular.
Hopefully, Angular will further improve the Developer Experience [3] and add some of the great concepts in Qwik to Angular’s core. However, I must say that Minko Gechev and his team have done a great job with all the new features available in Angular 16.
Links
[1] https://qwik.builder.io/docs/concepts/resumable/
[2] https://blog.bitsrc.io/rethinking-reactivity-in-angular-3bbe69a5a173
[3] https://blog.bitsrc.io/developer-experience-dx-in-angular-dbc2c06b9fb8
Build composable Angular apps with reusable components, just like Lego
Bit is an open-source toolchain for the development of composable software.
With Bit, you can develop any piece of software — a modern web app, a UI component, a backend service or a CLI script — as an independent, reusable and composable unit of software. Share any component across your applications to make it easier to collaborate and faster to build.
Join the 100,000+ developers building composable software together.
Get started with these tutorials:
