Downsides to Qwik?
After watching https://youtu.be/tJY1zrW35q8?si=EuiUF6S7hdFPYQu4, I really crave for a more objective review of Qwik including downsides. Theo once mentioned data fetching waterfalls being one such point where the RSC model works better. Do you have concrete points that are problematic in Qwik, besides it being new with little adoption and only few libs available for it? Please no hearsay.
Tony Alicea
YouTube
Qwik vs. React Server Components w/ Miško Hevery: Servers, Signals,...
In this eye-opening interview, I talk with Miško Hevery, creator of Angular and Qwik. We discuss the difference between Qwik and React Server Components, performance, server$, signals, and more. This is a deep dive with lots of important concepts. Enjoy!
Qwik: https://qwik.builder.io
Join us in New York in September, online or in-person!: https...
7 Replies
I have no direct knowledge, but I know of someone who does. I watch a loooot of Ryan Carniato's streams and he often mentions Qwik when comparing it to solid. He did a stream last year exploring Qwik https://www.youtube.com/watch?v=gT5NWKZZPQM
If you want something a little bit more compact he's also got a blogpost on Qwik from that same point in time: https://dev.to/this-is-learning/resumable-javascript-with-qwik-2i29
He's got a great understanding of the entire space of JS frameworks so his opinions are usually very sound. However, since this is from 1-2 years ago, comparisons with RSC's lack the context of them actually existing like they do today
Ryan Carniato
YouTube
Exploring Qwik, the Resumable Framework
We're going to just take a first look at Qwik, new approach to attacking the problem of efficient page-load in JavaScript frameworks. We will play around with samples, build something. And get an idea of what it is all about.
[0:00] Introduction
[2:32] This Week in JavaScript
[14:13] Introducing the Resumable Framework
[34:04] TodoMVC
[47:21] H...
DEV Community
Resumable JavaScript with Qwik
When Misko Hevery (creator of AngularJS) approaches you to look at his new framework, well, you stop...
Thank you, the video was very insightful!
You're welcome! I'm happy it helped even though it wasn't exactly what you were looking for
The code fetching waterfalls are not really an issue with preloading. The thing is if we assume most stuff is preloaded the biggest advantage of Qwik is reduced page load cost from not doing typical hydration. That does come at a cost on the DX side in terms of being aware of serialization boundaries.
Today RSCs and Qwik solve slightly different problems in RSCs is about server side rendered partials .. ie client side routing while retaining less javascript. While quick is only able to load minimal JS initially and then loads the rest as needed.
Honestly I'd just try it and see if you like it. Mostly I'd say tradeoffs come from DX in what is necessary to make Qwik work.
And obviously like any new library small ecosystem. Qwik being the newest is the smallest.
Hey, I've been working on the 𝕏 stack (using Qwik) for the past 6 months and I think I may have some insights on it. I'm also a Qwik and qwik-ui (equivalent to radix) contributor.
Pros:
To me the greatest pro of Qwik is that it can lazy-load js bundles automatically by default. This is done in the background (not on the main thread) through the service workers that store the bundles into the browser cache so that they can be retrieved and executed immediately on click. That may sound like nothing, but it means almost 100 lighthouse scores by default at any scale, which means you don't have to manually handle your lazy-loading or deal with the RSC mental model where you need to constantly worry about what's client, what's server, and what's shared.
Then of course, you have signals, which can be a big perf boost in some/many situations.
One underrated feature is
qwikify$ which basically gives you access to any library that's available in React (and Angular; Vue, Svelte and Solid are WIP). This means you can use "react three fiber" in Qwik for example. Your 3D scene would then be loaded as an island (similar to Astro). So in a way Qwik's ecosystem isn't actually that small.
Cons:
Qwik lacks an equivalent to shadcn. Hence why I'm working on qwik-ui (= Radix) and qwikcn (= shadcn) 😛. But you can still use stuff like daisy-ui or bootstrap if you don't care.
Room for improvement:
- <Link prefetch> isn't very well implemented for mobile. It will prefetch on hover on desktop, but we need to fix mobile. This is potentially fixed by Qwik Insights (but I haven't test it yet).
- It's not possible to lazy-load inside a component since it messes up with the optimizer (that's creating to lazy-load boundaries for you). You usually don't need to though, since the optimizer creates performant lazy-load boundaries for you. But if you need to import many files without writing the imports manually, you can work-around it with import.meta.glob, but it has some rough edges too (docs on that in my PR https://github.com/BuilderIO/qwik/commit/9784ec148b53241ecc8a0599658f8365b1990e28)
- we're currently fixing an issue with vite's library mode that creates some unoptimzed bundling. (this is a concern for library maintainers only and if the lib wants to provide multiple components from the same package).
Other than that, the DX is so much better than Next (thanks to signals and auto-lazy loading).
I haven't had issues with serialization, but I know a few people have. Qwik has noSerialize() for that kind of situations (https://qwik.builder.io/docs/components/state/#noserialize), which seem to be pretty rare.
Also on waterfalls, I haven't heard of many issues. Maybe it's only in dev mode: https://qwik.builder.io/docs/faq/#does-qwik-generate-too-many-small-files
I'd take a look at the FAQ if you want to know more.I honestly don't know if developers will find the serialization knowledge that prohibitive. I mean understanding that crossing
$ is crossing borders. I imagine it is more of a consideration for would-be library authors. They need to get a bit lower level. It is definitely a thing, but it is also something you might not think about much.I think it's not something people worry about until they encounter an actual serialization error. We haven't had any as part of our qwik-ui work, and although we are quite some performance nerds that are quite careful about eager execution, we haven't ever been worried about potential serialization issues to my knowledge.