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.
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.
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.
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.
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.
An interesting characteristic of Datastar: it's very opinionated about the shape of your backend but extremely unopinionated about how you implement that shape.
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.
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.
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.
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.
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
> 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.
Indeed, that would have to be specific advice for each country.
Most of these are not applicable where I live: you can’t cash out your pension fund, stocks are taxed separately from income, there are no high-yield savings accounts or health savings accounts, credit cards are rarely used and have no cashback.
In Norway you can use American Express, Diner's Club and other credit cards, though the two I mentioned aren't always accepted due to higher fees. The Norwegian airline also has a credit card that's pretty popular and offers cashback or bonus points or whatever and there's something called Trumf which offers cashback at certain stores for debit cards.
Regarding tax I just go to the tax authority's website and declare my expected income, assets, debt etc and my employer gets a "tax card" from them which they use to pay taxes for me. At the end of the year the tax authority does a final calculation, sends me an overview and either returns some money or sends a bill for what I owe. I can overestimate my income if I want to avoid that bill, then the tax return is like a bonus but I personally prefer to operate with a healthy emergency fund so that a $3000 tax bill doesn't really bother me. Usually it's like +-$1000 at the end of the year.
The UK (temporarily too embarrassed to be in the EU) has some very generous tax advantaged accounts which match the US ones, so you can map "401k" to pension and "Roth IRA" to ISA to get something similar.
Very cool concept and PoC of both Spotify and vscode integration to learn from.
It has opened my mind to a bunch of cool things to do now that I know that the /v1/me/player/currently-playing API endpoint exists.
But I'm having enough trouble concentrating as it is, this seems like a terrible idea :D.
Maybe for the more chill vibe codng sessions...
Edit: Also, cool to learn about https://lrclib.net/, will come in handy if the music industry paradigm shifts and we need to yet again sail the high seas.
This is one of those things that are terrible, but not because the tool is terrible in itself, it's just that the world in which the tool operates is terrible, and the tool just a natural conclusion.
I mean it makes sense right? If there were 5000 same job offers for the exact same position I'm sure we'd automate it - why not do it for VCs and accelerators?
100%. It's truly infuriating, but going back to my normal workflow now feels somehow wasteful. Like I'm able to rely on a team of devs for busywork and just deciding to do it by hand and overcharge my clients (in time).
I've had a few instances where I've been able to go into flow state with 3 concurrent sessions on fully disjoint projects. Feels like context switching is easier when there's almost zero cognitive overlap between the projects in terms of actual features, but the stacks are all similar.
But for sure I haven't even come closer to these glorious flow sessions fully locked into coding some clever bit of logic.
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.