Less characters is not simple that's easy.

Which is why HTMX is having to bolt on more gubbins. Because, although it's less characters to type its fundamentally complected and therefore less composable.

I'm sure you've already warched it but if you haven't I'd recommend Rich Hickey's talk Simple made Easy.

▲

yawaramin 2 days ago | parent [-]

I don't think the takeaway from Hickey's talk is just a blind 'simple is always good, easy is always bad'. It's actually important to offer 'easy' affordances in some cases. Htmx operates at a specific level of abstraction. This abstraction has been carefully chosen to work to create apps in a certain way. It's like a shortcut for creating a simple kind of hypermedia-driven app with some easy conveniences. I think this is a significant and important point in the design space.

▲

sudodevnull 2 days ago | parent [-]

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

▲

yawaramin 2 days ago | parent [-]

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.

▲

sudodevnull 2 days ago | parent [-]

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.

▲

yawaramin a day ago | parent [-]

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.

▲

nchmy a day ago | parent [-]

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.

▲

yawaramin 17 hours ago | parent [-]

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.

	▲	nchmy 11 hours ago \| parent [-]
		Lol