4 ms·

As for slimming down over time, HTMX 1.0 was 26KB minified, now version 2.0 is 48KB minified. Why has it blown up by 184%, when it dropped IE support? Why don't

As for slimming down over time, HTMX 1.0 was 26KB minified, now version 2.0 is 48KB minified. Why has it blown up by 184%, when it dropped IE support? Why don't keep it lightweight? Compare it with e.g. Petite Vue, which is 16KB minified.

recursivedoubts 2y ago
htmx 1.9.12 was 44kb: https://bundlephobia.com/package/htmx.org@1.9.12 https://bundlephobia.com/package/htmx.org@1.9.12 and 2.0.0 was 45.3: https://bundlephobia.com/package/htmx.org@2.0.0-beta4 https://bundlephobia.com/package/htmx.org@2.0.0-beta4 i think that the better web components support blew is up a little. there is a reasonable amount of fat we can cut around IE support that is still in there, planning on doing so over the next few months & slowly 17ms over emerging 4G (and hopefully cached forever after that) doesn't freak me out too much
- niutech 2y ago
  I was referring to HTMX 1.0.0, which was 26KB: https://bundlephobia.com/package/htmx.org@1.0.0 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 https://ajaxial.unmodernweb.com One more suggestion: use `<script src="https://unpkg.com/htmx.org@2.0.0 https://unpkg.com/htmx.org@2.0.0" defer>` in `<head>` (https://htmx.org/docs/#installing https://htmx.org/docs/#installing).
  - recursivedoubts 2y ago
    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

recursivedoubts 2y ago

htmx 1.9.12 was 44kb: https://bundlephobia.com/package/htmx.org@1.9.12 https://bundlephobia.com/package/htmx.org@1.9.12 and 2.0.0 was 45.3: https://bundlephobia.com/package/htmx.org@2.0.0-beta4 https://bundlephobia.com/package/htmx.org@2.0.0-beta4 i think that the better web components support blew is up a little. there is a reasonable amount of fat we can cut around IE support that is still in there, planning on doing so over the next few months & slowly 17ms over emerging 4G (and hopefully cached forever after that) doesn't freak me out too much

niutech 2y ago
I was referring to HTMX 1.0.0, which was 26KB: https://bundlephobia.com/package/htmx.org@1.0.0 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 https://ajaxial.unmodernweb.com One more suggestion: use `<script src="https://unpkg.com/htmx.org@2.0.0 https://unpkg.com/htmx.org@2.0.0" defer>` in `<head>` (https://htmx.org/docs/#installing https://htmx.org/docs/#installing).
- recursivedoubts 2y ago
  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