this will probably get nuked since it's just a point release, but there is an interesting new feature: it now has View Transitions support, an experimental browser feature available in Chrome 111+ that makes visual transitions between DOM states much easier to animate.

I discuss it in an essay here:

https://htmx.org/essays/view-transitions/

Chrome's docs on the feature are here:

https://developer.chrome.com/docs/web-platform/view-transiti...

MDN:

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

will be exciting to see this feature rolled out across the major browsers, as it will make vanilla HTML a lot smoother.

neat stuff!

you have a typo on that page under https://htmx.org/essays/view-transitions/#the-css : @keframes instead of @keyframes

thx, fixed!

I was curious about Mozilla's stance on the API. They have a GH issue for it: https://github.com/mozilla/standards-positions/issues/677

but it's not finalized yet. View the very interesting dashboard here: https://mozilla.github.io/standards-positions/

WebKit in a similarly undecided position: https://github.com/orgs/WebKit/projects/1?pane=issue&itemId=...

The Mozilla issue is labeled as "Position: Positive" and there is a comment that says:

> We're supportive of View Transitions, but since it's a new capability for MPAs in particular, we think it's important that the solution works well for MPAs and that it's consistent with the solution for SPAs. As such, if design changes are needed for the MPA use case that also affect SPA API, the latter should be updated as appropriate even though it has shipped. In other words, we think it would be bad for the SPA and MPA APIs to diverge or be inconsistent.

I don't think that's undecided. More like, "positive with some reservations".

edit: When I think about it again, perhaps you are right given the issue is still open (but also "ready to add").

edit2: Thinking about it more, I like the open process and all but perhaps such discourse should be private before being finalized as early commenters from Mozilla can have a premature influence on public opinion.

> but perhaps such discourse should be private before being finalized as early commenters from Mozilla can have a premature influence on public opinion.

No, it shouldn't. It's a good thing all discussion is happening in the open. See how Firefox devs still have their reservations but Chrome already shipped it to prod completely ignoring any such reservations.

FWIW, that's a pretty standard behavior for Chrome teams) and, as far as I understand, related to how they are evaluated within Google.

More spec proposals == good for your career.

