Post

Thanks for posting. I would respond but @gabbev.bsky.social pretty much has it completely covered. He's not trying to be difficult. The first thing I do when playing around with an app is throttle the network and see if it holds up. I did that on stream too. I hope this thread serves as a reference.

I think with any approach you hit the same issues and there's nothing inherent with hypermedia that prevents you from working with slow/throttled networks while sacrificing UX.

I'm suggesting that because of their wheelhouse modern SPA frameworks tend to account for this category in their design. I view HyperMedia as lower level protocol. I don't see an issue communicating with HTML partials etc. There is just a lot that sits on top of that. bsky.app/profile/ryan...

Ryan Carniato@ryansolid.bsky.social

No one is dismissing hypermedia or the like. Server components are basically a nod to them. There is just a reason like how you acknowledge you can't stop at HTMX, that I don't stop at Datastar. Not anything wrong with what its doing.

To make sure I'm following: you're saying modern SPA frameworks account for slow networks in their design. I assume you're referring to optimistic intent and/or the fact that SPAs tend to localize more state than typical hypermedia stacks.

From a DX standpoint, I sympathize. From a more theoretical one, I'm confused, given that my understanding is the fastest way to get fresh data shown in a browser is zstd/brotli compressed HTML morphed into the DOM. To wit I'd expect hypermedia to perform materially better in throttled conditions?

This might be besides the reality of the situation: building web apps is fundamentally hard, and your choice of architecture may allow you to move the amount of fresh data you can easily manage up and down the scale. For some apps reasoning about local data models might be preferable, I agree.

But in my experience there are many apps where that is simply not the case. A realtime dashboard for example, the app I build for a living, benefits from the server-authoritative model, regardless of network latency.

I think in part where we're speaking past each other is in the difference between, as you said on stream, design affordances (what do I show) and dynamic data latency (how fresh is what I am showing). The water is further muddied by this ethereal q of "who owns the state", which we can debate.

0 reposts0 likes

Design affordances can be handled in both hypermedia (or at least Datastar) stacks and SPAs. The ergonomics of doing so might be easier depending on the app in one architecture or another, though each has their weaknesses too.

My original point though was that, unless I'm misunderstanding in which case I'd love to learn more, it's not as simple as saying that hypermedia isn't suited for apps (at scale, in case that wasn't clear). I recognize I risk being pedantic here. Thanks again!

Yeah I mean it depends on how much changes. HTML chunk might be fastest but do you replace the whole page? Do you replace a dozen little pieces? Do those pieces themselves contain shared client side ephemeral state. Once we stopped shipping the page wholesale the places that wiring shows up increase

Additionally a lot of time with SPA approaches the client acts a cache that doesn't invalidate as often (ie.. ok to be stale) so per interaction costs are actually reduced. Like if the goal is to create DBMon benchmark I imagine the best approach is actually have a persistent server that diffs.