</> Htmx – The Fetch()ening

361 pointsposted 3 months ago
by leephillips

59 Comments

booi

3 months ago

> So, eventually & reluctantly, I have changed my mind: there will be another major version of htmx.

> However, in order to keep my word that there will not be a htmx 3.0, the next release will instead be htmx 4.0.

technically correct.. the best kind of correct

SquareWheel

3 months ago

It's an amusing solution, but if this ends up being anything like the missing PHP 6, it's also going to cause confusion for users. It might've been better to just mea culpa and release 3.0 anyway. I can't imagine anybody would really hold it against the author.

pavon

3 months ago

As long as they commit to making the next version after this htmx 8, I will be content with this versioning scheme.

drob518

3 months ago

Apple just jumped to version 26 across all its code bases. I think HTMX can survive with skipping to 4.

johannes1234321

3 months ago

What's the confusion around PHP 6? - There would have been a lot more confusion due to articles, talk slides, even printed books, .. talking about PHP 6's Unicode support would have been truly confusing.

abnercoimbre

3 months ago

A mea culpa would've been just fine. Even Big Tech can't keep their promises around this stuff (Windows 10 was the last OS remember?)

panxyh

3 months ago

Traditionally, software engineers are smart people

SwiftyBug

3 months ago

Maybe they could just initially launch v3.1 instead of a v3.0. They would still be technically correct.

fmbb

3 months ago

Should go directly to htmx 4.1, so we can finally have xhtmx 1.0

jraph

3 months ago

The author is lucky the phrasing wasn't "there won't be another major version of htmx", or even "a third version".

scuff3d

3 months ago

From what I know of Carson from his writing and presentations, he probably worded it that way on purpose knowing he'd eventually do a new version, and he didn't want to miss an opportunity to troll everyone a bit.

user

3 months ago

[deleted]

user

3 months ago

[deleted]

gr4vityWall

3 months ago

> htmx 2.0 (like htmx 1.0 & intercooler.js 1.0) will be supported in perpetuity, so there is absolutely no pressure to upgrade your application: if htmx 2.0 is satisfying your hypermedia needs, you can stick with it

This is commendable, specially during times when libraries and programs aren't afraid of breaking changes and API churn.

JSR_FDED

3 months ago

I think the ideas behind HTMX are cool, and Carson’s advocacy around Hypermedia is great.

I came from SPA-land and was tired of the fundamental architectural issue of having to keep the front-end and back-end state in sync.

I’ve compared Datastar and HTMX and decided on Datastar. There’s overlap between the two libraries in that they both support the request/response model, but with Datastar my learning investment takes me further and opens up new possibilities.

In one project I was able to remove a bunch of polling code and simply push a signal from the server to the browser when an external event occurred. The reduction in complexity was crazy.

On an internal tool I noticed I didn’t need Alpine.js anymore, and while anytime I can remove a dependency is a good time, the conceptual simplicity is what really makes me happy.

Now I’m doing a small app where I decided to make a streaming connection between browser and server and simply regenerate and send the entire view over that connection anytime something changes. Intuitively this felt wasteful but it turned out that with compression this works beautifully. There’s just less code in my app, and the code that’s there is less “fiddly” not having to deal with partial updates of the page.

If you’re coming from the world of SPAs, definitely check out both.

nprateem

3 months ago

Datastar looks interesting, but their guide on how to redirect a user is a joke.

async def redirect_from_backend():

    yield SSE.patch_elements('<div id="indicator">Redirecting in 3 seconds...</div>')

    await asyncio.sleep(3)

    yield SSE.execute_script('window.location = "/guide"')
LOL, they really think it's a good use of server resources to sleep so the client doesn't have to.

[1] https://data-star.dev/how_tos/redirect_the_page_from_the_bac...

deepsun

3 months ago

> hx-target attribute is explicitly declared as inherited on the enclosing div and, if it wasn’t, the button elements would not inherit the target from it.

So confusing. I'm pretty sure it should be "inheritable", because "inherited" on an attribute means the attribute is inherited, not the element's children will inherit the attribute.

UPDATE: or "inherit", sounds like a command, little less confusing.

SoftTalker

3 months ago

I was going to make the same comment. "inherited" is the wrong word. I like "inherit" too. And it's a bit shorter which is always nice. I guess "bequeath" might work also?

jonahx

3 months ago

> I'm pretty sure it should be "inheritable", because "inherited" on an attribute means the attribute is inherited, not the element's children will inherit the attribute.

That is one interpretation, but not the one I had reading it. I read it as "This target will be inherited by its children," rather than "This target is inherited from its parents," which, while a grammatical possibility, doesn't really make sense because you are specifying it right there with the equal sign.