Shipping a feature (even if it's non-standard) == good for your career.

Ensuring standard-compatibility == noop.

Source: I used to be a browser dev annoyed by how Chrome kept shipping non-standard features.

That's a feature, not a bug.

As long as Chrome has > 80% market share, the more non-standard features the ship, the more they cement their position.

Same as IE6, which was intentionally non-standards. Sites would be designed to work in IE, and would not work on Netscape.

Considering how much spying and how much lock-in Chrome provides for Google, anything that makes devs design for Chrome only is a huge advantage.

This seems like a big leap forward for web apps! Proper view transitions are one of the biggest gaps in usability and perceived smoothness between web and native/Flutter apps at the moment.

Where might I find a red cap that says "Make apps HTML again"?

Surely the cap is gray, and the font color is Ed:black, except for "HTML" which is blue and "again" which is purple (and possibly both are underlined)?

I know this is tangential but I was trying to decide what I wanted to use to make an app that could be accessed from android, ios, and desktop in a convenient way. I am not a fan of how churny the js world is, and I come from a background in Swing/Qt/GTK/etc desktop development.

I evaluated HTMX as a not-js way to do modern web apps. It was fine, it was certainly interesting. I had some concern about how much pain I would be in for when I inevitably wanted to borrow something from the js ecosystem, like a charting library or something.

I actually ended up deciding on godot with gdscript and while I'm not done yet, I'm having a pretty dang good time. I'm a little annoyed that I have to pay apple to get it on iOS, but I have to pay apple anyway because safari is such an annoying odd one out from how firefox and chrome's renderers work. It's always safari that has weird things it doesn't like, in my experience. And I have hope that either Epic Games or Europe will manage to force Apple to let people sideload apps.

Doesn't godot refresh the entire screen at X fps? That would kill battery life, no? Asking cuz I considered this route before but decided against it for battery and app loading time reasons.

Godot does have a low CPU mode that limits screen refreshes until something is interacted with on screen or animated, it's what the actual editor uses. I'm not sure whether it works on web exports though.

Might be worth double checking. Last time I read, this mode wasn't supported on mobile devices, which is precisely the ones more sensitive to energy use.

godot ticks at that rate, but if you don't transform UI things, they don't get redrawn. so maybe the framebuffer is switched every frame, but draw calls shouldn't be reissued unless needed.

also, I think it is possible to make it not tick from time updates, but only from input event updates, or maybe an animation actually running. similar to what the editor does.

It still consumes more battery than an HTML page on a browser, doesn't it? Can't tell how significant is the difference, though.

From what I could tell the sweet spot for HTMX would be much more targeted at adding some JS magic to an existing backend server based web app (i.e. Django, Flask, Rails) where the developer primarily is a Python/Ruby, HTML/DOM and database expert and doesn't want to get bogged down into supporting a full fledged frontend like React, Angular, etc. to add some UX flair to their mostly CRUD based app.

Native apps (i.e. iOS, Android, MacOS) purely in HTMX is probably not its sweet spot. Probably Electron (or Godot) would be better.

there is a really neat mobile-native hypermedia called HyperView:

https://hyperview.org/

which is discussed in depth in our book:

https://hypermedia.systems/book/hyperview-a-mobile-hypermedi...

Question. Have you ever seen someone use htmx in a capacitor/cordova app? I would rather use htmx like I have been instead of a different tech (like Hyperview)

Turbo is pretty similar to htmx and Turbo iOS produces some stellar experiences https://github.com/hotwired/turbo-ios

Funny you mention turbo/hotwire, I actually encountered a bug almost immediately after upgrading to Rails 7 where for some reason HTML5 video tags would work after a real page load but would not (with no error messages or anything) after a hotwire/turbo-"page"-"reload". I tore hotwire and turbo out and it worked.

Oh, this was only on iOS and macos Safari, of course. Worked fine on FF/chrome.

IMO the killer feature of htmx is quick prototyping. You can have an application really quick, only with some html templates in views. Maybe tailwind too, and you can skip css and js.

I am using d3.js inside an htmx app with no problems.

So htmx works flawlessly with any other JS library?

Asking because of my limited knowledge. If you happen to have a blog post or something on that, would be helpful.

I don't like libraries creating their own languages, but if one had to, they better have docs like you have. Amazing.

I gotta start blogging about that system because it really is cool.

HTMX is not too different from Jquery in terms of how it works so it is compatible with most if not all JS libraries. In my case I have

       <script src="https://unpkg.com/[email protected]" integrity="sha384-wg5Y/JwF7VxGk4zLsJEcAojRtlVp1FKKdGy1qN+OMtdq72WRvX/EdRdqg/LOhYeV" crossorigin="anonymous"></script>
       <script src="https://d3js.org/d3.v7.min.js"></script>

in my header and I write JS that uses d3.js from a <script> tag, I am not messing around with a Javascript build system but I see no reason why you couldn't have a react app that is compiled and lives in a <div> inside an htmx page.

In my experience, yes.

A large part of playing nice with other JS libraries is that HTMX works with the DOM in the browser, instead of creating a Virtual DOM (VDOM) like React and Vue (and others, eg. Solid.js) do, which leads to a lot of libraries only working with those platforms they're made for. Which is a great tragedy IMO.

I would be much more comfortable with the Epic Games App Store if they just let me pay to submit my app instead of micropurchase a bunch of loot boxes hoping that one has a submission crystal.

What kind of app is that? Wouldn't it be hard to create user Interface in godot especially text editing components, radio, check and select boxes etc?

gotdot's editor itself is built in godot, it has an entire suite of Swing/Qt/etc-feeling components and GUI layout stuff.

A long-standing frustration for me is that I always felt like it was really easy to make a responsive layout with Swing (I know desktop apps don't deal with quite the gamut of weird aspect ratios that websites do, but for the apps I built users typically tiled them and resized them between portrait/landscape and various sizes based on need and if they were actively using them or just passively monitoring them. So a lot of the considerations felt very similar compared to modern web design), whereas in CSS it's such a struggle comparatively (though flexbox and css grid and several other similar things have improved it a lot).

Now that, compared to godot, godot feels a lot more like the productivity/design experience I got out of Swing and friends.

Fantastic update. Also, I can't wait for Hyperscript to get to its maturity (1.0). ;)

Does it play nicely with custom elements and the shadow DOM?

I'm using a combination of RiotJS and HTMX. But RiotJS isn't exactly shadow DOM.

as far as I understand, it does a visual snapshot of the DOM, so it should work w/ custom elements just fine

It's a bit of an aside, but what do you get from the shadow DOM?

I've given a real, honest effort to using the shadow DOM for a bunch of WebComponents and it just seems like it makes everything harder for no benefit that I've been able to find. Every example I've found of WebComponents using the shadow DOM seems to show many many lines of weirdly-inverted HTML (templates/slots) and JavaScript, all to achieve what I can do in a few "document.creatElement"s (vanilla JavaScript) that are easier to understand. And using the shadow DOM means my global CSS styles don't apply to what I do there without absurd hacks.

I have honestly been looking for a benefit here, but I just don't see it. What am I missing?

I don't like having a bunch of styles fighting each other. It is similar to the !important stuff. In fact I sometimes thought it was better before !important was verboten. It was overused, though.

Only the shadow DOM provides some relief from this annoying part of web development.

Svelte does it in the compilation phase without shadow DOM.

I understand that precompiling is an extra step, but the React codebases that use shadow DOM are doing precompiling anyways (tsx), in which case it doesn't make sense anymore.

Not a fan of all this prefixing even if it works most of the time, it's a kludge IMO.

The state of code distribution in js is pretty sad IMO. Most es modules are faked. I would like the opposite of Vite where the real es modules are in production. Modules aren't just treated like a toy in other languages. :(

Prefixing should be web components instead probably (for some reason Svelte doesn't default to it, but there should be a push to make it work).

About Vite: I agree, it's not how it should be done. Svelte components should be compiled to real modules with real, easy to understand paths. I would love to use a system that actually I understand, and just compile things to module imports. We could hack it together maybe, it's HackerNews anyways :)

I mean, the shadow DOM practically forces you to put the styles with the elements they style. If you're going to do that, there's nothing stopping you from just exclusively using the style attribute in HTML, which would achieve the same result without the shadow DOM.

In my experience when I start running into problems with competing styles it's usually because I've not structured my CSS well, although admittedly, structuring your CSS well is pretty hard to do.

adoptedStylesheets will help with that. Already you can mix them in from any source, it’s just plain text.

Also the styles may contain variables and those can be inherited. So the design can be shared even if you aren’t pulling in shared styles.

You are correct. If you control the webpage, just get good and write correct CSS (including new CSS layers). If you don’t control the page, Shadow DOM is actually leaky in weird ways (inheriting fonts and colors, for example), so you want an iframe. There’s not many good uses for it, and it should be a CSS thing, not a JS thing anyway.

To me the major benefits of shadow DOM only come into play when you're making a web page composed of components that you don't fully own. Whether that's different teams maintaining different components, or you acquired some components from a third party vendor, or even just to isolate your host's (like wix/other site builders) components from your own. Shadow DOM lets things play together more nicely and without as much mutual trust needed.

If I understand correctly, https://htmx.org/api/#process

Woah--I stumbled upon "Hypermedia Systems"[0] from the View Transitions essay linked on this release page. If, like me, you're sympathetic to the htmx philosophy, but not really an expert, it looks like a great read. (And it's beautifully presented, too.)

Seems it was discussed a few months ago[1]; I missed it then.

[0]: https://hypermedia.systems/

[1]: https://news.ycombinator.com/item?id=34134545

If you are on the fence about using htmx in production. my startup[0] uses it exclusively for our frontend (with like 2 lines of hyperscript. It’s sister library). No complaints and boy, it’s such a fresh breath of increased productivity and still excellent user experience.

We still had to build an API anyway for external organizations using our product, but you still skip a ton of unnecessary JS code.

0. GalenAI.co

What's the back-end? Do you generate those HTML responses via a normal template engine, or is there some sort of deeper integration with HTMX on the backend?

It’s Django.. request data in, html response out. That’s all what you need :)

