Hacker News Reader

Comment by nextaccountic | Hacker News Reader

What do you mean by no hydration? How does the client-side code picks up state from the initial render? (does Qwik apps load faster due to not needing hydration?)

Also, it talks about reactivity. Does it means it has no vdom? Is it related for no need for hydration?

View on HN

Resumability is still a kind of hydration, I suppose, but it's so much more efficient that it makes sense to separate it from hydration and just say it's "no hydration" same as some frameworks advertise "0kb js" when what they mean is just a kind of progressive enhancement that still includes js.

There is no vdom on Qwik, it is kind of a requirement for fast hydration / resumability to not have a vdom – otherwise there is only so much optimisation you can do when you need to convert all your server-rendered markup into a vdom representation.

Qwik does use a virtual dom: https://github.com/BuilderIO/qwik/blob/3ac5665141208ccfac04f...

My bad, you’re right it seems they’re currently using a vdom; I suppose this is something they’re looking to get rid of before 1.0 since I’ve seen they’re implementing signals for reactive updates (like solid does)

Relationships between components and the app state are serialised along with the html. A small (~1kb) library is used to lazy load javascript as the user starts interacting. The key is that it's immediately usable, you don't require a client side re-render before any of the buttons work, for example. This means you can get great PageSpeed scores really easily and the apps feel super responsive.

I have no affiliation with Qwik, but I did try it out on a small project yesterday to see how it works. I'm really impressed so far.

It is true that a button's click event can fire before a client re-render. *However* if that event changes state it does have to do a initial VDOM render to make a first frame before a second one to work how to change the actual DOM and the UI. and although that click event does run it needs to be redirected to the actual event handler. That redirect needs to do downloading, parsing and hydration. So "immediately usable" and "super responsive" are a stretch here...

There is a service worker that will prefetch all of the event handlers currently in view. So when the person clicks on the button, the browser will fetch the JS, but the service work short circuits that request and returns the JS instantly. They have plans to make the prefetching even smarter by gathering information on which chunks are most used and prefetch those first.

Ah I didn't realise it did that? The homepage still makes several references to lazily downloading JS?

Eagerly downloading JS is something every framework does though and many only download for the current view through code splitting for the current page. It doesn't fix the later two problems..., struggling to find any benefits above existing techniques here :/

Reply on news.ycombinator.com