5 ms·
I'll shill datastar for a second, there's barely a notion of frontend state management if you treat HTML as a projection surface with interactivity. I'd argue H
by fatplexer 21d ago
I'll shill datastar for a second, there's barely a notion of frontend state management if you treat HTML as a projection surface with interactivity. I'd argue HTML is the most efficient wire format for interactive web apps, especially with streaming + compression.
Seriously DB->json->client->toHtml
DB->toHtml->client
Just imagine if that html wire format also conveyed the interactivity too and you eliminate the issues. And you can always seperate whatever concerns you want in whatever tpl lang of your choice.
Also htmx 4 is kinda just an worse datastar funnily enough In it's own way.
- turtlebits 21d agoDatastar relies way to much on IDs everywhere that it's not ergonomic and turns into a chore. It's also a bit too complicated for its own good trying to solve everything.
- fatplexer 20d ago[dead]
- devalexwells 20d agoAs far as I understand D* only uses id (which is a pretty normal HTML attribute?) to key morphs in SSE. I only use one id for fat morphs on the body, and even if I needed more I'm not sure I'd find that any less ergonomic than other web standard attributes (class for example I have to use religiously in my day job with tailwind, etc). Can you elaborate on the "too complicated" part? It seems a lot simpler to me given the slim surface area of the APIs?