idiomorph VS intercooler-js

in plain htmx, you can target an area that doesn't disrupt a playing video (e.g. the comments box appending to the comments) or you can use a morphing algorithm that disrupts the DOM less.

i have my own morphing algorithm (and a corresponding htmx plugin that allows you to use it) called idiomorph:

https://github.com/bigskysoftware/idiomorph/

i've also been working with the chrome team to get a feature added they are calling "atomic moves":

https://github.com/whatwg/dom/issues/1255

this would allow us to move elements around in the DOM without losing things like play state or focus or whatever

very excited for this last idea, I think it will be a huge boon for the web in general, not just for htmx

for htmx 2.0 i'm integrating this functionality into the core

it's based on the head morphing algorithm of idiomorph:

https://github.com/bigskysoftware/idiomorph/

which 37Signals is going to integrate into Turbo for v8:

https://twitter.com/ben_pylo/status/1717975035669876790

[1] - https://htmx.org/essays/locality-of-behaviour/

i certainly hope not

the 2.0 would drop IE support, remove the older SSE and WebSocket support, and switch a couple of defaults (e.g, using template wrapping for parsing partial content, which handles troublesome elements like table rows better, but isn't available in IE) so it would be a breaking change (not for most folks, but still, breaking for some) which I only like to do w/ major versions.

we may have one major addition: a morph swap based on idiomorph:

https://github.com/bigskysoftware/idiomorph/

i'm on the fence on that one: it is currently available as an extension and maybe doesn't belong in the core, still thinking about it

so, in comparison with most libraries, 2.0 is going to be very minor

maybe I'm too close to it, but htmx feels like a hack to address things that really should be part of the HTML spec

if browsers got into the game I would assume they could do things much faster and integrate things like preload (https://htmx.org/extensions/preload/) and idiomorph (https://github.com/bigskysoftware/idiomorph/) much more cleanly w/ the rest of the browser infrastructure

idiomorph:

https://github.com/bigskysoftware/idiomorph

it's an updated take on the DOM morphing algorithm of morphdom, and it uses what i call "ID sets" to allow the morphing algorithm to "see" children in the DOM when making morphing decisions in the parents, which means you don't need to annotate the DOM with as many ids

here is a demo showing how it outperforms morphdom when ids are sparse/deep:

https://github.com/bigskysoftware/idiomorph#demo

my trick for making the `htmx:confirm` event act like it is blocking:

https://github.com/bigskysoftware/htmx/blob/a3c414dcee94fd03...

basically, redesign the arguments for a function such that I can call it again at a given spot with one parameter changed and, to a first order approximation, it acts as if the function is resumable.

I've used this hack in many places now, just recently in idiomorph to allow head elements to load before the rest of the content is morphed:

https://github.com/bigskysoftware/idiomorph/blob/e6dfc189fa3...

That being said, htmx is about 3000 lines of mostly-understandable JavaScript. Really, the only two somewhat ugly parts of the code are history support and the somewhat fancy swapping model that enables CSS transitions. And it's basically baked at this point. I plan on adding a merge-style swap (https://github.com/bigskysoftware/idiomorph), better head merging and cleaning up some rough edges in htmx 2.0, but the core API shouldn't change at all and for most people 2.0 will be the same as a point release. At that point, htmx will be done done, and just another tool to use when building websites.

An early version of Htmx was in fact based on jQuery (https://intercoolerjs.org).

I used HTMX since the intercooler days [0] but the stuff you can make is rather limited. Also you still need the JS to deal with a11y things like expanded state (or hyperscript, apparently).

If you have a lot of components to implement, everything requires thinking.

I really love it for simple applications though. Resist implementing a complicated menu, live notifications, an editable data-table and such non-web-native things and you can create the fastest CRUD app ever.

And you will need another client, but that's not really an issue if your view model does not contain non-public data (it shouldn't), as you can convert it to JSON at the same endpoint and call it an API.

[0]: https://intercoolerjs.org/

to an extent, there was `jQuery.get` but it wasn't tightly integrated with HTML

the original version of htmx was intercooler.js:

https://intercoolerjs.org

released in 2013, and that version depended on jQuery

You asked for it:

https://htmx.org

https://hyperscript.org

I hated angular when it first came out and couldn't believe what insanity people were willing to come up with, so long as it came from google. (e.g. GWT) I created https://intercoolerjs.org out of frustration with that, and the lack of progress in HTML/hypermedia in general, so I could build a web application I was working on (https://leaddyno.com, since sold).

When covid hit I took a look back at intercooler and decided that it was really two things: HTML++ and a scripting language, so I split it up into htmx, focused just on the hypermedia angle, and hyperscript, the scripting language I wanted for the web (derived from HyperTalk, and old scripting language from HyperCard on the mac).

I know use them both professionally (email me if you want to use them too.)

I created intercooler.js in 2013 so I could do AJAX in HTML:

https://intercoolerjs.org

Last year I removed the jquery dependency and cleaned it up based on a lot of lessons that I learned, renaming it to hmtx:

https://htmx.org

Same idea: extends/complete HTML as a hypertext so you can build more advanced UI within the original hypermedia web model, and cleaner implementation.

Part of that cleanup involved me pulling out some functionality around events and a proto-scripting language (ic-action), and I enjoy programming languages, so I created a front end scripting language to fill that need:

https://hyperscript.org

It's based on HyperTalk and has a lot of domain specific features for lightweight front end scripting, kind of a jQuery or AlpineJS alternative.

This is my experience, and your mileage may vary:

Multiple times in my coding career I have felt stalled and/or like I was regressing.

Early on, I worked on a programming language, gosu (https://gosu-lang.github.io/) which ended up not really going anywhere. Once the work on it was done, I returned to more mundane web programming for a while. A long while after that, and unexpectedly, I turned a jQuery function I was noodling on into intercooler.js (https://intercoolerjs.org/). After a year of that I returned to mundane web programming for quite a while. Unexpectedly, a year ago, the country shut down. I was at home and decided to see if I could remove the jQuery dependency in intercooler.js, and so created htmx (https://htmx.org/). When creating htmx and removing some attribute/functionality, I realized that a small programming language would be the ideal replacement, so I created hyperscript: https://hyperscript.org/. I had not expected to work on a programming language again, but now I am.

So my career has been some very exciting technical projects punctuating long stretches of pretty basic web development, where the most exciting thing is me wondering if I can figure out what the deuce is wrong with my CSS. My takeaway here, at least in my career, is that patience is a virtue, and the interesting stuff tends to come up at irregular intervals and in unexpected moments and ways.

htmx is the successor to intercooler.js. It swaps parts of the page, not the whole page like Turbolinks. htmx allows you to access AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes, so you can build modern user interfaces with the simplicity and power of hypertext