Test bundle size effects of using serde_lite instead of serde for Resources about leptos HOT 4 CLOSED

Thinking more I'm pretty sure the answer is to feature flag this so you default to serde but can opt in to serde-lite (or even miniserde) with a flag.

from leptos.

Okay, this is pretty promising; it did manage to drop the bundle size of the HackerNews hydration client from 470kb to 445kb.

There are two concerns right now that are stopping me from just doing this:

1. At the moment the serde-lite author doesn't have Serialize and Deserialize implemented for Result, so I moved all the HTTP requests over to return an Option<T>. Given that I was returning Result<T, ()> for simplicity there is no real difference, but in a real app this is a blocker. I've opened an issue on serde-lite (see operutka/serde-lite#2) but would definitely want that resolved before I'd do this.

Maybe one of us could even submit a PR on serde-lite for this.

2. There are plenty of convenience crates that rely on serde to do things like JSON deserialization in fetch requests. The manual version with serde-lite is a little more awkward, since you get text, then deserialize to an intermediate format, then deserialize to the actual type https://github.com/gbj/leptos/blob/5c022879f16d488ba7eca017a6aa42ad1474199a/examples/hackernews/hackernews-app/src/api.rs#L18-L27

Given the bundle size effects and the big benefit this would on load times have as apps scale up — I've found serde to be the main culprit in real-app bundle sizes — I think this is worth it but would love some feedback.

Note: It would also be possible to feature-flag this, probably defaulting to serde but giving a serde-lite flag that allows you to opt-in to the smaller bundle sizes but deal with the quirks.

from leptos.

Oh and I should clarify: this is mostly to do with SSR + hydration mode, not pure-SPA client-side-rendering mode.

If you are doing SSR and hydrating resources/async requests will actually start on the server, and stream the results down to the client, which is much faster than waiting until the client has fully loaded. So initial load for the HackerNews demo is faster in SSR + hydrate mode than in SPA mode.

SPA/CSR mode:

1. Ask server for HTML
2. Browser sees it needs JS/WASM, and downloads them
3. Once WASM is downloaded, run component, including the create_resource
4. Begin network request to fetch from API (from browser)
5. Now we have data and can render it

SSR/hydrate mode:

1. Ask server for HTML. Server has to render the page. While rendering page, sees the create_resource
2. Begins fetching from API (on server)
3. Browser gets HTML. Sees it needs JS/WASM, and downloads them
4. API request resolves on server and it streams the result down to the client. (If you're inside a <Suspense/> component it actually streams the newly-rendered HTML too and replaces the fallback state)
5. WASM is downloaded and runs the component.
6. Sees the resource is already resolved, and deserializes it from JSON.

Depending on the API latency + WASM bundle size, streaming SSR means you often get the data + HTML before the WASM has even begun running, which is a huge speedup.

But this is why resource types need to be Serialize + Deserialize: so we can actually poll them on the server, send down JSON, and resolve them on the browser.

from leptos.

This was good for me to think aloud... I'm pretty happy with the solution in #33 and am going to go with that.

from leptos.