Htmx 4.0 • Hacker News Board

Re: Htmx 4.0

#241

Post by yawaramin » Mon, Aug 31, 2026, 12:58 AM UTC

Xeoncross wrote: post #216

moebrowne wrote: post #215

Earlier quoted context omitted.

Where are you getting those numbers from? The minified code is about 40kB before compression and about 13kB with gzip. https://bundlephobia.com/package/htmx.org@4.0.0

103KB is the actual source code. You should not be reading or debugging the minimized or gzip/transport bytes.

Yeah but when you're reading the actual source code you're not thinking in terms of bytes, you're looking and files and line counts. Htmx is deliberately maintained as a single, no-dependency file of about 5000loc. The maintainers are of the opinion that it reduces complexity, and I tend to agree.

Re: Htmx 4.0

#242

Post by yawaramin » Mon, Aug 31, 2026, 1:02 AM UTC

WillAdams wrote: post #188

I have been reading: https://www.goodreads.com/book/show/192405005-hypermedia-sys... and still having a hard time wrapping my mind around all of this. The thing which I would really like to see is a stand-alone IDE with a straight-forward "Hello World" as an on-ramp.

That's super simple, it's your favourite backend web framework. Rails, Spring Boot, Laravel, Django, Flask, FastAPI...really whatever you like.

Re: Htmx 4.0

#243

Post by asdfsa32 » Mon, Aug 31, 2026, 3:51 AM UTC

yawaramin wrote: post #240

asdfsa32 wrote: post #231

Earlier quoted context omitted.

Not react yet, but it is approaching the early 2010 jQuery and Backbone vibes, so give it another 5 years and it will converge to React.

The htmx creator has made similar things for a long time, if anything htmx has diverged from those ideas by taking Intercooler.js and stripping out the bundled jQuery to simplify it and create htmx. See https://news.ycombinator.com/item?id=49496634

Have you looked at the project for which htmx4 is released for? it is basically mvc + toolbelt + network library and all that jazz like it is 2012.

Re: Htmx 4.0

#244

Post by asdf88990 » Mon, Aug 31, 2026, 3:54 AM UTC

yawaramin wrote: post #230

asdf88990 wrote: post #227

Earlier quoted context omitted.

No, you misunderstand what is going on. htmx is an exercising in learning web development by someone who didn’t follow 2 decades of web development progress. He is catching up though, now approaching the early 2010s jQuery (moxi) and backbonejs era with fixiproject.org

Htmx is a direct descendant of Intercooler.js, which has been around since circa 2013, more than a decade. Intercooler still exists and is used in production, and you can clearly see that it works almost exactly the same way as htmx does today, it just bundles jQuery together. 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 th…

The creator is stuck in 2012 and so on as I said. If you look at project fixie, the reason htmx 4 exists, it shows how the 80/20 is an incomplete idea for something as general as a web framework. 80/20 might work for your specific use case, but as a general notion, it either gets built on reasonable constructs or grows into a Frankenstein. Htmx approach is a mirror of yaml in my ways. In denial of what it is trying to be and so turns into complete monster.

Re: Htmx 4.0

#245

Post by yawaramin » Mon, Aug 31, 2026, 4:59 AM UTC

deadbabe wrote: post #235

moebrowne wrote: post #217

Earlier quoted context omitted.

Because serialisation and deserialisation have a price and you almost never need what you describe

Who pays it? And I disagree, we definitely use the same API for other contexts.

The client pays it.

- 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.