How do you handle template and fragments? any libraries/usage patterns you use to integrate django <-> htmx?

If you're lazy, just develop your django app as usual, and use hx-select attribute to select relevant content to use in htmx. Django doesn't have to be aware of the fact that you're using htmx in the client side.

https://htmx.org/attributes/hx-select/

Awesome, thank you!

Why would it need anything special? Django doesn't care what templates contain. You can have a template with literally anything in it, including HTML fragments.

Usually we have a base template with a content block that a child template can extend. The extend keyword supports variables as well. So we can create a dummy base template, e.g. fragment_base.html, that contains only the content block and if a request is coming from HTMX we set the base template to the dummy one, so the rendered template will contain only the fragment.

I'm asking because I've sort of done this in the past, and find creating fragments of HTML with Django's template engine a bit awkward.

For instance, if I have some sort of utility button, and say I put it in "utility_button.html", a template file. In practice, I might have to supply different actions, or icon names, or colors when the button is generated, which means that each of these potential variable needs to be a template parameter. Adding a class involves some string manipulation magic.

On the other hand, on most client-side front end library, when using a template, I can still slap whatever attributes onto the element, or manipulate its classes as an actual list with relative ease, because front end libraries are more or less already a big HTML parser and generator.

Same, using it for https://findsight.ai (combined with Alpine). Backend is Nim & karax which makes HTML responses a breeze (fragments and full page).

It took me a second to get the hang of it but your app is cool as hell. I recommend everyone click it.

One comment on the UI, on my phone it was not obvious that adding the topic tags was working, because they get added off screen. I was just clicking "ancient-greece" like an idiot for 30 seconds then I accidentally scrolled down and saw what was happening.

Thanks, good feedback.

Echoing another commenter, your app is super cool. Bookmarked.

