Its not that "direct", its just a serialization format that supports a super-set of json types. Json tends to be lowest common denominator, so that describes most serialization formats. Which is why when i initially read the headline i thought it meant the wire format was json compatible, which would be really unusual and extremely impressive, because otherwise why else would anyone mention json compatibility? its like mentioning the format is for use with computers, it goes without saying.
That's not a criticism of anything with lite3, lite3 sounds really cool. The json angle is just an odd part to concentrate on.
The power in Datastar is YOU get to choose what plugins you use to build the API you what... want data-get, it's a few lines away from being yours! You can rebuild all of HTMX in Datastar, not the other way around. https://data-star.dev/examples/custom_plugin is a great intro
Yes, and the htmx philosophy is that it gives you some default functionality out of the box, it doesn't just hand you a bunch of building blocks and ask you to put everything together yourself. Both are valid approaches. I don't know why one side always has to come in and try to put down the other. Without htmx, there is no Datastar.
You are right! without HTMX 1 and the choices for future dev there would be no Datastar! If you think having a full framework while still allowing super easy way to make whatever API as you see fit is putting someone down, idk, ngmi.
That's not what I think. Just take a look at the top-level comments where Datastar supporters are coming in and doing the 'htmx 4 is just doing what Datastar does now, why do we need htmx' routine. First of all that's not even true, and secondly it's kinda transparent–whenever htmx gets discussed the Datastar fans show up to naysay.
the top-level comment (mine) literally celebrated the v4 changes, and I've done nothing but show respect and gratitude for HTMX.
I was simply asking, though, what I might be missing now that HTMX is becoming a (heavier) Datastar-lite (no signals and more). Given that these changes were literally previously rejected by HTMX and caused Datastar to even come into existence, it seems wholly appropriate to be making the comparison here.
Also, I can't speak for others, but when I've brought up Datastar in other HTMX-centric discussions here and elsewhere, its only when someone asks about things like SSE, idiomorph etc... I always say that if you're looking for those features, you might prefer to just use D... Now that those features are native to HTMX, I suppose they can just stay with it. But you get even more for less weight by moving to D
The largely nonsensical and overly-defensive responses from HTMX's devs/supporters have only made it clear to me that D* is the appropriate choice here.
Htmx supporters have explained why htmx over Datastar many times. This is not even the first thread about this topic. Even in this thread you can easily find people (including myself) explaining why htmx and what it does differently. We don't need to repetitively explain the same exact justifications every time someone asks. Do a little reading, it's all there.
If you are making technical decisions about web programming based on HN threads though, best of luck to you.
I make technical decisions based off of metrics. Last time we talked as soon as I showed you flamegraphs you yeeted. If you think D* version of morph is just idiomorph... please, make charts that actually show that to be the case.
I make decisions based off of metrics too, it's just that we disagree about the metrics. You think about milliseconds in download times while I think about Core Web Vitals. Both have their place of course, in different contexts.
I don't make any claims about the D* version of morph or idiomorph as I use neither of those.
So you can support JSON while still being REST. For example, Datastar supports merging in HTML, JS, JSON into the current view of a resource. They work together to keep the resource state unified versus polling. In general the Datastar way is...
1. make an MPA
2. each page is a resource
3. keep a stream open on the current state of that resource
4. ship, touch grass, repeat
It doesn't put me off the project! I will happily pay for great software that enables me to make money just like I'd pay for good tools around the house (once I get started with D*).
I was just pointing out that in my mind the criticism is totally fair game because many OSS do not do this, that is all. By the looks of it you agree.
I think I want to just mention something here that is really important. The Datastar team have done more to push for performance, better UX and the ways of thinking around SPAs and MPAs than multi billion dollar companies have done in the last couple of years. Not forgetting HTMX, this cooperation has been incredibly fruitful and I am very excited about the future with you guys.
hey Alex, I hope you are well. Datastar has had direct support for req/rep of HTML, JS, JSON while still morphing for a quite a while. They allow you to go as coarse as you want. Give the size and ability to choose what plugins you actually need seems like Datastar is more in line with your wants at this point. Strange times.
