Live data from Hacker News

Datastar: Web Framework for the Future?

chrismalek.me

21–30 of 161 posts

Re: Datastar: Web Framework for the Future?

#21
post #18
post #2

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?

> data-star.dev

Re: Datastar: Web Framework for the Future?

#22
post #2

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.

Yeah I'm seeing that too. We're getting ready for V1 and I probably missed a test around the Todo. My fault, didn't think we'd get hit by hackernews on a free shared fly.io server. I'll look into it now

Re: Datastar: Web Framework for the Future?

#23

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

I hate how right you are. We are now the smallest (v1 is on track to be 11.4Kb), have the fastest signal implementation and looking like over 2x faster than idiomorph. So it's the smallest and fastest shim to build real-time apps or simple CRUD. Shocked how much tech world is vibes based but so be it.

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.

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?

#25

Datastar 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 ?

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 :)

Data may live in the backend, but it is used more in the frontend. Having it local (in memory, or even indexeddb) makes more responsive apps, especially if it's a typical CRUD app with 70/30 or more split between reads/writes.

Re: Datastar: Web Framework for the Future?

#27

Datastar 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 ?

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.

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?

#28

If 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/

Is sending 10,000 divs/sec the right solution for this problem, or is this an "everything looks like a nail" solution?
Post reply on HN