lazy loading and resumability ala qwik

[tzoor-rozental]

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 rustwasm/wasm-bindgen#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.

[gbj]

Despite the interest, I'm going to close this as a mixture of "not planned" and "on the radar."

Lazy loading: This part is very much on our radar, and we have plans to incorporate the excellent wasm-split work by jbms above into cargo-leptos. The new router has been designed to work well with async/lazy-loaded components, and I have made some demos showing that this is a plausible path forward for us.

Resumability: Qwik-style resumability sounds good, but over the last two years I've come to the conclusion that it is a net negative, especially for a WASM-based framework. In the end, this mostly comes down to the cost of serialization/deserialization. Qwik ends up storing a large amount of data in HTML, to be lazily deserialized. That's not awful in and of itself, but deserialization is relatively expensive for WASM frameworks in terms of bundle size. Ironically this means that in the pursuit of faster load times, you slow load times down significantly because the binary that needs to be loaded to deserialize the resumable bits is much larger.

I have put a lot of thought over the last three years or so into ways to make a resumable Rust/WASM framework — research into serializing/deserializing closures so we know what signals are used in an event listener, etc. In fact I started a prototype of a resumable framework six months or so before I started working on Leptos. Over this time I've come to the conclusion that it's just not worth it.

We do have a very good partial-hydration solution with islands, which allow you to remove a large % of the client-side WASM. The combination of islands and lazy-loading will be my strategy going forward for fast loading/fast TTI.