Post

@ryansolid.bsky.social thanks for the discussion on stream today! You asked on stream today to show you a trello or otherwise sufficiently complex app in datastar. Here is that as as well as a few others that opened my eyes a bit, as a former skeptic. kanban.jsonbateman.com

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...

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?

where is the data coming from? if it's from the network then network latency will almost always dominate any sort of local computation

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

Yes, but that's not the comparison/framing afaict. Getting fresh data. I'd never argue that serving local data+rendering browser is slower than going over the network, but that's not the only aspect I care about.

i think it's a relevant comparison. if you only consider the least apt scenario for client-side rendering — network calls in the critical path of rendering — then of course it'll seem bad. but outside of that scenario there are all sorts of strategies to improve the perceived (or actual) performance