10 ms·

just because htmx (which is a library, not a framework) was mentioned, I'm going to respond to some stuff in the article first and foremost, the article doesn'

just because htmx (which is a library, not a framework) was mentioned, I'm going to respond to some stuff in the article first and foremost, the article doesn't talk about synchronizing state w/a server, which is what htmx is focuses on (via hypermedia exchanges), so htmx is orthogonal to WebComponents in this regard > There’s a cost to using dependencies. New versions are released, APIs change, and it takes time and effort to make sure your own code remains compatible with them. This is why htmx is dependency-free and focuses intensely on backwards compatibility (e.g. it is IE11 compatible). intercooler.js, which was htmx 1.0 and has one dependency, jQuery, was released in 2013 and is still supported. A lot of other javascript libraries have a culture of API rewrites and difficult upgrades, but htmx is explicitly not like that and shouldn't be heaped into that general culture. In htmx 2.0, our only breaking change is likely to be dropping IE support. Will web components outlive htmx? Well, they are part of the browser, so presumably yes. 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. And, most importantly, htmx answers a different question than Web Components: how should I synchronize state w/ the server.

jakelazaroff 3y ago
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 https://x.com/jlazaroff/status/1717176726248108469 [2] https://htmx.org/essays/hypermedia-friendly-scripting/ https://htmx.org/essays/hypermedia-friendly-scripting/
- recursivedoubts 3y ago
  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 :)
radlad 3y ago
> 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.
- infecto 3y ago
  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.
al_potato 3y ago
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.
- recursivedoubts 3y ago
  that's great to hear and confirms my intuition that web components and htmx would go very well together
- synergy20 3y ago
  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
pseudosavant 3y ago
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.
- traverseda 3y ago
  There is no "htmx app". You'd search for how to include auth0 in, say, a django app.
  - pseudosavant 3y ago
    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.
- infecto 3y ago
rprenger 3y ago
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.
- candiddevmike 3y ago
  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.
  - mjburgess 3y ago
    according to the people who write standards, but not the people who write browsers
  - recursivedoubts 3y ago
    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 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>
    - candiddevmike 3y ago
      So you want to inline JavaScript, similar to CSS and the `style` attribute?
      - recursivedoubts 3y ago
        I would prefer something more like what htmx has in hx-trigger: https://htmx.org/attributes/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.
flagged24 3y ago
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.
- chiefalchemist 3y ago
  "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.

jakelazaroff 3y ago

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 https://x.com/jlazaroff/status/1717176726248108469 [2] https://htmx.org/essays/hypermedia-friendly-scripting/ https://htmx.org/essays/hypermedia-friendly-scripting/

recursivedoubts 3y ago
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 :)

radlad 3y ago

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

infecto 3y ago
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.

al_potato 3y ago

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.

recursivedoubts 3y ago
that's great to hear and confirms my intuition that web components and htmx would go very well together
synergy20 3y ago
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

pseudosavant 3y ago

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.

traverseda 3y ago
There is no "htmx app". You'd search for how to include auth0 in, say, a django app.
- pseudosavant 3y ago
  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.
infecto 3y ago

rprenger 3y ago

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.

candiddevmike 3y ago
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.
- mjburgess 3y ago
  according to the people who write standards, but not the people who write browsers
- recursivedoubts 3y ago
  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 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>
  - candiddevmike 3y ago
    So you want to inline JavaScript, similar to CSS and the `style` attribute?
    - recursivedoubts 3y ago
      I would prefer something more like what htmx has in hx-trigger: https://htmx.org/attributes/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.

flagged24 3y ago

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.

chiefalchemist 3y ago
"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.