4 ms·

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

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.

mikewarot 3y ago
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(
- dartos 3y ago
  Everything is a pile of libraries. It’s a pile of someone else’s code all the way down.
  - diggan 3y ago
    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.
    - jollyllama 3y ago
      Indeed, that baggage is all that I avoid by using HTMX.
      - diggan 3y ago
        You do you. It's worth knowing though that using HTMX is not vanilla JS/HTML/CSS, it's literally the opposite of that.
        kugelblitz 3y ago
        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.
        diggan 3y ago
        > 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.
        kugelblitz 3y ago
        > 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).
  - Tao3300 3y ago
    https://xkcd.com/2347/ https://xkcd.com/2347/ And don't forget the alt-text
- replwoacause 3y ago
  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.
  - diggan 3y ago
    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.
    - jollyllama 3y ago
      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.
      - uxp8u61q 3y ago
        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.
        jollyllama 3y ago
        >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.
- recursivedoubts 3y ago
  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?

mikewarot 3y ago

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(

dartos 3y ago
Everything is a pile of libraries. It’s a pile of someone else’s code all the way down.
- diggan 3y ago
  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.
  - jollyllama 3y ago
    Indeed, that baggage is all that I avoid by using HTMX.
    - diggan 3y ago
      You do you. It's worth knowing though that using HTMX is not vanilla JS/HTML/CSS, it's literally the opposite of that.
      - kugelblitz 3y ago
        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.
        diggan 3y ago
        > 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.
        kugelblitz 3y ago
        > 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).
- Tao3300 3y ago
  https://xkcd.com/2347/ https://xkcd.com/2347/ And don't forget the alt-text
replwoacause 3y ago
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.
- diggan 3y ago
  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.
  - jollyllama 3y ago
    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.
    - uxp8u61q 3y ago
      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.
      - jollyllama 3y ago
        >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.
recursivedoubts 3y ago
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?