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

Try slowing down the network and interacting with it and see what happens. No feedback that anything is in flight and if i drag a card and then try to edit another before that is done the entire app freezes. I do think Ryan is genuinely open to be proven wrong here but this isn't it.

For sure! Can you clarify which part isn't it? Not trying to be rude, want to be explicit about what we're agreeing or disagreeing on. The feedback on the kanban board example could be improved, agree. How does a SPA handle the slow network roundtrip better here? Not following that part.

Trello as a demo comes from a challenge by Ryan Florence where he roasted peoples implementations seeing specifically how interacting with them broke in various ways when network was slow. There isn't a clear rule set but not waiting for network on every action feels like table stakes.

I'm not familiar with this challenge, will check it out. But I feel like we're talking around each other? You can easily add more clientside state to a datastar app if you want more--it's just signals. You can dial how much state you want to project on the client.

Conversely, in a SPA you can decide how frequently you want to update the server and show fresh data as you interact. A trello board is a good example where I could see arguments for both. Maybe I'm okay with more state at once that could be out of sync with the server. Maybe not.

"You can easily add more clientside state" dismisses the entire problem. What Ryan C is saying is that datastar doesn't provide solutions for apps where you need client state for the app to be good. Ryan Fs roasts clearly show how this client state is non trivial to get correct.

From what I understand, in datastar you usually send HTML back from the server. But to do optimistic updates (update the GUI before the server responds), you could also send back JSON to update client-side signals, but then there is no builtin functionality to render that to HTML with escaping etc?

D* is fairly simple in what it gives you: 1. An efficient, web standard (hence data attributes) way to bind DOM elements/events to state (via signals if you want it) 2. An efficient, web standard way to update the DOM from the server via morphing (idiomorph), almost like RSCs