Fun fact: Jonas, the creator of tig, is an ex-colleague of mine. It’s cool working with people while using dev tools they wrote!

2. OCaml has an idiomatic approach of using interface files for all modules that can be accessed outside their libraries, and interface files give LLMs a great précis of exactly what is wanted. They then just have to follow the types and fill in the blanks to get the implementation. It's nearly the perfect use case.

I didn’t realize that was allowed.

What do HN mods think of that, dang?

- If the server is responding with JSON, the client has to parse, decode, and validate the JSON. Then it has to transform it into HTML DOM nodes. Finally, it can inject them into the DOM.

- If the server is responding with a bespoke non-JSON data structure, it's the same situation as above except even more work because a third-party, non-standard library has to decode this structure into something (most likely JSON) and then transform the JSON into HTML nodes, etc. etc.

- If the server is responding with straight-up HTML, the client uses the browser's HTML parser to directly transform it into HTML nodes and inject it into the page. And by the way, the browser engine is essentially a function that is highly optimized for exactly this use case–parsing bytes into DOM nodes.

'We' might use the same API but it's widely accepted that generally the same API doesn't work for all contexts. See https://samnewman.io/patterns/architectural/bff/#general which details the many well-known problems with having a single API for different contexts.

The creator has been working on these ideas for a long time, but the core idea–swapping HTML from the server into the DOM–has been constant throughout.

It's exactly because he followed the past two decades of web dev that htmx avoids almost everything about it. Fixi and htmx extensions follow the 80/20 principle and can work by just being dropped in with a script tag. You don't need an elaborate npm setup, same as everything else in the htmx ecosystem.

The upgrade is completely voluntary: it won’t even be set as the default version in npm till next year, and there are no known security issues that would force anyone to upgrade. People happy with v2 can just stay on it for the foreseeable future.