I feel like generally a LV app doesn’t have much JS since you – by intention – push that to the server.
In my apps, the largest blobs of JS are other libraries and liveview.js. You’ll always need lv.js but other libs you could pull in dynamically. My own JS is generally pretty small, flip some classes, smush some local storage, etc. The markup size alone probably dwarfs it most of the time.
You could build a loader into your hooks if it were that important, depending on what they’re doing and just have tiny shims on load. The hooks have to be present on connect but the code they run doesn’t.
I played with QWIK the other week and didn’t get far into integrating external libraries but I think it can tree-shake and async load them in the prescribed style. Though some libs shake better than others so its probably a bit of a roll of the dice on that vs your components which are all in QWIK-space.
My understanding is there are a lot of smarts in the background/build process doing/setting all that up though. It’s not just a matter of grabbing blobs on demand, it’s creating the blobs that’s hard.
I think the best gains are optimising for RTT over anything else, which applies to QWIK too. This is simpler to do for QWIK as you can just CDN the components otherwise you have the same “lv lag” as the component resumes then fires. LV has to have proximal servers (so does QWIK for actual server interaction obviously, you can just fake more locally, simplerly).
I would be interested to see a way to localise component JS to where a component is defined, but it’s not particularly clear what a nice way to do that would be. Some special macro that pushes JS up and out to a build process to dump it into a js file? 
I never really liked writing JS on-the-element like alpine lets you, not for “real amounts” of js.
What I miss most about Alpine is the ability to target local elements without giving them explicit, non-duplicate ids, ie: x-ref. Maybe some way to specify running selectors against el.closest() and el.querySelectorAll() would be good. Eg to: {"closest", "input"} or to: {"chidren", "input"} or the maybe-soon-to-be-spec to: "& > input"? Maybe this would end up as to: JS.selector.closet("input") or something.
QWIK is neat, I like the idea, excited to see what KWIC (or maybe REQWIK?) looks like.
