Why Htmx is far superior to React and NextJS(henriqueleite42.com)
henriqueleite42.com
Why Htmx is far superior to React and NextJS
https://henriqueleite42.com/why-htmx-is-far-superior-to-react-and-nextjs
7 comments
I agree that Next is too big and you might as well just render it server side, but my question is, if you’re using HTMX, aren’t there substantial costs to the server side rendering that you’re doing, compared to sending lighter JSON and letting the client handle it?
Also,
Also,
"We lost the pro of not spending with servers, now we need a server to run our frontend"
> costs to the server side rendering
wouldn't the simplicity of generating html instead of invoking json more than make up for any data savings?
wouldn't the simplicity of generating html instead of invoking json more than make up for any data savings?
Frontend with golang? I found it curious. Not sure if I would pick it to be part of my frontend stack.
> So, to create any website, we need a framework, everyone knows this unquestionable truth.
They lost me already. Is this supposed to be sarcasm? I'm hoping it is - the more I read, the more the entire article looks like they were trying to write satire... but then they end with a non-sarcastic conclusion.
I'm really unclear if this whole thing is satire or if they really just hate JS so much that they are over-exaggerating the most complex ways to engage with its ecosystem.
They lost me already. Is this supposed to be sarcasm? I'm hoping it is - the more I read, the more the entire article looks like they were trying to write satire... but then they end with a non-sarcastic conclusion.
I'm really unclear if this whole thing is satire or if they really just hate JS so much that they are over-exaggerating the most complex ways to engage with its ecosystem.
The main thing I find with articles that are anti-React is that they are saying React is bad when all you need is a pretty simple site with some dynamic elements. That's 100% true, it never hasn't been true, and any react evangelical will tell you the same thing.
I would love to hear this authors take on if they would choose HTMX for a web app that is constrained to be highly-interactive, with multiple contributors/teams, and a dynamic user interface that requires heaps of internal state.
I would assume the counter-argument would be, "something like that should not be on the web!", but unfortunately we are in a world where that is what customers expect for certain classes of application.
I would love to hear this authors take on if they would choose HTMX for a web app that is constrained to be highly-interactive, with multiple contributors/teams, and a dynamic user interface that requires heaps of internal state.
I would assume the counter-argument would be, "something like that should not be on the web!", but unfortunately we are in a world where that is what customers expect for certain classes of application.
I would say that is true for any web app with multiple contributors. If you don’t use an existing framework and try to just use js DOM methods you will end up creating your own framework eventually, but now no one understands it except you.
- "It's extremely complex for someone with 0 experience to work with JavaScript tools"
- "JavaScript is terrible anything else than manipulating the DOM"
I guess the main issue was not liking / embracing JavaScript/TypeScript. Which is fine, but doesn't really make for a convincing article.
Another thing I would have loved to see was all the issues you ran into with htmx (apart from the ID collisions you expect to get). As we all know, everything is a tradeoff, there are no silver bullets.