This is why I am trying to switch as many projects I'm on as possible to HTMX. The churn involved with all of the frontend frameworks means that there's far too much update work needed after letting a project sit for N quarters.
and was disappointed to find it's just a pile of other libraries 8(
It’s a pile of someone else’s code all the way down.
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.
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.
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.
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).
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)
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".
And don't forget the alt-text
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.
One of the contributors to the project wrote about the issue here: https://htmx.org/essays/no-build-step/
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?