According to the article we're commenting on, the programming model is not the sole reason for switching from React to Htmx. Look at the executive summary's bullet points. Four of them are related to performance (build time, time to interactive, data set size, and memory usage). Performance might not be the reason you personally use Htmx, but it's certainly put forward as an advantage in the article which we're commenting on (which is from the htmx team by the way).
I've often seen this meme repeated in debates that js frameworks require you to duplicate logic between the server and client, but most of the logic isn't being duplicated between the client and server, it's being moved from the server to the client. It's relocation, not duplication. Instead of your rails/django controllers deciding what html to render, that decision happens on the client. In this model your server is mostly just an authorization layer, and an interface between the user and the database. Hasura, Firebase, Firestore, Mongodb Realm, and several other products have been successfully built around this premise. You might not like the thick-client thin-server model, which is completely fine, but it's a somewhat subjective preference. The only objective criteria you might use to decide which approach to use is performance.
The article we're commenting on dedicates an entire section to talking about the dev team makeup and how it completely changed and unified the team approach to being fullstack. That's how thoroughly htmx changed the programming model.
You haven't disagreed with anything I said. My original comment says "Htmx is great for developers who need client side interactivity, but would rather not write any js". I'm sure a team of Python developers is enjoying not writing Javascript. My point is that you don't have to switch to a completely different paradigm to reap the performance benefits that the article lists.
"We are fond of talking about the HOWL stack: Hypermedia On Whatever you'd Like. The idea is that, by returning to a (more powerful) Hypermedia Architecture, you can use whatever backend language you'd like: python, lisp, haskell, go, java, c#, whatever. Even javascript, if you like.
Since you are using hypermedia & HTML for your server interactions, you don't feel that pressure to adopt javascript on the backend that a huge javascript front end produces. You can still use javascript, of course, (perhaps in the form of alpine.js) but you use it in the manner it was originally intended: as a light, front end scripting language for enhancing your application. Or, if you are brave, perhaps you can try hyperscript for these needs.
This is a world we would prefer to live in: many programming language options, each with their own strengths, technical cultures and thriving communities, all able to participate in the web development world through the magic of more powerful hypermedia, rather than a monolith of SPAs-talking-to-Node-in-JSON.
People certainly unify their stack on JS that way. For Contexte their team was one React/JS dev, two Django/python, and one full stack. So they had two and a half people writing python and one and a half writing Javascript before, then three python developers after.
Switching to JS would require a full backend rewrite. The backend devs may not do well with the switch, so they may have let go two developers and needed to hire a new JS dev. The presenter may have been let go with that approach, clearly not ideal for the person driving the project.
You'd also need to address the perf issues. htmx clearly sped things up. Is the alternative JS SSR?
Validating data on the client and not doing it again on the server will lead to security vulnerabilities. At the very least you will end up duplicating that validation code.
If I were using htmx I would still want to validate data on the client and the server. If you don't validate data on the client, then you're effectively allowing clients to DDOS your server with invalid data.
Client side validation does not protect against that. You can't prevent people from making requests to your server without your client, i.e. `curl https://example.com/api --data 'dkfjrgoegvjergv'`.
Well yeah obviously you can bypass the client code and directly connect to a server. That's not my point.
Client side validation doesn't prevent a malicious user from sending invalid requests, but it can prevent legitimate users from sending invalid data to your server accidentally. In fact, if I see validation failures showing up in my server logs for something I know should have been filtered out via client side validation, I can mark that ip address as being potentially malicious and rate-limit their future requests.
And as a user I would rather find out about validation issues immediately instead of waiting for a network round trip to the server. If I'm typing in a password for example and it doesn't meet the website's length/complexity requirements, I'd rather know as I'm typing instead of waiting for an HTTP request to complete. That extra HTTP request is wasting the user's bandwidth and the server's resources.
I've often seen this meme repeated in debates that js frameworks require you to duplicate logic between the server and client, but most of the logic isn't being duplicated between the client and server, it's being moved from the server to the client. It's relocation, not duplication. Instead of your rails/django controllers deciding what html to render, that decision happens on the client. In this model your server is mostly just an authorization layer, and an interface between the user and the database. Hasura, Firebase, Firestore, Mongodb Realm, and several other products have been successfully built around this premise. You might not like the thick-client thin-server model, which is completely fine, but it's a somewhat subjective preference. The only objective criteria you might use to decide which approach to use is performance.