Hacker News Reader

We're replacing React with Htmx at work (about a year into it) and have found WebComponents to be very useful to re-use some of the React components that we want to preserve and treat a bit like using native browser widgets (input, select, textarea). Specifically, a WebComponent lets you hook into the lifecycle of a DOM element that is being modified by the outside world (morphdom via Htmx). In the event of attributes changing, you want to tell the React component about that. And in the event of the node being removed from the DOM, you want to tell React to run its cleanup procedures. I think that we weren't able to do this in a clean, efficient way without WebComponents.

The end result is that we can stick to Htmx's way of doing things, i.e. keeping all business logic state on the server, and only a few conservative things are client-side (such as currently focused element, text being typed in an input, things like that). Every step we take towards this, it offers a much better user experience with fewer bugs and race conditions, so it's worth the effort.

that's great to hear and confirms my intuition that web components and htmx would go very well together

what about alpine.js, seems great to me and more natural(not mixing html and js behind the scene like some black magic)

both are really for SSR applications, a modern jQuery to some extent. For CSR(client side rendering), you still have to use react/vue/mithril/etc

Author here — I’ll remove that sentence since it looks like it’s being received in a way I didn’t intend. Sorry about that! I actually mentioned on Twitter [1] that web components are a natural fit for hypermedia-friendly scripting as described in your essay [2] (which I like a lot).

[1] https://x.com/jlazaroff/status/1717176726248108469

[2] https://htmx.org/essays/hypermedia-friendly-scripting/

Well, I think that the article (and sentence) is correctly pointing out an issue w/many JS frameworks, I just don't think it applies to htmx necessarily. I don't mind you keeping it up and having a debate around the topic: in as much as htmx does cause upgrade pain that's a burden of using it that deserves to be called out.

I don't think you need to change the article, I just want to give my perspective as the author of htmx. It isn't realistic to expect everyone to write perfectly precise articles at all times, especially when the htmx reference in the article isn't a focus (likely included just because you kinda like htmx :)

I kind of hoped the long term result of htmx, instead of just being a Javascript library, was to become a standard in a newer version of HTML itself. The constraints of only forms being able to do POSTs, and the only way to handle the response is to rewrite the entire page seems arbitrarily limiting. If htmx were just HTML6 or whatever, it'd outlive all the Javascript frameworks.

I think this is still possible.

It took a decade for JQuery to be nearly completely absorbed by browser standards.

For the most part, jQuery was absorbed into ES/JavaScript, not HTML.

The most visible part of jQuery for me was always querying selectors - $('.some > a.selector'); and that certainly was something integrated into HTML/the DOM as document.querySelectorAll('.some > a.selector').

Well yeah, that's still under "browser standards."

The difference is that the internet can exist (and did) quite well without JavaScript. Without HTML there is no internet. Furthermore, ECMAScript is a language and W3C/WHATWG are a consortium that maintain HTML.

Sorry to nitpick, but there is a lot more to the internet than the web.

And the browser APIs still have significantly worse ergonomics than jQuery

You'd have to merge JavaScript and HTML to get htmx in any usage capacity. HTML is not a programming language, it's a markup language.

I have thrown together a minimalist extension to HTML that I think captures the core ideas of htmx, although you are right that there are still some outstanding issues that probably need additional thinking to make it widely useful:

https://gist.github.com/1cg/d1ad1ddd5f43a8a993cd9f711135edc9

Here is an example button using these proposed extensions to HTML

  <button href="/example"
        method="patch"
        target="#divToReplace"
        onClick="this.submit()">
    This is an example button hypermedia control
  </button>

I'd vote for being able to put an href attribute on any element (eg <div href=""> and <span href="">), and maybe binning <a> entirely. That seems like such an obvious enhancement to me, I figure there's probably a deep reason it hasn't been done.

Not sure of why it was done then, but currently for accessibility a link says, "This takes you to another page / URL" while a button says, "This performs some action / triggers some event."

If everything and anything is clickable, how does technology that supports accessibility handle that? Note: This isn't a way-a-figure-you-fool question. Not at all. It's a sincere question in the sense that accessibility matters, we can't forget that. So if we change, how can we be certain accessibility isn't left behind?

Yeah, I wondered if it was accessibility, or maybe a limitation to support text browsers.

To take the opposite view, there's not much we can't wrap in an <a> since HTML5 (eg <a href=""><div></div></a> is valid, and makes the div clickable). How do accessible browsers support that today?

So you want to inline JavaScript, similar to CSS and the `style` attribute?

I would prefer something more like what htmx has in hx-trigger:

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

w/ an explicit and declarative syntax, but that attribute is fairly involved

