[simonhorlick]

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.

[kaleidawave]

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...

[meenie]

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.

[kaleidawave]

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 :/