One UI note, the layout jumping around when typing or clicking on things is a little jarring. E.g., the "Word is too short" message pushes the field the user is typing in down the page.

Great! Yes, all these micro-interactions are something that's on the backlog. I focused on getting the MVP out (it's been here for barely 2 days) and will improve the experience in time.

Wish htmx supported WASM - ie instead of sending a request to the server, you send the request to the hosted WASM module and render the response. Ideally, one could then use Rust web-frameworks such as Axum on the client side.

Anyone planning to make a browser with native support for HTMX (instead of a full JavaScript runtime)?

I only ask because I kind of wish such a thing existed.

I still can’t find a happy medium between no JS and “browser as an entire OS”.

my hope is that, at some point, the browser developers notice htmx and decide to fold its functionality into HTML itself, which is where most of this stuff belongs

Htmx has such an old man yells at cloud vibe. People don't like fat js clients because of "view transitions", they like the developer experience, composability of components, and benefitting from a vibrant ecosystem that is constantly innovating.

I despise JS clients because I hate waiting for the entire thing to download and initialize every time I visit a site to make a quick change. Looking at you, Hello Fresh.

Most popular js frameworks support SSR - it isn't appropriate to use an SPA for a public app like Hello Fresh, that's on them.

I just like the user experience coupled with a dead simple development experience. Simple CRUD webapps, which is a lot of things, don't need unique user experiences; oftentimes the less unique the better.

Constantly innovating can also be interpreted as 'having no standard'.

I had developed sites for 25 years. I still have a corporate site that was developed 20 years ago, and it returns more results, and is faster to render than most of new fangled SPA I seen deployed on servers 20x larger.

I do agree with you that SPA (react and its ilk) have cleaner benefit of composability of components, but I would posit that AJAX and component state/props has made for less reliable web. I often find myself in situation where SPAs crash mid way during concert or flight purchase - be it JS error, or network instability. Reloading the page doesn't get SPA to resume where it crashed, but often throws additional errors, saying I am already mid way in checkout (but I can't continue), or invalidating session (but still remembering that my other session was in process of buying a seat, so I can't reselect the seat I wanted. Finally, they are terrible for bookmarking or sharing.

So the composability of components, a benefit, came with a need for developer to be extra careful about failure modes, resuming states, bookmarking directly to specific content. Most developers are not careful, and the old html per page model forces different mentality for dealing with failures, and content availability.

People are emotionally attached to SPA's because they are:

1) Annoyed by page refreshes

2) SPA's is a special skill now, frontend developers take pride in knowing everything about React, Vue, Angular and spending hours and hours updating their NPM dependencies. How can they justify all the time spent if it's not almost like a science?

3) Separates the frontend guys from the backend guys. Technologies like HTMX allows the backend developer to pretty much do the whole job, which concerns a few people.

Eh, backend devs don't want to do the whole job. They want to provide a single excessively complicated API which all client-side (web, Android, iOS, TV, IoT, etc) devs can consume without disturbing them (at the cost of 10 requests to render a single page). They definitely do not want to be involved in generating specific HTML fragments and subsequently fiddling with them whenever a designer decides something needs a minor alteration.

I've looked a bit for examples of HTMX in the wild, and the only times I've found it it's been so slow I would have preferred a full page refresh which at least lets me bookmark/navigate properly and involves no JS at all. Not enough data to really form a strong opinion though, I freely admit.

> They want to provide a single excessively complicated API which all client-side (web, Android, iOS, TV, IoT, etc) devs can consume without disturbing them (at the cost of 10 requests to render a single page)

I've seen that quite a few times. Basically moving the entire business logic to the frontend, so that the backend can remain elegant and generic (yet somehow complicated too). In the end it actually makes for a slower app experience and may cause insane complexity on the frontend.

Allowing a backend dev to do frontend should concern everyone. They are very distinct skillsets.

That's not true though. Yes, if it needs to be a complex and breathtaking frontend that has all the bells and the whistles.

But backend developers often need or have a desire to build a perfectly usable frontend for their service, without relying on a frontend person to start with. This could be due to project ambitions or budget.

This. Especially airplane bookings always fail.