this was a brief exercise in thinking about the minimal changes necessary to HTML to support something like htmx, and unfortunately there isn't any attribute that maps to hx-trigger in the same way there is for other htmx attributes, so I resorted to the on* attributes + generalizing the submit() function on forms.

Yes and no. You wouldn't call a <form> inlining JS while it does come with some degree of interaction. It would be an expansion of HTML to include a few new things to (ideally) enable a wider rage of lightly-interactive websites to be HTML only.

according to the people who write standards, but not the people who write browsers

I literally just started with htmx, but can’t you override both of those behaviors? hx-<http verb> on the form will switch the verb it uses, and you can swap outerhtml, innerhtml, or some other css target?

Or am I incorrect?

I think you've slightly misread - they specified only forms can do POSTs, not that forms can do only POSTs. (Also, they're talking about vanilla HTML, not HTMX).

Oh I did not catch that … oops

> The constraints of only forms being able to do POSTs

HTML elements shouldn't do POSTs, that's why JavaScript exists. <form> and <a> are elements that do HTTP requests but the same can be added to any other html or custom element. html integration with JS doesn't need another layer.

> But, insofar as I can help it, htmx should be very stable and churn free going forward. The API is basically correct (yes, w/ a few warts and mistakes) and I see no need to rewrite everything for the sake of purity or sexiness.

This is awesome to hear. I've been eyeing htmx a bit lately for some pet projects, but as a primarily backend-focused engineer, most JS libraries I import tend to be a large maintenance burden moving forward, with major API changes happening regularly.

I'll definitely take htmx out for a spin.

I have been using HTMX a lot and would highly recommend it as a backend engineer.

Historically I have constantly had an issue following JS frameworks and more importantly their build processes. Too much mental overhead when the majority of things I am building don't really benefit from a SPA style. I started my journey using Backbone.js a decade ago and enjoyed the relatively simple apis. Everything that came after for me has been a nightmare. Finally with HTMX I am in the groove and able to easily build what I want in a pattern that I enjoy.

I've been wanting to rewrite a side project SPA using htmx. I've never been that interested in Web Components, but it is an intriguing idea to use with htmx. It'd certainly make generating the HTML fragments server-side less complex to template.

On a side note about htmx. Really compelling concept, I wish there was a larger community around it. Chicken and the egg kind of a problem, but there just aren't a lot of resources (blog posts, videos, etc) compared to many other web frameworks. Basic stuff like how do integrate something like Auth0 auth into an htmx app.

There is no "htmx app". You'd search for how to include auth0 in, say, a django app.

It seems like examples are usually oriented around specific popular SPA frameworks (e.g. React) or focused on an existing server side rendered app that you are adding interactivity into. I understand extending server-side way. The kind of stuff I used to do with jQuery back in the day adding interactivity into otherwise SSR pages.

In a world of either SPAs or SSRs, htmx straddles the two. That is what makes it so interesting and unique, but it is also a different enough model to not always cleanly map from my pre-existing skills/patterns.

For the app I'm doing, I'd really prefer to keep it an SPA. In that the URL never changes, and there is never a full page reload (outside of OIDC/sign-in). I'm sure I can get there, I just need to think about the architecture a bit.

I'm kind of obsessive in this app about loading the app being nearly instant (I personally use it countless times a day). I really love the idea of returning back a full rendered page of HTML that wouldn't require any other API calls before showing the content.

The current stack (which I hate, but it works, I wrote it, and so who am I going to blame?) - is PHP/MySQL. My concept for something that will be lower maintenance going forward (keeping up on PHP versions...ugh.) is to use Deno + oak + SQLite (running in Deno using WASM) on the server to render HTML fragments/pages, and htmx on the front end. With no build step and no database server to maintain.

The community is relatively large but I understand what you are saying.

I think really all you need to do is start using it. The HTMX api is minimal but powerful. At the end of the day you are requesting chunks of html that replace existing sections in your html.

You are building an HTML driven app so your auth workflow is going to be whatever HTML can handle.

If your SPA is written in Typescript, you're going to throw away a lot of safety checks moving to htmx.

A move from SPA means business logic moves to the backend and becomes hypermedia-driven, so the correct comparison if you want to think about type safety is if the backend server is type-safe. htmx is mostly declarative and its correct use could be statically checked with basic tools--it's not meant to contain complex logic.

Isn't IE dropped in the upcoming htmx 2.0 release? Not that it's a bad thing, but goes against the superior backwards compatibility claim.

"In htmx 2.0, our only breaking change is likely to be dropping IE support." from a comment by the engineer who writes and maintains htmx.