idiomorph VS fast

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.

Similarly to Promises/A+, this effort focuses on aligning the JavaScript ecosystem. If this alignment is successful, then a standard could emerge, based on that experience. Several framework authors are collaborating here on a common model which could back their reactivity core. The current draft is based on design input from the authors/maintainers of Angular, Bubble, Ember, FAST, MobX, Preact, Qwik, RxJS, Solid, Starbeam, Svelte, Vue, Wiz, and more…

If you are generally interested in how to write components that can be used by many frontend libraries (react/vue, etc), you should take a look at https://github.com/microsoft/fast. I was tangentially involved with porting an existing component library to it and the end result was pretty framework agnostic and well made.

Could not have articulated it better, especially when compared to other MS project sites like https://www.fast.design/. Maybe the dev or someone on the team downvoted me :/

I know FAST is not used that much but I wanted to cover it as it seems to be the only library that reflects attributes by default. By default it won't do any type coercion unless you use the mode: "boolean", which works almost like an HTML boolean attribute, except an attribute present but with the value "false" will coerce to a property value of false!

This doesn't mean you are required to write vanilla JavaScript web components either. If you are familiar with using Fast or Lit to write web components you can include those libraries in you Enhance application. However, with the introduction of Enhance base classes for the light and shadow DOM you can get the same DX improvements where you write less boilerplate web component code while enabling the sharing of a render method between the SSR and CSR rendering.

You could take a look at FAST https://www.fast.design/. I know it is not what you asked but ...

FastUI from Microsoft? https://github.com/microsoft/fast

I want to use Fast Components, so I've added the Microsoft.Fast.Components.FluentUI NuGet package and added the relevant CDN script tag to index.html.

fast- (Fast components from Microsoft8)