well, i am old and i do yell at clouds (i live in montana, and it's been a really long winter)

but...

am i out of touch?

no, it is the children who are wrong...

Indeed ! HTMX is one of these rare tools that have an immediate, high added value with very little to no learning curve and no downside... a complete no-brainer, I love it.

This is the best response possible!

People don't like fat js clients because they are bloated and very often provide subpar UX (spinnerfest, broken back, etc).

If HTMX is "old man yells at cloud" meme, then fat js clients is "I have no idea what I'm doing" meme.

As someone else pointed out in another comment, htmx is not a replacement for JS frameworks. It is a way to add some level of interactivity without needing to learn too much about UI development. The authors actually recommended coupling htmx with a client side framework if your needs are more complex.

> constantly innovating

Don’t mistake activity for achievement.

What's the consensus on using custom HTML attributes such as "hx-post", "hx-trigger" and so on, which are "invalid" according to the spec? I don't mind prepending data- to custom attributes but it's still a minor nuisance.

Data attributes are accepted. From the docs:

> It’s worth mentioning that, if you prefer, you can use the data- prefix when using htmx:

> <a data-hx-post="/click">Click Me!</a>

Why is it slow? For example in https://htmx.org/examples/click-to-edit/ and https://htmx.org/examples/edit-row/ when I click the edit button, there is a noticeable delay between click and appearance of editable boxes.

I don't see any network requests being sent.

It seems to just be a simulated delay and should probably mention that if that's the case. Running the first example locally does indeed attempt to send a network request when clicking the edit button.

all the demos use a mock ajax request library (sinon) so we don't have to run a server

i intentionally introduced an 200ms delay so that you can see things like request indicators:

https://github.com/bigskysoftware/htmx/blob/master/www/stati...

Why would there need to be any sort of network request to show edit fields?

well, if you are using a hypermedia style application then you want to make a hypermedia exchange on an interaction to bring down the hypermedia representation for editing a particular resource

So any UI change requires a network round trip?

Well, there are UI changes and then there are UI changes.

https://htmx.org/essays/hypermedia-friendly-scripting

In general, I'd recommend perusing the essays to get a flavor of the style of web application we are advocating for:

https://htmx.org/essays/

And, if you want more, taking a look at our book:

https://hypermedia.systems

Yep and that’s ok in some cases.

Not required, you could still use js if you wanted.

Why don't you stop posting questions to this page and take the time to read the Htmx landing page? It answers all of your questions. https://htmx.org/

Because they are actually two distinct views: one is a details view, the other one is a form view. HTMX loads the form view and replaces the respective part of the page. But it needs to contact the backend for the form, you don't have the data model on the client like with an SPA framework, so you cannot generate the form.

So any UI change requires a network round trip?

You're probably comparing htmx with client-side framework like React. Unlike those client-side ui framework, htmx is used to enhance standard html pages, such as those outputted by server-side web framework. Those frameworks typically renders detail and form page separately, and htmx can combine them into a single interactive page. For example, when you reply a comment in HN, it'll open the form as a new page, and when you submit the comment, it open another page. htmx can combine all of those pages into a single interactive page.

But it's still as slow as two separate pages?

Should be a bit faster because it only requests a piece of html fragment which then get swapped into the dom instead of reloading the whole page again.

there is a good talk on a real world react->htmx port here:

https://htmx.org/essays/a-real-world-react-to-htmx-port/

in which improved performance features as a big part of the realized benefit of the conversion

of course, not every application is going to be amenable to a hypermedia-style approach, so your mileage may vary:

https://htmx.org/essays/when-to-use-hypermedia

Slower than what? In my experience, simple page loads are usually blazingly fast assuming you're not on 2g or something.

It's heavy client-side frameworks that often feel slow.

You've never used backend frameworks like WordPress? They can be very slow.

Yes. That's why I specified "simple page loads". If your frameworkless website is slow then the fault doesn't lie with the nature of http or the intrinsic overhead of full page loads. You've got a shitty backend framework, database or network.

Are your (repeated) questions in good faith, or are you taking a swipe at the project?

I'm hoping a future version will allow using hidden markup that's already in the DOM rather than fetching from the server.

It's already supported with the client-side-templates extension [1]. HTMX can fetch JSON from the backend then calls e.g. nunjucks.render() with the data.

[1]: https://htmx.org/extensions/client-side-templates/

On a sufficiently long timeline we'll see full SPA frameworks on top of htmx ;)

Not at all, you can preload as many data as you wish and use vanilla or a companion JS framework like Alpine.js or HyperScript or any web-component to make the current page interactive without fetching the backend. It's a trade-off between the initial page size vs. additional network delay.

Is this actually a reasonable scenario for using HTMX? Is JavaScript even required?

HTMX is basically a JavaScript framework that makes the traditional request-response approach feels like an SPA via replacing only part(s) of the current page with the response. In this case: it loads a small form, submits it to the backend, then replaces the respective part of the page with the updated markup. The state is kept only at the backend.

With some constraints you can create a page that works with or without JS. The same endpoint can be used for serving HTML fragments for HTMX and full page for JS-disabled clients since the HTMX request can be detected by the HX-Request header.

> ...basically a JavaScript framework that makes the traditional request-response approach feels like an SPA via replacing only part(s) of the current page with the response.

Didn't that used to be called AJAX or REST or something?

Yes! HTMX is a better API on top of a XMLHttpRequest for this approach. A hypothetical next iteration of the HTML standard could make most of HTMX unnecessary. Maybe one day.

Answering my own question, you can make an element appear using just CSS and a hash:

https://enmascript.com/articles/2019/09/26/toggle-content-on...

I don’t like messing with the URL to achieve this, so unless using the “details” element, maybe JavaScript is actually the best approach…

Because the data might have changed between displaying it and opening the edit form.

May be it's worth adding a note on these pages that you are simulating network by introducing delay.

as an embedded developer, CSR+SPA is the default way to do it these days, my embedded board(with limited resources that can not run python/django/etc) only needs to provide some json data but htmx expects backend spits out html.

Not sure if it's possible for htmx to work with haserl or some c-based cgi or even lua-based lightweight web framework, I guess it could, just not popular so nobody did it.

If I am not mistaken, last time I looked at it I think I saw that HTMX has the ability to declare handlers. So that if you instead want to provide Json, one of those handlers could transform/handle it client-side. I think, haven't tried it myself.

Any backend that can spit out html fragments should works. The backend doesn't have to be aware of htmx. Heck, the response doesn't have to be a fragment either because you can just select which part of the response to update the dom with using the hx-select attribute.

I'm currently using htmx on my latest project to only change parts of the page that need changing. This is fine, but I am finding some weirdness happening in that design though. For example, if I load a portion with some JS in it, the consecutive times I load it, gives me "already declared variable" errors. I guess this is because the JS stuff is hoisted outside of the area it's called, so when it's recalled, it hasn't been removed with the previous request. My solution has been to use `var` but I guess this is not the best solution and something more fundamentally wrong.

Read up on HATEOAS - Hypermedia as the engine of application state. Long story short, don't use J's to store state, use html responses.

I use `window.someVar = "blah"` instead of `var someVar = "blah"`. It's a dirty hack, but it works around the re-binding issue.

> Unfortunately for HTML, CSS transitions are only available if you use JavaScript: you have to change elements dynamically in order to trigger the transitions, which “vanilla” HTML can’t do. In practice, this meant that only the cool kids using JavaScript to build SPAs got to use these tools, further cementing the aesthetic superiority of SPAs.

I'm sorry if my question is not sufficiently informed, but how does HTMX not "use JavaScript" to trigger animations?

Have followed the library and approach for a while and tend to compare it to Alpine, which I find a bit more intuitive.

But that's probably exactly because Alpine isn't shy about the fact that you're writing JS in the end.

I found such solutions (Alpine) a grrat joy to start working with (e.g. a complex form with nested fields, custom autocomplete...) and a nightmare to extend or generalize.

The Chrome transition API is very interesting. Also, there certainly is a place for controlling JS via HTML.

But for the risk of sounding inpolite:

Having read a couple of posts by htmx team, the "htmx is hypermedia, SPAs were invented because X and are a crutch" style intro starts to feel a little repetitive and dated to me. Every post starts with a bashing of "SPAs", it gets tiresome very quick. SPAs can be simple, they can be complex nightmares.

So can HTML-centric "sprinkles of JS" that outgrow their purpose.

Also, who are these "cool kids writing SPAs"? It's 2023 and it's irrelevant if you generate your HTML in PHP, JS, Rust or Python: you need abstraction and modularization for large frontends.

That's the problem React solves, not just fluffy page transitions.

> it's irrelevant if you generate your HTML in PHP, JS, Rust or Python: you need abstraction and modularization for large frontends.

Yes, it's just that some of us prefer to leverage our existing stack (ie. abstract and modularize with Django/Twig templates) than adding yet another layer to the lasagna. Nothing against SPA frameworks (ex: we do use Vue/Vuetify for some apps with complex user interface), but there are many cases where it's actually just bloat.

Before I begin to ramble; I don't see where your "just" comes from, in other words, where is the difference between our two statements?

> > it's irrelevant if you generate your HTML in PHP, JS, Rust or Python: you need abstraction and modularization for large frontends.

> Yes, it's just that some of us prefer to leverage our existing stack (ie. abstract and modularize with Django/Twig templates) than adding yet another layer to the lasagna. > Nothing against SPA frameworks (ex: we do use Vue/Vuetify for some apps with complex user interface), but there are many cases where it's actually just bloat.

Sure, I agree with you!

But this has been discussed ad nauseam over the last 10 (15?) years, hasn't it? Who really argues against your approach if it works for you?

What I don't like is the contrarian attitude of htmx team and the pretence of not using JavaScript. It's just progressive enhancement, a valuable and very old approach.

IMO, an approach best implemented without a "framework" like HTMX.

I mentioned Alpine, in combination with blade "components", which are just fancy template partials. Alpine is a library that fills a similar purpose as HTMX.

You can't implement client-side interactivity using Django or Twig templates, but you don't want to generate your HTML in JS.

That's where the htmx approach begins, as far as I understand, which is why I compared it to Alpine.

Kudos to the htmx developers, who made a library out of their idea of progressive-enhancement JS.

My point is just that I don't like two things which seemingly repeat in each of their blog posts:

- They define their own language around REST and hypermedia to explain a string-language in HTML-attributes, which is then executed by JS. It's really not much different from Alpine. It's called "progressive enhancement" and a DSL in HTML attributes is not needed to implement it

- They start most posts about their library with a lengthy ramble about "cool kids and SPAs" vs "good old server-rendered HTML". This is a tiresome trope.

The first time I read their "HATEOAS / Rest is for humans" article, I found it witty. The second time I read an article explaining their appproach, I found it interesting.

By now, I just skip all the htmx stuff and jumped to the meat of the post, the new (JS!) API for page transitions.

I'm not really interested in learning a new "JS-in-HTML"-language.

TL;DR: Have you ever heard of frontend-fatigue-fatigue? :D

I wrote lots of vanilla JS which abused HTML attributes in similar ways.

For a simple landing page, I'll probably try htmx some day instead of writing this myself.

But I tend to not like this whole approach of "magic strings in HTML". When I do this in my own code, the point where an internal alarm rings is usually when HTML attributes start referencing comma-separated lists of unchecked... somethings (usually IDs).

Okay. I don't really care about the HTMX team attitude, the way they start their blog posts (that I don't read) or this funny concept of "frontend-fatigue-fatigue" so... what's left for me is a very useful tool for certain use cases that they kindly offer for free. But to each his own.

