[oldestofsports]

HTMX is neither a meme nor is it anti-javascript, it is literally written in js.

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.

[Animats]

Nor is it "local first". It works by remotely pushing HTML into the DOM. It's really a form of push technology.

[kryptn]

htmx isn't local first. this blog post is about trying to make it 'local first' by introducing a service worker.

[kryptn]

i decided to use htmx for a frontend for myself and it was a pretty fun experience. even got tailwind involved pretty easily with my rust+maud backend.

[xg15]

It is definitely "anti-javascript" or more precisely "anti-SPA". I've read the blog posts.

[recursivedoubts]

htmx is pro-JavaScript:

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

[zelphirkalt]

JS != SPA though, no matter how many frontendies want to believe it is equivalent.

[brabel]

It’s funny to equate JS with SPA. We’ve had JS on the web since day 1 to add interactivity to otherwise static pages. SPA only became a thing decades later.

[michaelcampbell]

I was there on day 1 of the web and js was not yet even a twinkle in anyone's eye.

[someothherguyy]

https://en.wikipedia.org/wiki/Dynamic_HTML

[fires10]

?? Since day1?

[andai]

Day 1505 by my count. Say, does anyone know Javascript's birthday?

[someothherguyy]

There was a pretty long gap between JS being created and people making significant use of it.

[oldestofsports]

Sorry but you must have read with your eyes closed. Here’s a quote from the HTMX website:

”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/

[cubefox]

> HTMX is neither a meme nor is it anti-javascript, it is literally written in js.

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]

we are working towards incorporating some of its ideas into the html spec:

https://alexanderpetros.com/triptych/

[cubefox]

Thank you

[throwaway838112]

It is definitely meant to provide an alternative to JS, obviously

[BinaryIgor]

It's more like a JS-heavy library that allows you not to write JS, or write it as little and as rarely as possible

[sublinear]

Why not just write the js yourself? It's really not that complicated. The people who keep pushing for htmx are weird.

[Swizec]

> Why not just write the js yourself? It's really not that complicated. The people who keep pushing for htmx are weird.

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]

> 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.

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]

Because with HTML you get static, non-flashing, intstantly rendered without load times. So smart developers actually want less Javascript, because the browser already implements most of what Javascript does, why reinvent the wheel?

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]

> 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

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]

Which isn't JavaScript's failure per se. I wouldn't wat to use a Google Maps like thing, with full page reload each time I scroll or zoom or check details of a place.

The issue is of "plain" websites for bad reasons add dynamic stuff.

[HiPhish]

Why should I write it myself? Sure, I could do that, but then every time I want to have that sort of functionality on multiple pages I would have to write the JavaScript code multiple times. I could then roll it into a library. Maybe make the library work with custom HTML attributes. And now I've just reinvented HTMX. So I might as well use HTMX instead of reinventing it.

Such a weird question. You could ask that about any library ever.

[recursivedoubts]

there's a fair bit of functionality in htmx that isn't trivial: history support, event debouncing, etc. you can certainly write it yourself, but there are advantages to having existing functionality that is well tested and fits together reasonably

fixi.js is a more minimalist take on the same idea: https://github.com/bigskysoftware/fixi

agree that htmx users are weird

[on_the_train]

Because I don't know js and don't want to touch it