idiomorph VS codebase-visualizer-action

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.

Nice post - treemaps are great!

My friend and I made a codebase visualisation tool (https://www.codeatlas.dev/gallery) that's based on Voronoi treemaps, maybe of interest as an illustration of the aesthetics with a non-rectangular layout!

We've opted for zooming through double-clicks as the main method of navigating the map, because in deep codebases, the individual cells quickly get too small to accurately target with the cursor as shown in the key-path label approach!

If anyone's interested, this is also available as a Github Action to generate the treemap during CI: https://github.com/codeatlasHQ/codebase-visualizer-action

If you find this type of codebase visualisation useful, you might want to checkout codeatlas.dev and its Github Action (https://github.com/codeatlasHQ/codebase-visualizer-action). It doesn't animate the repo over time like gource (yet), but instead aims to give a beautiful interactive visual snapshot of a repo at a particular point in time. It also lets you zoom in on specific aspects like recent commit activity, programming language and hopefully in the future test coverage.

E.g. see here for a visualisation of the pytorch codebase we did a while ago: https://codeatlas.dev/gallery/pytorch/pytorch

(disclaimer: I'm the author)

If you think this is useful, you might also like codeatlas.dev and its Github Action (https://github.com/codeatlasHQ/codebase-visualizer-action). It currently does not support per-contributor activity, but we put a lot of effort into making the diagrams beautiful to look at and the basic approach of using treemaps for visualisation seems very similar. In fact, could be cool to collaborate on this, DM me if interested!

https://codeatlas.dev

https://codeatlas.dev - codebase visualisation tool

Takes your git repo and generates a beautiful visual representation of the code. Sort of an alternative navigation tool (in addition to IDEs) for large codebases. Can also run it as part of CI with our Github Action (https://github.com/codeatlasHQ/codebase-visualizer-action).

We made this because grokking complex software projects is really difficult and we've found that a visual overview of what's in a codebase can be quite helpful to get started.

E.g. checkout https://codeatlas.dev/gallery/kubernetes/kubernetes for the generated visualisation of the Kubernetes Github repo!

Currently making -10$/year to pay for the domain :D We slowed down active development after our initial attempts at dissemination didn't really go anywhere (bragging about side projects on the internet, ugh), but I'm still really keen on getting some feedback on whether this is actually useful to anyone else!

Note: The site works somewhat on mobile, but is much better on desktop!

Also, funny there's a post like this again, just like https://news.ycombinator.com/item?id=34531989 yesterday.

https://codeatlas.dev - codebase visualisation tool

It takes your git repo and generates a beautiful visual representation of the actual code that's in it. Sort of an alternative navigation tool (in addition to IDEs) for large codebases. You can run codeatlas as part of your CI with our Github Action (https://github.com/codeatlasHQ/codebase-visualizer-action).

We made this because grokking complex software projects is really difficult and we've found that a visual overview of what's in a codebase can be quite helpful to get started.

E.g. checkout https://codeatlas.dev/gallery/kubernetes/kubernetes for the generated visualisation of the Kubernetes Github repo!

We slowed down active development after our initial attempts at dissemination didn't really go anywhere (bragging about side projects on the internet, ugh), but would still love feedback on whether this is possibly useful to anyone else!

Note: The site works somewhat on mobile, but is much better on desktop!

I've already mentioned this on the other thread (https://news.ycombinator.com/item?id=31569646), but my friend and I have been working on [https://www.codeatlas.dev](https://www.codeatlas.dev/) as a sideproject - it's a tool for creating pretty (2D!) visualisations of codebases, while providing additional insights via overlays (e.g. commit density, programming language or other results from static analysis like dead code/test coverage/etc.). For example here's the Kubernetes codebase visualised using codeatlas: [https://www.codeatlas.dev/repo/kubernetes/kubernetes](https:....

At the moment, codeatlas is just the static gallery, but we're only a few weekends away from releasing a Github action that deploys this diagram on github pages for your own repos - if you're interested, feel free to watch this repo: https://github.com/codeatlasHQ/codebase-visualizer-action

OP, how close is this to what you had in mind in your question?

My friend and I have been working on https://www.codeatlas.dev in our spare time, which is a tool that creates pretty (2D!) visualisations of codebases, while providing additional insights via overlays (e.g. commit density, programming language). For example here's the Kubernetes codebase visualised using codeatlas: https://www.codeatlas.dev/repo/kubernetes/kubernetes.

At the moment, codeatlas is only a static gallery, but we're currently about 1-2 weekends away from releasing a Github action that deploys this diagram on github pages for your own repos - if you're interested, feel free to watch this repo: https://github.com/codeatlasHQ/codebase-visualizer-action