I know nothing about Alpine, will check it out.

Yes if htmx is the right tool for you, all power to you. I was not meaning to provide more than a tangential thought on their outward presentation.

an href is just a magic string in HTML :)

I'm old enough to remember the mess it was to force a file download at link clic. Now it's just a matter of using another HTML attribute. So yes, I like magic attributes. Actually, I wish something like HTMX was embedded in the browsers.

If it's well thought out, sure, why not. But the examples in the HTMX docs for me are mostly not as simple as common HTML attributes.

E.g. these are examples for what I meant by "DSL in HTML attributes":

    <input type="text" name="q"
        hx-get="/trigger_delay"
        hx-trigger="keyup changed delay:500ms"
        hx-target="#search-results"
        placeholder="Search..."
    >
    <div id="search-results"></div>

In the end, of course, standardized HTML has DSLs in attributes too (e.g. srcset, sizes...).

Using the word "magic" might have been a bit snarky, that's always a question of definition.

I meant that the behavior is neither standardized nor simple code that can be read as such. With Alpine it's the same, it's code in HTML attributes, but not all regular JS rules apply.

The first example for the transition from the release notes is another one:

    <div class="sample-transition">
       <h1>Initial Content</h1>
       <button hx-get="/new-content" 
               hx-swap="innerHTML transition:true"
               hx-target="closest div">
         Swap It!
       </button>
    </div>

