Htmx users, can you please share your backend stacks and approaches? Me specifically interested in templaters for node (+ts) and your thoughts on endpoint management, but all ideas are welcome I guess.
Django user here. HTMX fits in perfectly with the Django templating system. A fairly common approach is to use the same view but check for the HTMX header and then return a template file with the specific bit of HTML being swapped. There's also work in the Django space to be able to return parts of a template based on the request, which will suit HTMX perfectly too.
Htmx 2.0.0 has been released
121–130 of 146 posts
Re: Htmx 2.0.0 has been released
#122Earlier quoted context omitted.
Would love to hear more about how you’re using it
We are building an enterprise application that manages (create, update data) and interacts with (read, display, enable user to browse via linked entities) a large-scale knowledge graph. In some views we have live updates from the server with SSEs (alerts, logs, etc.). Everything is rendered server side with Go + stdlib templates, Material Design Bootstrap for CSS, and HTMX for all the in interactive bits like fetchin…
Re: Htmx 2.0.0 has been released
#123Re: Htmx 2.0.0 has been released
#124Earlier quoted context omitted.
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.
htmx 1.9.12 was 44kb: 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 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)…
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 `https://unpkg.com/htmx.org@2.0.0" defer>` in `` (https://htmx.org/docs/#installing).
Re: Htmx 2.0.0 has been released
#125Earlier quoted context omitted.
You deleted 500 lines of JS and added 44KB of (minified) HTMX. Better use HTMZ, which is only 166 bytes (sic!) and provides most of the interactivity: https://leanrada.com/htmz/
The problem is not the download size. The problem is the amount of code to maintain.
Re: Htmx 2.0.0 has been released
#126Earlier quoted context omitted.
My backend for a simple web application I'm working on is entirely in Rust. Highlights: - axum: web application framework - https://github.com/tokio-rs/axum - axum-htmx: axum extractors, responders, guards for htmx - https://github.com/robertwayne/axum-htmx - rusqlite: SQLite bindings - https://github.com/rusqlite/rusqlite - maud: HTML templating as a macro - https://maud.lambda.xyz The way maud lets you compose mark…
Do you use something like cargo-watch for "hot reload"?
Re: Htmx 2.0.0 has been released
#127Earlier quoted context omitted.
htmx 1.9.12 was 44kb: 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 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)…
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 ` https://unpkg.com/htmx.org@2.0.0 " defer>` in ` ` ( http…
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
Re: Htmx 2.0.0 has been released
#128Earlier quoted context omitted.
Isn’t that moving code around, not deleting it?
Most likely that code already existed server-side and was duplicated client-side. It's what usually happens since frontend code can't enforce invariants.
Re: Htmx 2.0.0 has been released
#129Earlier quoted context omitted.
The problem is not the download size. The problem is the amount of code to maintain.
It's both. All the JS code has to be parsed and interpreted by web browser, which is affecting especially low end smartphones. Better use plain HTML and CSS whenever possible, see e.g. PHOOOS: https://github.com/niutech/phooos (demo: https://kodus.pl )
htmz looks very cool, though.
Re: Htmx 2.0.0 has been released
#130Earlier quoted context omitted.
HTML already allows a lot of HTMX functionality with just 166 bytes of JS glue code, see HTMZ: https://leanrada.com/htmz You can make tabs, accordions, carousels, modals, popovers and even Pure HTML Out-Of-Order Streaming (PHOOOS) using only HTML & CSS: https://kodus.pl
yep, it's an interesting idea we are planning on implementing a minimalist version of alex's ideas from "The Birth & Death of htmx" talk as a POC for people to look at too.