Not a fan (andersmurphy actually is better at explaining than me). However! I've been working with Micah from the Turbo.js team on idiomorph ideas. We are already multiples of v0.7.3 right now and getting faster each day. Together we can solve the core ideas even if we disagree on the top level API.
So I've used Turbo 8 to make a multiplayer app using a non rails backend. It was a struggle, the docs are incomplete. I mostly pieced things together from what others have done and written about. Which, is ironic considering your point about having a massive community behind it. The nice thing about Turbo 8 is morph (it uses idiomorph like datastar). It's also got a pretty simple refresh model.
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.
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.
Regarding Turbo being push based and the approach of using refresh event to reload page. Would pushing Turbo Stream fragments using a SSE connection overcome the issues mentioned?
Is this the same as the Datastar approach?
