</> Htmx – The Fetch()ening

by leephillips • 9 months ago

361 142 9 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.

ranger_danger2• 9 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.

edoceo• 9 months ago

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

ranger_danger2• 9 months ago

One of the actual responses was "Htmx isn’t designed to work with JSON APIs at all. It needs HTML back from the server."

It sounds like they are referring to hx-swap and not arbitrary javascript callbacks though, and in that case, I don't see why calling JSON.parse() inside htmx (when the content-type is json) is that big of a deal.

recursivedoubts6• 9 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

booi• 9 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

jraph• 9 months ago

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

scuff3d2• 9 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.

SquareWheel• 9 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.

johannes12343212• 9 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.

pavon• 9 months ago

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

abnercoimbre• 9 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• 9 months ago

Traditionally, software engineers are smart people

drob518• 9 months ago

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

SwiftyBug• 9 months ago

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

tidbeck• 9 months ago

Got a https://en.wikipedia.org/wiki/Leisure_Suit_Larry#Leisure_Sui... vibe from it.

Waterluvian• 9 months ago

Spaceballs 3: The Search For Spaceballs 2: The Search For More Money

fmbb• 9 months ago

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

nchmy17• 9 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?

andersmurphy8• 9 months ago

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

nchmy17• 9 months ago

Better late than never. Everyone benefits with HTMX evolving and bringing more attention and capabilities to hypermedia-first approaches.

arcanemachiner• 9 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%.

nchmy17• 9 months ago

I can appreciate why people would have this perspective - I have been rugpulled a few times recently by thoroughly unscrupulous companies (Augment Code are trash humans).

But Datastar is different. The project is literally owned by a 501c3 non-profit. The devs have dayjobs and donate their spare time to this. Funds are for going to conferences or hosting their own

And 99% of the features/value that I mentioned is MIT licensed, and the "rugpulled" code is still available to easily port via the plugin API.

andersmurphy8• 9 months ago

Yeah HTMX should rebrand as DATASTAR LIBRE.

amanzi7• 9 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.

nchmy17• 9 months ago

Fair. Though, D*'s authors are pretty adamant that this is an anti-pattern - that's why they put it behind the paywall.

Moreover, the FOSS code still exists and would take 2 minutes to update to the current plugin API (I have Datastar pro and the code is almost exactly the same)

https://github.com/starfederation/datastar/blob/v1.0.0-beta....

fukka422• 9 months ago

Check out window.history.pushState

alexpetros4• 9 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/

andersmurphy8• 9 months ago

Why bother with v4 at all? If it dilutes that simpler interface?

I think that even with req/resp morph leads to a simpler majority use case and that's what Turbo and Datastar have both shown. No?

nchmy17• 9 months ago

Respectfully, almost everything you said is just plain wrong.

1. Datastar supports req/reply just fine - be it via normal text/html responses, or SSE (0, 1, or infinity responses) https://data-star.dev/reference/actions#response-handling. So, the crux of your argument is moot...

Moreover, if htmx's real value is ajax request/response, then why are you introducing SSE as a first-class citizen now?

2. Datastar has data-on, and various other attributes, that allow for triggering far more actions than just backend requests, from far more (any) events. I'm glad to see that htmx is now following suit with hx-on, even if it is apparently limited in capabilities.

3. Datastar can do OOB-swaps just fine - that's literally the core functionality, via (their own, faster) idiomorph.

4. Its a misnomer that Datastar is for video games etc - again, as described above, it can do all of the simple things that that HTMX can do, and more. And, again, why is HTMX introducing SSE if its so apparently unnecessary and unwieldy?

5. What makes htmx popular is that it was the first library to make declarative fragment swapping easy. And Carson is just a god-tier marketer. Its nice to see that he's now realized that Delaney was on to something when he wanted to introduce all of these v4 features to HTMX 3 years ago, but was (fortunately for us happy users) forced to go make Datastar instead.

6. We havent even talked about one of the key features - declarative signals. Signals are justifiably taking over all of the JS frameworks and there's even an active proposal to make them part of the web platform. D* makes them simpler to use than any of them, and in a tiny package.

I, Delaney, and all other D* users are grateful for HTMX opening this door. But I reiterate my original question - now that HTMX is becoming Datastar-lite, why not just use Datastar given that the powerful extras don't add any complexity and comes in a smaller package?

