If you look at the end-user API documentation[1] it's pretty good. But the htmx.js file itself seems to struggle from a certain type of internal naming scheme

If you look at the end-user API documentation[1] it's pretty good. But the htmx.js file itself seems to struggle from a certain type of internal naming scheme that will take a while to get up to speed with and doesn't really lend itself to being easy to context switch in & out of it, where you might simply forget that things exist and end up re-writing or inlining these fragments. This naturally stems from a very organic development process, where something starts out as a quick prototype, then the functions get too big so you split fragments out into things like `shouldProcessHxOn` and `processHXOnRoot` which absolutely make sense at the time where you're avoiding duplication, and trying to turn it into something 'more proper' with 'better abstractions' would actually cause the code to balloon in size and make it much bigger and much more like object spaghetti. On the whole though, a large amount of the file is type documentation, e.g. `/* @param {Node} start */` which is more a failing of JavaScript itself than anything else, and honestly a 5k self-contained file with good public documentation of what's user-facing vs internal is pretty easy to grok if it's something you work with frequently. If you were to rewrite this in a saner language like Python with a more functional style, you could probably condense it down to 1000 lines or less. [1]: https://htmx.org/api/ https://htmx.org/api/