Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I googled HTMX, all excited that maybe, just maybe, the browser people got their shit together and came up with a framework we can all live with, something native to the browser with a few new tags, and no other batteries required....

and was disappointed to find it's just a pile of other libraries 8(



htmx is written in vanilla javascript, has zero dependencies and can be included from source in a browser and just works

it doesn't introduce new tags (there are probably enough of those) but it does introduce new attributes that generalize the concept of hypermedia controls like anchors & forms (element, event, request type & placement of response/transclusion)

what do you mean?


Everything is a pile of libraries.

It’s a pile of someone else’s code all the way down.


You can also use the web platform straight up without transpilation, build tools, post-css compilation and all that jazz.

Just vanilla JavaScript, CSS, HTML, some sprinkles of WebComponents. And you can be pretty sure that you won't have to update that for a decade or more, as compatibility won't be broken in browsers.

Heck, I have vanilla JS projects I wrote 15 years ago that still render and work exactly like how they rendered/worked when I wrote them.


Indeed, that baggage is all that I avoid by using HTMX.


You do you. It's worth knowing though that using HTMX is not vanilla JS/HTML/CSS, it's literally the opposite of that.


Have you ever worked with just raw js?

Anything more than a todo list becomes unwieldy almost instantly.

Taking a small dependency to avoid that is well worth it.

Taking a whole “virtual dom” may be overkill though (looking at you, react)


> Have you ever worked with just raw js?

Yes

> Anything more than a todo list becomes unwieldy almost instantly.

That's not a fact, just your personal experience

> Taking a small dependency to avoid that is well worth it.

Sometimes, yeah. Sometimes, no.

> Taking a whole “virtual dom” may be overkill though (looking at you, react)

In most cases, probably yeah. React was created to solve a specific problem a specific company experienced, then the community took that solution and tried to put it everywhere. Results are bound to be "not optimal".


It's one small dependency. Worst case, you write the library yourself.

You send a request to the backend, it then sends you HTML back (all rendered in the backend using a templating language such as Django templating engine, Twig or Liquid), you insert it into a div or so.

Htmx was Intercooler, worst case you create your own. But no additional scripts needed.

I've been able to kick out Vue out because Htmx covers my use case.


> It's one small dependency. Worst case, you write the library yourself.

Every abstraction comes with a cost :) I'm not saying it never makes sense to use React, Vue, Htmx or anything else. But that's besides this conversation.

> You send a request to the backend, it then sends you HTML back

You're just trading doing stuff in the frontend for doing stuff in the frontend + backend. Might make sense in a lot of cases, while not making sense in other cases.


> You're just trading doing stuff in the frontend for doing stuff in the frontend + backend. Might make sense in a lot of cases, while not making sense in other cases.

For me I can now do everything in the backend, I don't need to switch context (Twig templating language vs. JavaScript / SPA / etc). It's now easier to just keep up to date with PHP / Symfony, instead of also updating Node, npm / yarn, node_modules, and keeping up to date with everything.

Otherwise the frontend part is messy and not so great code, since my JS skills are limited and it's too stressful for me to keep up to date with in addition to PHP / Symfony (I had worked with AngularJS 1, Angular 2-8, Vue 2, some React, played around with Svelte, managing stuff via bower, gulp, grunt, Webpack, parcel, npm, yarn 1/2/3, Node 10-18, nvm, corepack; and if I kept up, I probably need to look at bun soon).


https://xkcd.com/2347/

And don't forget the alt-text


Nothing to be disappointed in here AFAICT, however, it’s shocking that you had to Google HTMX, seeing as it shows up on HN a few times a month at least.


I'm guessing the disappointing feeling come from parent saying "Pff, I'm so tired of all these libraries that eventually update their APIs in a breaking way, so now I'm using X" while X is just another library exactly like all the rest, and will surely introduce a breaking change or two down the line.


HTMX is not _exactly_ like the rest. It's far simpler than the others, e.g. by not requiring a build step, being pure JS and just having a smaller scope overall. Hot/cold isn't binary.

One of the contributors to the project wrote about the issue here: https://htmx.org/essays/no-build-step/


You're arguing from the abstract point of view, rather than the practical. The point is that it takes an order of magnitude more time to clone, say, a Vue project from three years ago that nobody has touched since then and try to download your dependencies and build on a new machine, as compared to an HTMX project.


As if "npm/yarn install" wouldn't work for the hypothetical Vue project? A charitable interpretation of what you're saying is that you cannot clone a vue project from three years ago, update all dependencies to the latest version, and expect that to work. But then, how is it different for HTMX, other than for the fact that 1. it's younger 2. you don't have the ecosystem around it to update - but that also means you're doing less or redoing everything yourself.


>As if "npm/yarn install" wouldn't work for the hypothetical Vue project?

I'm not talking in hypotheticals. No, if you do this for a Vue project that hasn't been touched in a few years, it doesn't work. Upon cloning the source, and running npm install, you'll run into loads of build errors between incompatible versions of npm dependencies, even after you've used nvm to switch back to an old version. A build process, especially one based on npm, intrinsically introduces great amounts of fragility to the project.

Yes, you pay for it by having to invent a lot of things yourself, but limiting the project to HTMX means you've just got one dependency to store and it'll work so long as you do that.

Back to the point of TFA: you can have a cold blooded project with a dependency to HTMX and one or two other JS libs. Once you introduce an npm build, you're squarely out of cold blooded territory due to the constant updates and maintenance required just to keep your build working.


Okay, go ahead. Show me a (serious) project that hasn't been touched in three years and that plain doesn't work it you install packages from the lock file. You made a claim, I said I was skeptical, your only counter argument was... To reiterate your initial point without adding anything new. So, time for evidence.


It's a work project, you'll have to take my word for it. I'm staring at the node gyp errors right now.


Sure...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: