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.
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).
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.
Instead of a WASM backend, I used react-dom/server to generate the HTML.
https://github.com/michaelcpuckett/listleap?tab=readme-ov-fi...
oldestofsports•5h ago
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.
sublinear•5h ago
Swizec•5h ago
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.
Culonavirus•2h ago
Yes. Then imagine you have a massive legacy codebase and a control panel of something has a ton of data and buttons and inputs and all kinds of nonsense. Say you have a weight and dimensions of a package of a product... you'd like to make it so you can edit these in-place and when you do, a package volume (and/or volume sum of all packages) gets updated somewhere else on the page (along with some other info... I don't know, an estimate of product delivery cost based on volume, which delivery methods are now un/available etc.)
Like... you already have ways to calculate and show these in your server side logic. With HTMX you reuse these, add a sprinkle of hx-get and add some OOB updates and you're done. You can do the same with ajax, but not nearly as fast as with HTMX and much more annoyingly...
righthand•5h ago
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.
orhmeh09•5h ago
Why? This makes for a horrible user experience. Things like TicketMaster, and in recent years GitHub, slow my machine to a crawl sometimes. I much prefer mostly static content. This is a well-made website: https://www.compuserve.com/
johannes1234321•4h ago
The issue is of "plain" websites for bad reasons add dynamic stuff.
on_the_train•4h ago
HiPhish•4h ago
Such a weird question. You could ask that about any library ever.
Animats•3h ago
kryptn•3h ago
xg15•3h ago
zelphirkalt•3h ago
brabel•2h ago
oldestofsports•1h ago
”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.”
https://htmx.org/essays/hypermedia-on-whatever-youd-like/
recursivedoubts•27m ago
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
kryptn•2h ago
cubefox•1h ago
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.
recursivedoubts•5m ago
https://alexanderpetros.com/triptych/