5 ms·

The difference in programming model IS THE advantage of HTMX. Changing from react to preact is a perf optimization. If you are doing the SPA thing correctly yo

The difference in programming model IS THE advantage of HTMX. Changing from react to preact is a perf optimization. If you are doing the SPA thing correctly you must duplicate business logic (data validation). Also when your API just sends "dumb data" (JSON) to the client, you are forced to make changes to the backend and frontend in lockstep.

strife25 4y ago
+1 SPAs were a workaround to slow CPU servers serving millions of requests in the mind-2000s. Client computers were faster, so it made sense to push UX logic there. We've flipped things around. Servers are fast as hell for rendering HTMl. We can leverage that and re-focus the client on UI code that only it can do.
- ec109685 4y ago
  They were also in response native mobile applications and desire to have a single api tier for all applications. That and the panacea of being able to run same javascript on server and client.
ksbrooksjr 4y ago
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.
- yawaramin 4y ago
  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.
  - ksbrooksjr 4y ago
    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.
    - eyelidlessness 4y ago
      I didn’t read the comment as disagreeing either. Sometimes people are commenting not to disagree ;)
      - ksbrooksjr 4y ago
        I read it as a straw man argument, but that might not have been the author's intention at all. It's hard to judge tone through text alone.
  - personalidea 4y ago
    Wouldn’t that also work the other way around? Move to a JS backend and now every dev on the team can write client and server side code?
    - 8organicbits 4y ago
      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?

strife25 4y ago

+1 SPAs were a workaround to slow CPU servers serving millions of requests in the mind-2000s. Client computers were faster, so it made sense to push UX logic there. We've flipped things around. Servers are fast as hell for rendering HTMl. We can leverage that and re-focus the client on UI code that only it can do.

ec109685 4y ago
They were also in response native mobile applications and desire to have a single api tier for all applications. That and the panacea of being able to run same javascript on server and client.

ksbrooksjr 4y ago

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.

yawaramin 4y ago
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.
- ksbrooksjr 4y ago
  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.
  - eyelidlessness 4y ago
    I didn’t read the comment as disagreeing either. Sometimes people are commenting not to disagree ;)
    - ksbrooksjr 4y ago
      I read it as a straw man argument, but that might not have been the author's intention at all. It's hard to judge tone through text alone.
- personalidea 4y ago
  Wouldn’t that also work the other way around? Move to a JS backend and now every dev on the team can write client and server side code?
  - 8organicbits 4y ago
    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?