3 ms·

Some bullet points are missing from the “perfect framework” list: 1. SSR must support streaming 2. SSR must work in a service worker (so in fact you have 3 ta

by deno 9y ago

Some bullet points are missing from the “perfect framework” list: 1. SSR must support streaming 2. SSR must work in a service worker (so in fact you have 3 targets: server, client/hydration, client/service worker) 3. All work that can be offloaded to a WebWorker must be offloaded 4. Navigating to subsequent pages must support prefetching, including dynamic data (Next.js doesn’t even tell you how to do it) 5. Navigating to subsequent pages SHOULD support prerendering (offscreen) where it makes sense, but… 6. MUST support FLIP-style transitions[1]. Which does mean prerendering anyway for about 100ms at least so the layout can stabilize and cached images load into memory. For long pages you need to split them into chunks/sections and only animate the part that gets shown (usually above fold). [1] http://www.pocketjavascript.com/blog/2015/11/23/introducing-pokedex-org http://www.pocketjavascript.com/blog/2015/11/23/introducing-...

rich_harris 9y ago
This is an excellent list, thank you. To answer some of the points: Sapper supports partial streaming of server-rendered HTML (typically you'll get most of the <head> while it's fetching data for your page, unless there's no dynamic data in which case you get the whole lot instantly). I'm not convinced there's actually a benefit to 'server' rendering in a service worker as opposed to serving a shell page. We have an issue for it though! (https://github.com/sveltejs/sapper/issues/22 https://github.com/sveltejs/sapper/issues/22) Sapper supports prefetching (including of dynamic data) of subsequent pages — just add rel=prefetch to <a> elements (we'll add a programmatic way to do this in future as well). As for the rest, some of it is app-specific, some of it is stuff the framework could help with. We're not at version 1 yet, so bear with us :)
- deno 9y ago
  It should be “free” with the right architecture, and it should be faster, that’s why I included it for the “perfect” framework list. However, it’s only a win on first page load on a subsequent visit. So definitely not a priority for an actual implementation. BTW one easy way to implement this would be to flip the usual model: 1) Have service worker/server as main renderers 2) On navigation do a fetch to service worker and patch the page So you’re on /main, do fetch to /page2?from=state and get patching instructions. If you could give the service worker readonly access to DOM without copying this wouldn’t actually be that stupid. It might be possible some day: https://github.com/whatwg/dom/issues/270 https://github.com/whatwg/dom/issues/270

by deno 9y ago

rich_harris 9y ago

This is an excellent list, thank you. To answer some of the points: Sapper supports partial streaming of server-rendered HTML (typically you'll get most of the <head> while it's fetching data for your page, unless there's no dynamic data in which case you get the whole lot instantly). I'm not convinced there's actually a benefit to 'server' rendering in a service worker as opposed to serving a shell page. We have an issue for it though! (https://github.com/sveltejs/sapper/issues/22 https://github.com/sveltejs/sapper/issues/22) Sapper supports prefetching (including of dynamic data) of subsequent pages — just add rel=prefetch to <a> elements (we'll add a programmatic way to do this in future as well). As for the rest, some of it is app-specific, some of it is stuff the framework could help with. We're not at version 1 yet, so bear with us :)

deno 9y ago
It should be “free” with the right architecture, and it should be faster, that’s why I included it for the “perfect” framework list. However, it’s only a win on first page load on a subsequent visit. So definitely not a priority for an actual implementation. BTW one easy way to implement this would be to flip the usual model: 1) Have service worker/server as main renderers 2) On navigation do a fetch to service worker and patch the page So you’re on /main, do fetch to /page2?from=state and get patching instructions. If you could give the service worker readonly access to DOM without copying this wouldn’t actually be that stupid. It might be possible some day: https://github.com/whatwg/dom/issues/270 https://github.com/whatwg/dom/issues/270