2 Examples:
1. "Convert any hx-on attributes to their hx-on: equivalent: [..] hx-on="htmx:beforeRequest: alert('Making a request!') [..] becomes: [..] hx-on:htmx:before-request="alert('Making a request!')" Note that you must use the kebab-case of the event name due to the fact that attributes are case-insensitive in HTML.
2. The htmx.makeFragment() method now always returns a DocumentFragment rather than either an Element or DocumentFragment
> So your brain must've just ignored the code diffs above when responding, because it likes htmlx so much.
It's less about whether someone likes HTMX or not and more has to do with none of those points in the upgrade guide being relevant to, or impacting, the author or most other people.
The reason some of us like the way it updated so much is that except possibly for authors of swap plugins the new behaviours have been telegraphed long in advance so a lot of places already did all the changes and V2 just removed some stuff that was already deprecated.
Funnily enough, this confusion shows how bad our expectations became, in some ways...
Let's go through migration guide:
- NO CHANGE NEEDED JS modules changes: new feature in form of all three major module formats being provided out of the box
- MINOR Extensions are now packaged separately, and one extension explicitly has to be upgraded. Minor amount of work (been there, done that)
- MINOR Again migration of SSE and WebSocket extensions, something already pushed as default and preferred way in later v1 versions. If you followed best practices from docs in last year, you have nothing to upgrade.
- MEDIUM hx-on="htmx:..." -> hx-on:htmx:... - again, old recommended becomes new mandatory. If you followed best practices you have nothing to upgrade, otherwise change is minor unless you have lots of custom events involved where you also did not follow recommended naming.
- MINOR - default settings of configuration options changed. Minor change of adding few configuration lines.
- MAJOR ... but only for users of internals, not public API - htmx.makeFragment() changed to simpler and more performant code underneath (and less buggy) - and it was because HTMX dropped IE that it could finally do so, because IE's documentFragment handling was simply plainly bad. It's also internal, not public API, so unless you went deep or wrote your own extensions you're not going to see it at all
- MAJOR - for extension authors that used a certain specific private internal API, that API got replaced with a new public one.
- Internet Explorer support getting dropped. Some of us still have to deal with it, for them the team behind htmx apparently promises to maintain v1 for a while longer. Also trigger for the makeFragment thing.
All in, if you have followed v1 documentation on recommended patterns in the last year or two, you're barely going to notice anything except maybe the configuration changes, and well, better be explicit about those.