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.

0 reposts1 like

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?

Depends on what you're asking exactly. Do you mean how far is the connection from the data source? If so then you measure real world latency and determine if it's actually an issue.

i'm specifically questioning the claim "the fastest way to get fresh data shown in a browser is zstd/brotli compressed HTML morphed into the DOM" like, if you're comparing HTML over the network vs. client-side rendered from memory, the latter will absolutely be faster except in pathological cases

wrt to OP's point compressed html over the wire is technically faster than serialized json and then rendering, but also depends on what you're sending exactly.

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.