Sounds like OCaml has the answer then. It has the equivalent of all the great things you described in Rust, plus compile speeds similar to or better than Go. Agents should be able to blaze through changes with it.
4,189 karma · joined November 3, 2012
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.
There are many ways to skin the cat.
This is almost always because of using a string-based templating system. If you use a language-embedded HTML generation library, it represents HTML fragments as first-class values in your language, and you can compose them together in flexible ways. This makes out-of-band swaps very simple.
They quite literally have a a large essay on their site dedicated to discussing when to and when not to use it: https://htmx.org/essays/when-to-use-hypermedia/
Also, it’s not at all sold as a ‘competitor to React’, it’s sold as a simpler option for many apps where React is overkill. If you want to make a game with React, no one will argue for using htmx instead. The game will probably have a lot of perf issues though.