3 ms·

Isn't this replacing the complexities of JS libraries like react/redux-saga with the complexities of these new server-side libraries..? Reduced bundle size look

Isn't this replacing the complexities of JS libraries like react/redux-saga with the complexities of these new server-side libraries..? Reduced bundle size looks like a big advantage & this will hopefully encourage the adoption of lighter front-end tech like preact/inferno/svelte. But the downside seems to be more resource consumption on the back-end, especially if using websockets, and so higher cost & more vulnerability to a DDOS? Also, what about offline support?

raihansaputra 6y ago
Yeah, I'm interested about offline support. I might have to check out the HEY trial on web and on mobile. I think this HTML SSR approach have different tradeoffs and uses compared to Single Page Applications. The HTML SSR works best with a stable connection and being close to the server for good enough latency. Higher cost on the backend is a tradeoff on how much computation/complexity you want to offload to the client, and also what language/framework you want to work with more. Some HN comments from previous related topics suggest these approaches (Hotwire / LiveView / Blazor? / StimulusReflex / Intercooler / HTMX / Unpoly) fare better with apps targeting a specific region so roundtrip latency is lower. One can optimize the reads with DB replicas + app servers closer to any user, but the write DB is the bottleneck (I think). This also ties in with the feedback that US/EU HEY/BC users perceive the app as snappy enough while AU users feel the latency a lot more. SPA (properly built) should be more resilient in regards to network stability/condition/latency and expose a lot more offline capability. I feel like the ideal app is HTML SSR + an app shell to serve some offline capabilities. Scaling the write DB globally is a hard problem though.
frizkie 6y ago
The overview video touches on how some components of the Hey app are aggressively cached, like menu popups and such - so I imagine your "offline" capability comes from the fact that anything you need to run the application offline is just cached from the last online use.

raihansaputra 6y ago

Yeah, I'm interested about offline support. I might have to check out the HEY trial on web and on mobile. I think this HTML SSR approach have different tradeoffs and uses compared to Single Page Applications. The HTML SSR works best with a stable connection and being close to the server for good enough latency. Higher cost on the backend is a tradeoff on how much computation/complexity you want to offload to the client, and also what language/framework you want to work with more. Some HN comments from previous related topics suggest these approaches (Hotwire / LiveView / Blazor? / StimulusReflex / Intercooler / HTMX / Unpoly) fare better with apps targeting a specific region so roundtrip latency is lower. One can optimize the reads with DB replicas + app servers closer to any user, but the write DB is the bottleneck (I think). This also ties in with the feedback that US/EU HEY/BC users perceive the app as snappy enough while AU users feel the latency a lot more. SPA (properly built) should be more resilient in regards to network stability/condition/latency and expose a lot more offline capability. I feel like the ideal app is HTML SSR + an app shell to serve some offline capabilities. Scaling the write DB globally is a hard problem though.

frizkie 6y ago

The overview video touches on how some components of the Hey app are aggressively cached, like menu popups and such - so I imagine your "offline" capability comes from the fact that anything you need to run the application offline is just cached from the last online use.