The TODOS mini application at data-star.dev is slow and doesn't work correctly for me (checking/unchecking items isn't reliable). To me, this highlights one common problem I've seen with frameworks that insist on doing everything on the server.
Link?
Datastar: Web Framework for the Future?
21–30 of 161 posts
Re: Datastar: Web Framework for the Future?
#22The TODOS mini application at data-star.dev is slow and doesn't work correctly for me (checking/unchecking items isn't reliable). To me, this highlights one common problem I've seen with frameworks that insist on doing everything on the server.
Re: Datastar: Web Framework for the Future?
#23The web framework of the future is for better or for worse what Vercel and YouTubers talk about. Original thinking is sorely lacking in the majority of the web dev community.
Re: Datastar: Web Framework for the Future?
#24> fresh perspective, embracing server-driven architecture This is not fresh perspective. I used to be on "team everything on server" but it's a mistake on insist on that today.
Re: Datastar: Web Framework for the Future?
#25Datastar author here... AMA, but know that Datastar is pure yak shaving for me to do real work stuff so I have no golden calves, just approaches I've seen work at scale.
Re: Datastar: Web Framework for the Future?
#26> fresh perspective, embracing server-driven architecture This is not fresh perspective. I used to be on "team everything on server" but it's a mistake on insist on that today.
I think, at least as the creator, I've seen the "fight" be MPA vs SPA. IMO, both are wrong. It's about state management. MOST state lives in the backend but you still need fine grain reactivity on the frontend. On the number line between React and HTMX; Datastar is complex :)
Re: Datastar: Web Framework for the Future?
#27Datastar author here... AMA, but know that Datastar is pure yak shaving for me to do real work stuff so I have no golden calves, just approaches I've seen work at scale.
What do you think about the Hotwire stack (Stimulus, Turbo) as compared to Datastar ?
However, you quickly realise the limitation. You can even see this in the Turbo 8 demo (see this issue https://github.com/basecamp/turbo-8-morphing-demo/issues/9). You can try to fix this with `data-turbo-permanent` but you'll now run into another issue that you can't clear that field without resorting to JavaScript. Which, brings me to the next thing, I found I was still writing quite a bit of JavaScript with turbo. Like HTMX pushes you to use alpin.js/hypercript turbo pushes you to use Stimulus.js.
Turbo.js is not push based it's mostly polling based. Even when you push a refresh event, it pushes the client to re-fetch the data. Sure this is elegant in in that you re-use your regular handlers but it's a performance nightmare as you stampede your own server. It also prohibits you from doing render sharing between clients (which is what opens up some of the really cool stuff you can do with datastar).
I was using turbo.js with SSE so no complaints there. But, most turbo implementations use websockets (which if you have any experience with websockets is just a bad time: messages can be dropped, no auto reconnect, not regular http, proxy and firewalls can block it etc).
Finally, according to the docs Turbo Native doesn't let you use stream events (which is what gives you access to refresh and other multiplayer features).
I like turbo, I'd use it over react if I was using Rails. I use it for my static blog to make the navigation feel snappy (turbo drive). It gives you a lot without you having to do anything. But, the minute you start working on day 2 problems and you are not using rails the shine fades pretty quickly. There are 3 ways to do things, frames, streams and morph. None of them are enough to stop you having to import stimulus or alpine and honestly it's just a bit of a mess.
If you need help with turbo the best blogs posts are from (Radan Skoric https://radanskoric.com/archives/).
Specifically these:
https://radanskoric.com/articles/turbo-morphing-deep-dive-id...
https://radanskoric.com/articles/turbo-morphing-deep-dive
I think he's also got a book on turbo he's releasing soon (if you go with turbo it's probably worth getting).
Those posts helped me grok Torbo 8 morph and ultimately what sold me on datastar. Morph, signals and SSE is all you need.
As for mobile I'll just wrap it in a webview (as an X native mobile dev I can tell you it will lead to a lower maintenance app than native or react native).
TLDR: datastar solves all the problems I ran into with turbo and more. It's faster, smaller, simpler, more examples, better docs and easier.
Re: Datastar: Web Framework for the Future?
#28If you want a solid demo of what you can do with datastar. You can checkout this naive multiplayer game of life I wrote earlier in the week. Sends down 2500 divs every 200ms to all connected cliends via compressed SSE. https://example.andersmurphy.com/
Re: Datastar: Web Framework for the Future?
#29For people who are looking for HTMX alternatives, I think Alpine AJAX is another choice if you are already using AlpineJS