Both "inherit" and "inheritable" have the same possible double readings. Something like "pass-to-children" or "pass-down" would remove the possible ambiguity, but I'm not sure like either better than "inherited".

recursivedoubts

3 months ago

yeah, i'm struggling w/it, willing to consider options

mrj

3 months ago

Maybe `heritable`?

treve

3 months ago

or 'cascade' ?

user

3 months ago

[deleted]

lazypenguin

3 months ago

> By switching to fetch(), we can take advantage of its support for readable streams, which allow for a stream of content to be swapped into the DOM, rather than a single response.

Based on this section, it will be interesting to see how this evolves. I've used HTMX a bunch but after stumbling on Datastar I've come to prefer it. Partially because I don't need something like alpine.js to get some frontend goodies but also because I've come to appreciate the power of SSE streaming morphable targets to the browser

rtpg

3 months ago

I feel like people who crave stability pull all the wrong lessons from how to get to stability when doing this sort of "ok we'll make _one_ major version with all the breaking changes we've built up over time".

This feels like a repeat of the Python 3.0 strategy, though obviously at a much smaller scale. Some stuff is of course hard to roll out but to me it feels "obvious" that having a 4.0 with the inheritence change (or even better, a 2.1 with a toggle on that change!), then a 5.0 with some other changes, then a 6.0 with other changes... all feels way easier to manage than a 4.0 with all the changes at once.

We have version pinning! People who want 2.0 can have 2.0 "forever", so version numbers that go up very high are not actually a problem. Many releases can of course be a bit of a frustration from a release maker's perspective, but given that htmx is the way it is (ain't even getting type checking helping you out on any of this like you would with React!), having the gradual path seems way better.

"I think I've handled the 10 changes in between 2.0 and 4.0... but forgot the 11th change" is a constant annoyance with these huge major version bumps.

I will once again point to the Django strategy of having breaking changes be rolled out over several releases, including in between releases where "both" models exist. It is a very nice way to do release management when rolling things out, gives good checkpoints for pushing things out, and overall means users are seeing less bugs. Going from `XMLHttpRequest` to `fetch` really might not be a feasable thing to toggle, but a lot of the other stuff in that list feels like it.

imtringued

3 months ago

>I feel like people who crave stability pull all the wrong lessons from how to get to stability when doing this sort of "ok we'll make _one_ major version with all the breaking changes we've built up over time".

Yeah this is a huge fallacy. If you do a breaking change, you want to do as few breaking changes at once as possible, with as little impact as possible and in the best case scenario you're in contact with every single person that is affected by the breaking change, so that it can be handled without anyone noticing anything other than having to bump a library version, which they were doing anyway since they're running a new Python version in the first place.

The dumbest change in python 3 was removing the print statement [0]. Maximum breakage, minimum gain. They could have introduced the new function as println() and deprecated the print statement in Python 3.

[0] https://news.ycombinator.com/item?id=13260563

nchmy

3 months ago

Great to see this evolution! Realtime ssr hypermedia is definitely the future.

But, my thoughts immediately go to Datastar, which has Fetch, SSE, declarative signals and js expressions, dom morphing, and much more - in a tiny package. I find it to have a more flexible, expressive and standards-compliant API as well. And it'll soon have a simple reactive web components and css framework as well.

At this point, why use HTMX when it really seems like (a heavier) Datastar-lite?

arcanemachiner

3 months ago

Because Datastar Pro isn't FOSS, and speaking from a purely probabilistic and historical standpoint, your odds of getting rugpulled (in some form or another) might as well be 100%.

jaredcwhite

3 months ago

I took a look at Datastar, and pretty quickly realized I really don't like libraries which try to do so many different things. The surface area of the API is way too big. htmx is already too big for me, I tend to reach for mostly vanilla-only or small vanilla-adjacent solutions I can either write by hand or import. But as I've been experimenting with htmx (including its very good extensions API), I'm realizing it's in a pretty good sweet spot overall.

I'm very excited about htmx 4.0 and sounds like things are headed in a promising direction.

alexpetros

3 months ago

> why use HTMX when it really seems like (a heavier) Datastar-lite?

The reason to use htmx is that it has a simpler interface optimized for the majority use-case.

