Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I was referring to HTMX 1.0.0, which was 26KB: https://bundlephobia.com/package/htmx.org@1.0.0

It's not only about bandwidth, but JS code has to be parsed and executed, which takes CPU time, which is especially affecting low end mobile devices. Compare HTMX with e.g. Ajaxial, which is only 5KB minified: https://ajaxial.unmodernweb.com

One more suggestion: use `<script src="https://unpkg.com/htmx.org@2.0.0" defer>` in `<head>` (https://htmx.org/docs/#installing).



ah, yeah, i don't know what to tell you, i've gone through the code base a bunch and there isn't much i feel like i can take out that would make much of a difference without a major step back in functionality: history support is a big one, input gathering has gotten more complex as i behave the way forms in HTML actually work, i have a lot of events that i fire, there's the queuing behavior of requests, etc.

my understanding from the browser engineers is that javascript files are compiled and kept in a cache for the browser, and i never see compilation or execution times in htmx profiles unless someone is processing a ton of htmx attributes (1000+ row tables w/ loads of hx-* attributes per row) which is an orthogonal problem

end of the day i don't think grinding out another few K on the minified source is gonna make a big diff, although we do plan on doing things like moving to modern closures (i assume gzip nukes most of that advantage, idk)

i think a minimal preact-like htmx might be interesting, not as minimal as htmz, but something close. might be worth looking at if you are interested, the concept isn't hard and w/ different design decisions you could prob keep it really small




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: