It does not aim to remove js from your code, it simply adds more features to HTML by default, like making any element able to trigger an web request.
When you write a real world app with HTMX, you inevitably end up writing some js, which is totally fine.
https://m.youtube.com/watch?v=9ZhmnfKD5PE
It is not anti-SPA, but pro-hypermedia for the right problems:
https://htmx.org/essays/when-to-use-hypermedia/
htmx is a front end library of peace
”After all, both htmx and hyperscript are built in JavaScript. We couldn’t have created these libraries without JavaScript, which, whatever else one might say, has the great virtue of being there.
And we even go so far as to recommend using JavaScript for front-end scripting needs in a hypermedia-driven application, so long as you script in a hypermedia-friendly way.
Further, we wouldn’t steer someone away from using JavaScript (or TypeScript) on the server side for a hypermedia-driven application, if that language is the best option for your team. As we said earlier, JavaScript now has multiple excellent server-side runtimes and many excellent server-side libraries available.”
Java is written in C++, but it is clearly "anti-C++" for any reasonable interpretation of the term. (Java historically replaced C++ as the most popular language, as far as I remember.)
More importantly, HTMX could have had native support without requiring an implementation in JavaScript.
HTMX is great. We use it as a middle ground for mildly interactive parts of the app. Places where jquery/vanilla would get annoying but going full React isn’t worth it. Admin interfaces in particular are a great fit – lots of CRUD, mildly interactive, very repetitive.
Adding `hx-get` to a button or div is way way quicker than writing all that boilerplate javascript yet again for the hundredth time.
Extra bonus: it encourages you to write small self-contained composable endpoints instead of massive kitchen-sink pages.
Why would I write React components myself when I the Javascript isn't really that complicated?
It is bizarre that ONLY HTMX gets these weird "DONT USE THAT ITS NOT POPULAR ENOUGH" criticisms.
XML, XLST get these criticisms except for the XQuery and XPath components because HTML fanatics need that to make their hybrid HTML/JS garbage apps work.
But really the ultimate goal for any good website engineer should be to offload as much logic and processing to the browser, not rewrite everything in JS just because you can.
Such a weird question. You could ask that about any library ever.
fixi.js is a more minimalist take on the same idea: https://github.com/bigskysoftware/fixi
agree that htmx users are weird
But man, 10MB Go WASM download? That's a no go. It's not only about downloading it but executing on a clients machine over and over again. But I guess you can handle those requests perfectly fine just in service worker using pure JavaScript.
So you'll never get Go Wasm binary sizes down to something reasonable, alas.
(Some languages in particular are remarkably inflexible regarding how they want you to use them in this context.)
So seeing no real benefit. I ended up switching back to TS. I became depressed shortly afterwards, but that's probably unrelated ;)
Still, wasm game dev was a delightful experience in many respects and I would recommend it to anyone who's interested. ("Elimination of headache" is not necessarily an unambiguous good. Some headaches are genuinely worth it! Just depends on your taste and your goals.)
[0] My "favorite" bug was spending the last day of a game jam stuck on a bizarre compiler bug that would only manifest in the wasm version of the game... but I got it figured out in the end!
https://hacks.mozilla.org/2018/01/making-webassembly-even-fa...
I know it's "whataboutism" but I thought it was pretty funny.
[0] https://logankeenan.com/posts/a-rust-server-app-compiled-to-...
[1] https://logankeenan.com/posts/client-side-server-with-rust-a...
[2] https://github.com/richardanaya/wasm-service
Instead of a WASM backend, I used react-dom/server to generate the HTML.
https://github.com/michaelcpuckett/listleap?tab=readme-ov-fi...
The geneal idea of HTMX is that your HTML will be rendered by the backend — à la Server Side Rendering.
It's another use of "render" relative to the server such as converting non-HTML data inside database tables, json, etc --> rendered into HTML:
https://www.google.com/search?q=SSR+server+side+rendering
Many different perspectives of "rendering":
- SSR server-side rendering : server converting data to HTML
- CSR client-side rendering : e.g. client browser fetching and converting JSON/XML into dynamic HTML
- browser-engine rendering : converting HTML to operating system windowing GUI (i.e. "painting")
See also Server Side Rendering (SSR) which uses the term rendering in the same way.
One of the many dictionary definitions of the word also appears to be to "give an interpretation or rendition of" something.
You could "render" it to html with pandoc, then serve the html from disk by a static web server.
This would be "build time" html - it's html before it's read by the server.
Then you could setup a cgi script, php-script or an application server that converted markdown to html - then sent it to the client. This would be server-side rendering.
Finally, you could send some html+javascript to the client that fetch the raw markdown, then generates html on the client. That would be client side rendering.
In case anyone thinks this idea is serious, my strong like of vanilla HTMX came from the realizations that (i) state management can revert to the ur-web model and avoid all the complexity of browser / server state synch and (ii) I can use anything I damn well like on the server (I wrote https://harcstack.org to optimize for expediency).
So you should be able to achieve pretty much anything at that point. A nice side-effect of moving to fetch.
Latency is not a real issue with SSR apps, there are a bunch of solutions to place servers and data closer to your users (within a few tens of ms). Plus you can prefetch and cache content very easily without using service workers. That’s not the reason Jira or GitHub feel slow; in fact GitHub was quite fast a few years ago when all it did was render pages from the server.
The author explicitly states that he likes to write Go and that’s why he picked it in this example, which in my opinion makes this article more interesting. The main benefit is that the 'local server' within the service worker mimics the 'real server,' which effectively means you only have to write the code once.
But I generally agree that a 10MB download on first load is not something that I’d be happy to serve to users, especially to those who are using their mobile network.