Strings like "innerHTML transition:true" or "closest div" and the whole thing in combination are just not too much my taste, and I find that this is not really simpler than just writing JS.

But I can see how it fills a niche and I don't want to argue against this idea as such.

Just the presentation I can't understand.

HTMX is not an "extension of HTML" for my understanding, it's a JS lib that parses non-standard attributes using a DSL. Doesn't need to be bad.

Regarding the "download" attribute: I love it too, and I always love when I find out I can do something easily in HTML and CSS without using JS. Similar example, maybe not useful so often: the form attribute.

> E.g. these are examples for what I meant by "DSL in HTML attributes"

It's a DSL, sure, I won't argue about that. Matter of taste I guess, but I actually find this example you posted super easy to read, even the hx-trigger value. That's precisely what I like about HTMX: you get quite a lot done in a few attributes, while still remaining very readable. If the attributes value is too complicated or too long (ie. difficult to read), I would probably rewrite the logic in a simple JS function anyway.

> I always love when I find out I can do something easily in HTML and CSS without using JS

Ditto. When I wanted to play a media, it used to be some bad combination of flash object with JS bindings... now it's just a single audio and video tag. What a time to be alive...

what I'm saying there is that CSS Transitions aren't integrated into the normal hypermedia flow of HTML, which is what htmx tries to address

we have never said that SPAs are a crutch, our (really, my, there isn't much of a team and I don't speak for anyone else) claim is that SPAs are as popular as they are for advantages that are not inherent to them when compared to hypermedia, and htmx tries to narrow that gap

i am sympathetic that people reading the various essays on the htmx website might get worn out by my repetitive beating on hypermedia, but consider that for every repeat reader, there are tens or hundreds of new readers who haven't heard much about or thought much about hypermedia. Repetition is a key to teaching, and I teach, so maybe that influences how I write as well.

