3 ms·
The problem I have with this style of library for frontend dev work is eventually the scope of the problem exceeds what the library is capable of doing. Then yo
by iterateoften 3y ago
The problem I have with this style of library for frontend dev work is eventually the scope of the problem exceeds what the library is capable of doing. Then you have to embed JS which then gets pretty messy and spaghetti code and enough of this you are right back to where you started setting up a JS build system to make up for the deficiencies. Only now it is worse because you are working around one library and you start fragmenting your app because you started with the wrong thing.
- karmarepellent 3y agoBut it is not a given that the scope of the problem eventually exceeds what HTMX is capable of. It is perfectly fine to set HTMX aside and choose another framework if you feel that it better suits the problem at hand. Meanwhile there is still a ton of projects for which HTMX is more than enough (and always will be). So what you are mentioning is not an issue of HTMX, but one of "chosing the right tool for the problem".
- iterateoften 3y agoThat’s fair. I guess my comment was inadvertently responding to another about why you don’t see it at large companies. One team at my company wanted to use HTMX and write the product with it and then the PM kept asking for features to bring it to parity with the rest of the application with regards to client side behavior and things devolved. They used hyperscript and eventually the frontend was just rewritten to be react.
- karmarepellent 3y agoWell I would not dare going through the hassle of moving from React to something like HTMX if the former is already well-established in the company, except when everyone is on board. So I totally get that.