Of course you have to validate on the server. That's a given, always.
But you want to provide better UX to the user.
Htmx is not simpler than React. I can't deploy that without a server that knows everything about the frontend. React allows me to decouple. Templates are hell. I lived in it for many years, never again.
Detractors of the "html over the wire" movement are always talking about it as if the people working on this stuff didn't live through the jQuery days and are blindly repeating them.
Sure, you do you. I spent 10 years working with jQuery and am very thankful to leave that very far behind me.
BTW: jQuery is 85.1 kB minified and 29.7 kB gzipped. Preact (same API/dev experience as React, minimal performance impact) is 11.4 kB minified and 4.5 kB gzipped. Who has the smaller JS bundle now?
So did I and you’re side-stepping my initial comment by responding to my response that people can use jQuery if they want. I no longer use it myself nor, btw, did I say anything about its size.
Why though? It's much easier to do a simple API (or use a pre-made one like this one) from the web and the app. And no need to change the backend code on design updates.
I just don't get what you're chasing after. All this seems more complex (to develop, to maintain, to operate, to manage) than what I'm doing with (P)React (Native) and APIs.
And where are the thousands of pre-made components like React has?
- code base reduced by 67% (21,500 LOC to 7200 LOC)
- total JS dependencies reduced by by 96% (255 to 9)
- web build time reduced by 88% (40 seconds to 5)
- Time-to-interactive reduced by 50-60%
- htmx allowed them to display much larger data sets
- memory usage reduced by 46% (75MB to 45MB)
the essays above also discuss why to split your apis (disentangle web app churn from your general purpose data API) and how to avoid duplicating logic (the mvc essay)
i take pains to reiterate in the essays and book that htmx isn't right for every application, but it is a good architectural choice for some, and many more than most web developers who are used to reactive-style programming would think
there are not thousands of pre-made components for htmx because there are no components for htmx: there are rather components for HTML. those components should integrate with htmx in the HTML-standard manner: events & form participation
Sorry but this sounds like they just didn't know how to write React and didn't take the time to learn it. You can write React and have 2 runtime dependencies in total - react and react-dom. Or you can go for preact and have exactly 1 runtime dependency - preact. Everything you need is there.
Time-to-interactive has never been a problem for me. My code-splitted bundles are so small they're pre-loaded quicker than the server-rendered HTML code. And builds? My apps - even big ones - build in single digit seconds (using swc or esbuild), and small ones like forms we're talking about in less than a second. The only thing that takes long time is TypeScript typechecking, I do that in a separate task in my CI while the build is long done and tests are in progress at the same time.
I'm not saying all this is super easy - obviously it's the product of using React literally since it's first public beta release. But it's also not impossible to do, and setting up a htmx and a server to run it on is IMHO similar complexity.
The biggest mistake people do - they use stuff like create-react-app with a bunch of absolutely unnecessary cruft. And then they follow some tutorials made by a dude who knows React for 2 months. Just read the React docs (except for the create-react-app part) and you're good to go.
BTW: jQuery is 85.1 kB minified and 29.7 kB gzipped. Preact (same API/dev experience as React, minimal performance impact) is 11.4 kB minified and 4.5 kB gzipped.
But you want to provide better UX to the user.
Htmx is not simpler than React. I can't deploy that without a server that knows everything about the frontend. React allows me to decouple. Templates are hell. I lived in it for many years, never again.