3 ms·
No, it's meant for websites that don't require loading 8 MB of JavaScript. You've completely missed the point that "product line heavy JavaScript interactivity"
by henning 4y ago
No, it's meant for websites that don't require loading 8 MB of JavaScript. You've completely missed the point that "product line heavy JavaScript interactivity", whatever that means, is bullshit that doesn't solve any problems, it just creates new ones.
You're saying "I have all this code, what do I do with all this code." The answer is: don't write it!
- no_wizard 4y agoNo, I'm simply positing that HTMX doesn't fill the void of heavy web apps, like Figma, or Salesforce. At least not naturally. React does scale well in this way. So does Angular (though I don't care for it, which is another discussion entirely). Especially when you want maximal code sharing in your dependency chain. I never done it with Vue (largest Vue app I ever worked on had roughly 200K lines of deployed code, all in, for the application, very thick client type stuff), but maybe with Vue 3 and the composition API this isn't an issue (I don't think Vue 2 would ever scale well developer experience wise this way) I'm not throwing shade on HTMX, but there tends to be this energy around it that would make someone who, perhaps trying to weigh some options, stumbles across HN, sees threads like this and thinks oh gee! This sounds great without knowing exactly what that means. And it is true, that perhaps, that person is building app that needs scalable reactivity and fine-grained control, or something along those lines. I at least want to give a fair take on purpose for people thinking about it. HTMX is great for its target audience, much superior to jQuery in this day and age, but you have to understand what its for.
- mixmastamyk 4y agoThe time wasted by choosing htmx for the wrong job is probably quite small compared to choosing react for the wrong job.