idiomorph VS scheme-for-max

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.

Mine is Scheme for Max, now on it's fourth open source release, but really written so I could make computer music how I want to. It's an extension to the popular Max/MSP visual music programming environment that embeds an s7 Scheme interpreter and provides a substantial API/FFI to Max. It allows you to script Max (and thus also Ableton Live) with Scheme, enabling interactive coding, algorithmic music, live coding, macros, and just much more pleasant scripting than in JavaScript. It locks in with the scheduler so you can even use Scheme powered sequencers within Ableton Live alongside regular Live tracks, and you can build sophisticated Live control surfaces using the Live API.

Github page here: https://github.com/iainctduncan/scheme-for-max

The project page is here, with links to lots of documentation I've done: https://github.com/iainctduncan/scheme-for-max

To download Scheme for Max and for tutorials, documentation, and the cookbook, visit the GitHub page: https://github.com/iainctduncan/scheme-for-max

If you like things like Janet, you might also like s7 Scheme. It is also a minimal Scheme built entirely in C and dead easy to embed. I used it to make Scheme for Max and Scheme for Pd, extensions to the Max and Pd computer music platform to allow scripting them in Scheme. (https://github.com/iainctduncan/scheme-for-max) Janet was one of the options I looked pretty closely at before choosing s7.

The author (Bill Schottstaedt, Stanford CCRMA) is not too interested in making pretty web pages, ha, but the language is great!

Project page: https://github.com/iainctduncan/scheme-for-max

I created Scheme for Max and Scheme for Pure Data. They are extensions to the Max/MSP, Ableton Live, and Pure Data computer music environments that embed an s7 Scheme interpreter in the host so that you can script, automate, and live code the hosts with s7, a Scheme from the CCRMA computer music center at Stanford and the same one used in the Snd editor and the Common Music 3 algorithmic composition environment. This allows you to do things like write algorithmic music tools, sequencers, and use the Ableton Live API in Scheme, including with Common Lisp style macros. It has an API for integrating with Max to share data structures, hook into the scheduler, run in the high priority thread, and so on. S4M allows you to do all the goodness of high level music programming in a Lisp, without losing the ability to use modern commercial tooling and instruments. It's my thesis project for a Masters in Music Technology with Andy Schloss and George Tzanetakis at the University of Victoria, and I plan to continue to a PhD working on it. I tried submitting twice, but it never made the page, which surprised me a bit given Lisp interest here.

The github page is here: https://github.com/iainctduncan/scheme-for-max

The youtube channel with various demos is here: https://www.youtube.com/c/musicwithlisp