[adlpz]

I may be just completely out of my depth here, but I look at the cool example on their website, the Open the pod bay doors, HAL bit, and I don't like it, at all.

And reading comments one would think this is some amazing piece of technology. Am I just old and cranky or something?

This feels... very hard to reason about. Disjoint.

You have a front-end with some hard-coded IDs on e.g. <div>s. A trigger on a <button> that black-box calls some endpoint. And then, on the backend, you use the SDK for your choice language to execute some methods like `patchElements()` on e.g. an SSE "framework" which translates your commands to some custom "event" headers and metadata in the open HTTP stream and then some "engine" on the front-end patches, on the fly, the DOM with whatever you sent through the pipe.

This feels to me like something that will very quickly become very hard to reason about globally.

Presentation logic scattered in small functions all over the backend. Plus whatever on-render logic through a classic template you may have, because of course you may want to have an on-load state.

I'm doing React 100% nowadays. I'm happy, I'm end-to-end type safe, I can create the fanciest shiny UIs I can imagine, I don't need an alternative. But if I needed it, if I had to go back to something lighter, I'd just go back to all in SSR with Rails or Laravel and just sprinkle some AlpineJS for the few dynamic widgets.

Anyway, I'm sure people will say that you can definitely make this work and organize your code well enough and surely there are tons of successful projects using Datastar but I just fail to understand why would I bother.

[bargainbin]

I’ve not tried Datastar in anger but I have tried HTMX after all the hype and it quickly became unmaintainable.

My dream was having a Go server churning out all this hypermedia and I could swerve using a frontend framework, but I quickly found the Go code I was writing was rigid and convoluted. It just wasn’t nice. In fact it’s the only time I’ve had an evening coding session and forgotten what the code was doing on the same evening I started.

I’m having a completely opposite experience with Elixir and Phoenix. That feels like an end to end fluid experience without excessive cognitive load.

[FredPret]

BEAM + Elixir + Phoenix feels like I can control a whole system from the CPU processes (almost) up to the UI elements on a remote user’s screen, all in one easy-ish-to-understand system and language.

Granted, I’ve only used it for smaller projects, but I can almost feel my brain relax as the JS fades out, and suddenly making web apps is super fun again.

[leg100]

Did you use templ [1] for server side templating? It supports something called fragments, which may help with HTMX [2].

[1]: https://templ.guide/

[2]: https://templ.guide/syntax-and-usage/fragments

[mxey]

The standard library html/template also has that in the form of blocks.

[yawaramin]

html/template blocks are not as ergonomic. They force you to work on the template level and drill down into the blocks. Templ, Gomponents etc. let you build up the components from smaller pieces, like Lego.

[ndyg]

The preferred pattern addresses your concern about scattered logic: a single long-lived SSE endpoint that "owns" the user's view of the app. That endpoint updates their field of view as appropriate - very much inspired by game dev's immediate mode rendering.

I've a tutorial that demonstrates this with Nushell as the backend: https://datastar-todomvc.cross.stream

An interesting characteristic of Datastar: it's very opinionated about the shape of your backend but extremely unopinionated about how you implement that shape.

[yxhuvud]

> if I had to go back to something lighter, I'd just go back to all in SSR with Rails

FWIW, default config of Rails include Turbo nowadays, which seems quite similar to Datastar in concept.

[ndyg]

My understanding is Turbo is more aligned with htmx. Common practice in Turbo are generally patterns of last resort in Datastar.

e.g. Datastar prescribes a single long lived SSE endpoint that owns the state for the currently connected user's view of the world / app, while common practice in Turbo is to have many small endpoints that return a fragment of html when requested by the client.

[array_key_first]

The idea of HATEOS is that HTML isn't "presentation logic", it IS the state of your application. Then, the backend manages the state of your application.

[pragma_x]

Yup. Another way to frame it is a "return to form" by moving app and business logic back to the server. Technology like HTMX and Datastar are optimizations that allow for surgical updates of portions of the client DOM, instead of forcing full-page refreshes like we did 25 years ago.

[jakubmazanec]

I share your feelings. If you like React and its trade-offs, and you're comfortable using it (based on various HN discussion the easiest sign is that you're able to understand the concept of hooks and you don't have the need to wrongly yell everywhere how it's a bad abstraction :D), you can forget about Datastar or HTMAX.

[spoiler]

For context, I worked with large React codebases, contributed to various ecosystem libraries (a few bigger ones: react-redux, styled components, react-router). So, I'm pretty comfortable with hooks, but I still make mistakes with them if React isn't in my daily routine (different day job now, only use React occasionally for some pet projects).

I've also onboard interns and juniors onto React codebase, and there's things about React that only really make sense if you're more old-school and know how different types behave to understand why certain things are necessary.

I remember explaining to an intern why passing an inlined object as a prop was causing the component to rerender, and they asked whether that's a codebase smell... That question kinda shocked me because to me it was obvious why this happens, but it's not even a React issue directly. Howeve the fix is to write "un-javascripty" code in React. So this persons intro to JS is React and their whole understanding of JS is weirdly anchored around React now.

So I totally understand the critique of hooks. They just don't seem to be in the spirit of the language, but do work really well in spite of the language.

As someone who survived the early JS wilderness, then found refuge in jQuery, and after trying a bunch of frameworks and libraries, finally settled on React: I think React is great, but objectively parts of it suck, and it's not entirl its fault

[Izkata]

> and they asked whether that's a codebase smell...

Something that's been an issue with our most junior dev, he's heard a lot of terminology but never really learned what some of those terms mean, so he'll use them in ways that don't really make sense. Your example here is just the kind of thing I'd expect from him, if he's heard the phrase "code smell" but assumed something incorrect about what it meant and never actually looked up what it means.

It is possible your co-worker was asking you this the other way around - that they'd just learned the term and were trying to understand it rather than apply it.