Htmx 1.9.0 has been released

https://htmx.org/posts/2023-04-11-htmx-1-9-0-is-released/

by vyrotek • 3 years ago

351 142 3 years ago

this will probably get nuked since it's just a point release (no hard feelings dang), 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.

clairity• 3 years ago

neat stuff!

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

recursivedoubts14• 3 years ago

thx, fixed!

afraca• 3 years ago

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/

rmorey• 3 years ago

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

udbhavs• 3 years ago

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.

durpkingOP• 3 years ago

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

e12e• 3 years ago

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)?

ye-olde-sysrq3• 3 years ago

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.

Takennickname• 3 years ago

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.

DisownedWheat• 3 years ago

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.

boterock• 3 years ago

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.

somethoughts• 3 years ago

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.

recursivedoubts14• 3 years ago

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...

hokumguru• 3 years ago

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

mejutoco2• 3 years ago

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.

PaulHoule2• 3 years ago

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

wg02• 3 years ago

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.

riwsky• 3 years ago

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 for a submission crystal.

wg02• 3 years ago

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?

ye-olde-sysrq3• 3 years ago

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.

sdze• 3 years ago

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

benatkin4• 3 years ago

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

djbusby• 3 years ago

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

recursivedoubts14• 3 years ago

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

canadianfella• 3 years ago

What is a visual snapshot of the DOM?

kerkeslager2• 3 years ago

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?

benatkin4• 3 years ago

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.

earthboundkid• 3 years ago

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.

Jach• 3 years ago

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.

leke2• 3 years ago

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

JoshWVS• 3 years ago

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

jonathan-adly2• 3 years ago

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

powersnail2• 3 years ago

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?

jonathan-adly2• 3 years ago

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

summarity3• 3 years ago

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

jrumbut• 3 years ago

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.

benji-york• 3 years ago

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.

lenkite• 3 years ago

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.

schemescape3• 3 years ago

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”.

recursivedoubts14• 3 years ago

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

squidsoup2• 3 years ago

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.

mdavidn• 3 years ago

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.

squidsoup2• 3 years ago

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.

zhte415• 3 years ago

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.

adamzochowski• 3 years ago

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.

sgt3• 3 years ago

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.

TigerTeamX2• 3 years ago

This. Especially airplane bookings always fail.

recursivedoubts14• 3 years ago

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...

JodieBenitez7• 3 years ago

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.

rlawson2• 3 years ago

This is the best response possible!

pier252• 3 years ago

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

JodieBenitez7• 3 years ago

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

selcuka• 3 years ago

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.

adamckay• 3 years ago

constantly innovating

Don’t mistake activity for achievement.

seumars• 3 years ago

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.

mejutoco2• 3 years ago

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>

smusamashah2• 3 years ago

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.

sli• 3 years ago

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.

recursivedoubts14• 3 years ago

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...

robertoandred6• 3 years ago

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

smusamashah2• 3 years ago

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

synergy20• 3 years ago

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.

olodus• 3 years ago

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.

neurostimulant5• 3 years ago

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.

leke2• 3 years ago

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.

thornewolf• 3 years ago

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.

arcanemachiner2• 3 years ago

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

moritzwarhier4• 3 years ago

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.

JodieBenitez7• 3 years ago

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.

moritzwarhier4• 3 years ago

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!

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, because I think in combination with blade "components" (which are just fancy template partials), I think it's better than HTMX (subjective opinion). Still, I'd advise against Alpine and for a simple external JS file for anything more serious than an MVP or a landing page.

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).

recursivedoubts14• 3 years ago

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.

0xParlay• 3 years ago

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!

JodieBenitez7• 3 years ago

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.

veidelis2• 3 years ago

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

the_gastropod• 3 years ago

What do you mean by traditional?

veidelis2• 3 years ago

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.

sam_goody2• 3 years ago

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.

kaeshiwaza• 3 years ago

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

recursivedoubts14• 3 years ago

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.

Htmx 1.9.0 has been released

Related Stories