With htmx, you are largely tied to a request/reply paradigm. Something happens that triggers a request (e.g. user clicks a button, or some element scrolls into view), htmx sends the request, and then it processes the response. The htmx interface (`hx-get`, hx-trigger`) is optimized to make this paradigm extremely simple and concise to specify.

Datastar's focus (last I checked) is on decoupling these two things. Events may stream to the client at any time, regardless of whether or not they were triggered by a specific action on the client, and they get processed by Datastar and have some effect on the page. htmx has affordances for listening to events (SEE extension, new fetch support) and for placing items arbitrarily on the page (out-of-band swaps) but if your use-case is a video game or a dashboard or something else where the updates are frequently uncorrelated with user actions, Datastar makes a lot of sense. It's a bit like driving a manual transmission.

Delaney is fond of saying that there's no need for htmx when Datastar can technically do everything htmx can [0]. But I think this misses the point of what makes htmx so popular: most people's applications do fit within a largely request/reply paradigm, and using a library that assumes this paradigm is both simpler to implement and simpler to debug. As an htmx maintainer, I often encourage people to even use htmx less than they want to, because the request/reply paradigm is very powerful and the more you can adhere to browser's understanding of it, the more durable and maintainable your website will be [1].

[0] https://data-star.dev/essays/v1_and_beyond

[1] https://unplannedobsolescence.com/blog/less-htmx-is-more/

andersmurphy

3 months ago

The irony that the Datastar author originally tried to have those features added to HTMX a few years ago.

amanzi

3 months ago

One important difference that I found is that HTMX (and Alpine AJAX) can easily push a URL into the browser's location history. I've used this feature often with my Django projects--essentially storing the state in the URL which is great for sharing URLs or bookmarking them. As far as I'm aware, Datastar have locked this feature behind the "Pro" paywall.

simonw

3 months ago

I really enjoyed reading this - very clear technical writing and I learned quite a bit about htmx and their approach to API design generally from it.

logankeenan

3 months ago

This is great! I had to create an xhr-fetch-proxy to use fetch and htmx. This change should open up a lot of fun possibilities.

https://github.com/logankeenan/xhr-fetch-proxy

recursivedoubts

3 months ago

in 4.0 the request cycle is totally open: you can replace the fetch() implementation on a per-request basis

learned that trick from fixi.js

masfoobar

3 months ago

Computer works in binary

htmx 1 htmx 2 htmx 4

I look forward to version 8 in 2030.

(Meaning there always was a version 3! Just include both htmx1 and htmx2 onto your webpage!)

huntercaron

3 months ago

> In 4.0, with the complexity savings we achieved by moving to fetch(), we can now comfortably fit a morphInner and morphOuter swap into core

It seems odd to me to treat these as different properties on their own? might as well keep it as an extension if it is not going to be more deeply integrated and let htmx 4.0 be smaller? Possible I may not be understanding the use case though

adamzwasserman

3 months ago

Interesting timing - I'm building genx.software which leans hard into implicit inheritance for the exact reason he is abandoning it. In my finance app, when the product owner changes their mind about decimal places for the 47th time (and it's always 47), the last thing I want is to hunt down every cell and add :inherited modifiers.

We treat everything as integers server-side (because floating point is the devil) and defer all formatting to the client. Implicit cascade means I can change fmt-x="currency:USD:decimals:2" in one place and watch it ripple down the entire table. It's 'maddening' the way CSS is maddening - which is to say, it becomes second nature after you stop fighting it.

That said, I fully understand the support ticket burden. Maybe the real lesson is: implicit inheritance is great when you control the domain (like 'format all money the same way'), but terrible when people want to do arbitrary things at arbitrary levels. I will bear that in mind as I complete genx.software

ranger_danger

3 months ago

The only big gripe I have about htmx is that the hx-on::after-request response it provides to your callback function does not automatically parse JSON content types like with e.g. jQuery.ajax(). Last time I brought that up, people simply questioned why I would ever want to do that in the first place.

recursivedoubts

3 months ago

in 4.0 we are opening up the entire request/response/swap mechanism so you can replace any component of it per-trigger

you can replace the fetch() function used w/ an event callback, etc

should allow you to do pretty much anything w/o any hacks

edoceo

3 months ago

That sounds like use-case exploration? Did you answer?

causal

3 months ago

Neato. Sensible updates, no loss of support for previous versions? The software dream.

ksec

3 months ago

Hopefully one day we will see htmx 4.0 being merged into HTML Spec.

epolanski

3 months ago

The image breaks the website on mobile for me.

fud101

3 months ago

I was just about to use this for a feature but i won't bother now, it won't pass the stability test. Thanks I guess.

jakubmazanec

3 months ago

[flagged]

patates

3 months ago

yes, you write this weird custom syntax that's interpreted in js, without writing any single line of js!

well, except when you want to do drag and drop sorting and this other thing.

yeah you get to communicate intent with html, but ignoring the security concerns for arguments sake, an inline script tag or your good old onclick event handler can do that too.

recursivedoubts

3 months ago

this one is really, truly the last version for sure

atomicnumber3

3 months ago

it's truly wonderful how much can be done and still be better than writing javascript

scuff3d

3 months ago

I feel like Carson Gross wrote this himself lol

epolanski

3 months ago

The only trolling I see is in your tone.

Okay, the author changed idea, so?

What's your point?