regarding abstraction and modularization being key to large front ends, I sort of agree to an extent, but I think that at the system level that abstraction can be hypermedia and that the modularization can be done server side

of course it always depends on the app, htmx/hypermedia isn't right for everything, etc. etc. as we try to point out in an essay on our site:

https://htmx.org/essays/when-to-use-hypermedia/

do I get a little punchy about SPAs at times? Sure, it's the internet after all. I've been fighting for the hypermedia-oriented approach for web development for a decade now, and I've been called "old", "irrelavent", "pointless" and "stupid" many times along the way by SPA fans. There is obviously some conflict between my views on web development and the larger front end world's perspective.

But I try to be reasonably balanced about the tradeoffs, even while I think that the SPA approach is dramatically overused today.

First of all congrats on creating a project that people want to use. I hope to one day join your ranks!

First impressions from someone who's had a hand in many large scale consumer centric UI's.

- I have a decent grasp on hypermedia as a concept. Not sure why I should care

- The focus on hypermedia strikes me as dogmatic

    - it brings me back to the holy wars of gatekeeping "restfulness"

    - or the battle to strictly adhere to semantic web

        - Nooo, style classes can't be used in markup! that's what selectors are for and I'll literally die on this hill

    - In the middle of the restful holy wars at least everyone could agree allowing clients to query data was insanity. Insanity i say!

        - ok maybe graphql makes a little sense

- The htmx value prop seems to be scattered

    - people who value "hypermedia"

    - devs who have "javascript fatigue"

    - based on sentiment I've seen users tend to be the latter

- As far as the tech itself (again quick first impression)

    - i feel like the "api" is somewhat over-abstracted

    - seems like much of the functionality would be a jquery one-liner but with the syntactic sugar of using html

        - this pattern taken to the extreme reminds me of coldfusion markup and I don't mean that disparagingly!

    - jquery is popular bc the api strikes a great balance between over/under abstraction

        - syntactic sugar, effective primitives, plugins for the rest

        - to contrast htmx seems to emphasize high-level functionality

On the ideological grounds of "semantic web" having logic and tags sprinkled thru the UI feels questionable and challenging from a unit testing perspective.

- Given a code sample with the exact same syntax what benefit is there to template/interpolate on the server vs the client side? The downsides seem pretty big. Strings with "X time ago" become stale. More network round trips. Interpolated data has to be parsed to be queried locally, but I guess you could add another network request. Given the typical react/SSR setup I don't even have to think about server vs client side and benefit from both worlds. Anyways sorry for the ramble - I'll be following!

Great release ! I've been thinking about something like "hx-on" for quite a while and I'm glad I'm not the only one.

htmx seems like a very attractive alternative to using a bloated JS SPA framework, especially if you are building an app without very complex state requirements. I actually love Python/Django, Ruby/Rails, and Elixir/Phoenix, and htmx can free devs to use their favorite back-end technology without worrying about duplicating logic.

The only danger I see is devs having more-than-basic interactions and UI updates going off the deep end when trying to integrate htmx with their favorite back-end stack and thereby inventing a new, ad-hoc full-stack framework when Django+Unicorn/Reactor, Rails+Hotwire, Phoenix+Liveview, etc. already provide good, coherent abstractions. If you’re going to be sending HTML over the wire throughout your app, you might be better off using something optimized and battle-tested than trying to roll your own framework.

What's the use case for Htmx? When would someone want to use this over more tradional approaches?

What do you mean by traditional?

For example, having some Django or RoR render forms and handle submit with a full reload, or another case where client would query some endpoints via JS fetch API and handle the responses that way.

TLDR: htmx can give you the UX of the later with the simplicity of the former.

I would recommend reading the essays on the htmx website for more in-depth discussion:

https://htmx.org/essays

HTMX should have a way to have JS modify the response before it is inserted/handled.

    <div hx-preinsert="myfunc">Old Content</div>
    <script> function myfunc(callingElement, serverResponse){ 
        return modified-Server-Response 
        }

IMO, aside from the fact that such a feature really is needed, the lack thereof pushes people to Marko, Livewire, etc, simply because they need to do add some tiny detail which is available in the JS. Besides that it makes HTMX look like a toy that values purity (no frontend JS) over practicality.

I know there are ways to build a plugin, but do not have the time or headspace to figure it out.

Maybe the new feature 'hx-on' can help with that ?

You can use the `htmx:beforeSwap` event to transform responses if you'd like:

  <button hx-get="/example"
          hx-on="htmx:beforeSwap: event.detail.serverResponse = transformResponse(event.detail.serverResponse)">
    Example
  </button>

In general, htmx is going to lean on events for integrating scripting into the hypermedia flow.