lazy loading and resumability ala qwik

[tzual]

consider adopting ideas from qwik framework.

leverage seralization on the client to enable:

• lazy loading components - makes the app a lot faster to start
• resumability between sessions - better user experience

i believe qwik is bringing some inovative ideas into the web app world and since this project is still in early development you can still possibly incorporate them.

[gbj]

Oh, totally! In fact one of the reasons the reactive system in this library uses index-based arena allocation is that it means the whole reactive system can be serialized and deserialized.

I've experimented in the past with Qwik-style resumability in Rust. The main blocker right now is the Wasm bundle splitting story, which is not great. There's been some progress with the wasm-split tool from binaryen recently, and talk of integrating that with wasm-bindgen.

So, Leptos isn't resumable at the moment but has been designed so far for future resumability.

[benwis]

Very cool! I too have been eyeing wasm split with the idea of Qwik-style resumability. Hoping we can get that soon

[matthewharwood]

Is how qwik serializes events to HTML on the server side to client. They call this resumability https://github.com/google/jsaction

[atdiar]

Just wondering how feasible it is really... Javascript can serialize most functions (not all but most) and deserialize them using eval.

How does one do the same thing for rust functions?

Seems to me that this is only a possibly valid approach for javascript and then again I jave doubt about the arguments that this is much better... The resumability approach, while interesting, seems to be at best an early optimization of app startup time.

There are probably other tradeoffs. Just wondering there as I'm trying to see below the marketing.

[gbj]

Just wondering how feasible it is really... Javascript can serialize most functions (not all but most) and deserialize them using eval.

How does one do the same thing for rust functions?

You don't need to serialize the functions, per se. You just need to know which signals are updated from which callback functions (this is by far the hardest part), and be able to code split such that you can load the correct function from Wasm as needed (this is also hard.)

Qwik has put a ton of work into both of these things in a language they're much easier in.

Seems to me that this is only a possibly valid approach for javascript and then again I jave doubt about the arguments that this is much better... The resumability approach, while interesting, seems to be at best an early optimization of app startup time.

There are probably other tradeoffs. Just wondering there as I'm trying to see below the marketing.

You're 100% correct here. Qwik's team pushes resumability as the answer to every problem and the best thing ever. In reality, we can probably get a lot of the benefit with much-lower-hanging fruit like partial hydration/islands, and hybrid routing like Solid is working on right now.

[atdiar]

Well, part of why Qwik is able to not ship any javascript at startup is that they put the state in the Server Rendered HTML(including reactive functions I understand).

But then the functions have to be serialized too. If someone has to ship wasm however, they basically have to send some file on first request which is claimed to be slowing everything. And load it at app startup.

To be fair, I don't buy that as I think that most of the potential slowness is caused by third party scripts and not necessarily application code.

But that's still one of the purported benefits of qwik that seems difficult to reproduce oustide of pure javascript.

If the wasm has to be sent AND loaded separately very first thing anyway, I am a bit dubious about the true utility of implementing resumability in this case.

If there is a solution for that, then why not of course.

[saolof]

Resumability may have other advantages beyond just bundling/lazy loading, such as saving state in local storage.

Even if you don't load the code as granularly as qwik, resumability still makes hydration a lot easier.

[blueray453]

Just curious, Qwik Optimizer is written in Rust. Is leptos reusing that?

[gbj]

Just curious, Qwik Optimizer is written in Rust. Is leptos reusing that?

I don't think this would be plausible. Qwik's optimizer may be written in Rust, but it's a tool for doing static analysis of JavaScript files to do code extraction, etc. Some of the same principles may well apply to trying to build resumability into a Rust framework but the optimizer itself couldn't be reused in any meaningful sense, I don't think.

[jbms]

I've built a prototype implementation of code splitting with lazy async loading for rust wasm32-unknown-unknown. See https://github.com/rustwasm/wasm-bindgen/issues/3939

[gbj]

@jbms This is extremely good news. I've only skimmed your post so far but explicit module splitting is exactly what we need, not so much for resumability as for route-level code splitting, which would be fantastic. I will look at this more deeply.