jaredcwhite• 9 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.

sudodevnull11• 9 months ago

I hope you realize literally everything is a plug-in. The core is < 4kb. Also Datastar is literally smaller than HTMX so this is already kinda funny

nymanjon3• 9 months ago

If you are looking for a very tiny foot print, you might like htmz-be.

amanzi7• 9 months ago

This looks great, although the version 4 alpha doesn't appear to be available at the suggested URL: https://cdn.jsdelivr.net/npm/htmx.org@4.0.0-alpha/dist/htmx....

"Couldn't find the requested release version 4.0.0-alpha."

ian-g• 9 months ago

It's named 4.0.0-alpha1. Just add the 1 and the link works

amanzi7• 9 months ago

Thanks. The docs need to be updated at https://four.htmx.org/

deepsun2• 9 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• 9 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?

mrj• 9 months ago

Maybe `heritable`?

recursivedoubts6• 9 months ago

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

Rendello• 9 months ago

If you're ok with an imperative verb, "propagate" could fit.

bruce511• 9 months ago

Heirloom

wpm• 9 months ago

“curse”

Like male pattern baldness, we are cursed by our parents to inherit it

PKop• 9 months ago

"propagate" seems the most accurate name for it

jonahx• 9 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".

treve• 9 months ago

or 'cascade' ?

deepsun2• 9 months ago

Well, I just remembered that in SQL "ON UPDATE CASCADE" is specified on downstream keys (children), not on their target (parent).

lazypenguin• 9 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

simonw• 9 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.

andersmurphy8• 9 months ago

Looking forward to porting my demos [1] from Datastar to HTMX once V4 is stable enough. Exciting stuff. Nice to see HTMX innovating again.

- [1] https://checkboxes.andersmurphy.com/

logankeenan3• 9 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

recursivedoubts6• 9 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

logankeenan3• 9 months ago

Yep, it's super nice. The Service Workers API also makes this really easy too. I experimented with compiling a Rust Axum server to WASM and then ran it in my service worker. Also, thanks for incorporating fetch into htmx!

I thought I'd include an example of replacing fetch for anyone that come across this.

    const originalFetch = window.fetch;
    window.fetch = function(url, options) {
      if (url.includes('/api/user')) {
        const mockUser = {id: 1, name: 'John Doe', email: 'john@example.com'};
        return Promise.resolve(new Response(JSON.stringify(mockUser)));
      }
      return originalFetch(url, options);
    };

https://developer.mozilla.org/en-US/docs/Web/API/ServiceWork...

adamzwasserman• 9 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

causal• 9 months ago

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

epolanski3• 9 months ago

The image breaks the website on mobile for me.

prokopton• 9 months ago

htmx hasn’t had the piss taken out of it enough.

recursivedoubts6• 9 months ago

100%

fud101• 9 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.

rtpg• 9 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• 9 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

JSR_FDED2• 9 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.

nprateem2• 9 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...

JSR_FDED2• 9 months ago

One of the things I had to wrap my head around was the whole async server style of programming. I learned that doing a sleep on the server consumes essentially zero resources. The thread goes to sleep and wakes up when the timer expires. In the meantime the server can handle other requests unhindered. You can have hundreds or thousands of these threads at the same time - serving requests, waiting for IO, etc.

It’s not like synchronous servers e.g. Flask with Gunicorn (in the Python world) where you have a few pre-forked server processes. In that case it would be a waste to prevent one of those processes from serving other requests while sleeping, I agree.

Ultimately it’s cool though to be able to control the client from the backend asynchronously, updating signals (think of them as a kind of special front-end variable with superpowers) when something on the backend happens, or updating the client’s DOM, or running scripts.

gazpachoking• 9 months ago

That's a contrived example to show how you can redirect from the backend (and the sleep is to make it easy to see it working.) It isn't a recommendation that you should do it exactly that way.

huntercaron• 9 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

masfoobar• 9 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!)

rbjorklin• 9 months ago

Any chance we could get a poll on changing the default swap strategy as documented in the quirks page? https://htmx.org/quirks/#the-default-swap-strategy-is-innerh...

ksec• 9 months ago

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

</> Htmx – The Fetch()ening

Related Stories