4 ms·

HTMX looks pretty much like something I would use for fast prototyping with very limited complexity/the scope is known ahead to stay simple. I've been working i

HTMX looks pretty much like something I would use for fast prototyping with very limited complexity/the scope is known ahead to stay simple. I've been working in full-stack for a decade together with extremely skilled engineers on large monorepos. Our wisdom is to stay as vanilla as reasonable and understand what your technology does underneath. As soon as there are layers over layers (tools calling tools with domain specific languages) you wish you could simply change X directly instead of having to go through e.g. create-react-app or htmx. But if any framework can provide me that level of comfort then I'm fine with it although I learned the more comfort frameworks provide the darker the other side.

Woshiwuja 3y ago
i disagree. making the backend format a div and send it back is much faster than creating a json, sending it to client and having the client hydrate stuff inside the page
- replwoacause 3y ago
  I have found this to be true in my experience too, but I’m not a professional dev, rather a hobbyist, so HTMX suits me just fine. That isn’t to say it doesn’t have a place in the toolchain of professional devs though!
  - Woshiwuja 3y ago
    both things can be true at the same time! For an hobbyist you get to write less js. For a company you get faster apps. Its a win win situation
infecto 3y ago
I see these kind of comments pop up and as a long time backend/full-stack dev I don't follow the logic all too well. HTMX is just another tool to be deployed. If your app requires a SPA experience or large amounts of javascript for the UI, its not the right tool for the job. Where I have had great experience with it is for applications that have discrete javascript implementations or none. Lot's of applications that are quite valuable to the end user, are really just a bunch of CRUD like operations and don't really need a full blown FE framework.
mst 3y ago
I had some 'fun' figuring out how to deal with not going through create-react-app without doing a full eject, got something barely working ... and discovered https://craco.js.org/ https://craco.js.org/ already existed and did precisely what I'd part-implemented except better. On the upside, by that point I knew the CRA codebase well enough to predict what it would do even in edge cases, and CRACO's implementation was immediately comprehensible, and none of my colleagues had to try and understand my half-arsed NIH version. (avoiding being in any of this situation in the first place would likely have been preferable, but given where things were when I landed on the project in question that would've required a TARDIS)

Woshiwuja 3y ago

i disagree. making the backend format a div and send it back is much faster than creating a json, sending it to client and having the client hydrate stuff inside the page

replwoacause 3y ago
I have found this to be true in my experience too, but I’m not a professional dev, rather a hobbyist, so HTMX suits me just fine. That isn’t to say it doesn’t have a place in the toolchain of professional devs though!
- Woshiwuja 3y ago
  both things can be true at the same time! For an hobbyist you get to write less js. For a company you get faster apps. Its a win win situation

infecto 3y ago

I see these kind of comments pop up and as a long time backend/full-stack dev I don't follow the logic all too well. HTMX is just another tool to be deployed. If your app requires a SPA experience or large amounts of javascript for the UI, its not the right tool for the job. Where I have had great experience with it is for applications that have discrete javascript implementations or none. Lot's of applications that are quite valuable to the end user, are really just a bunch of CRUD like operations and don't really need a full blown FE framework.

mst 3y ago

I had some 'fun' figuring out how to deal with not going through create-react-app without doing a full eject, got something barely working ... and discovered https://craco.js.org/ https://craco.js.org/ already existed and did precisely what I'd part-implemented except better. On the upside, by that point I knew the CRA codebase well enough to predict what it would do even in edge cases, and CRACO's implementation was immediately comprehensible, and none of my colleagues had to try and understand my half-arsed NIH version. (avoiding being in any of this situation in the first place would likely have been preferable, but given where things were when I landed on the project in question that would've required a TARDIS)