[wibblewobble124]

we’re using htmx at work, migrating away from react. the technique we’re using is just rendering the whole page, e.g. we have a page where one side of the screen is a big form and the other side is a view on the same data but with a different UI, updating one updates the other. we’re using the morphdom swapping mode so only the things that changed are updated in-place. as a colleague commented after implementing this page, it was pretty much like react as far as “pure function of state.”

our policy is that for widgets that are like browser components e.g. search as you type with keyboard shortcuts, we just use the off the shelf react component for that purpose and use it from htmx like it’a browser input element. for all other business logic (almost all of which has no low latency requirements and almost always involves a server requets), we use htmx in our server side language of choice.

our designer who knows a bit of react is not happy, but the 12 engineers on our team who are experts in $backend_lang and who are tired of debugging react race conditions, cache errors, TypeScript front end exceptions, js library churn, serialisation bugs, etc. are very happy indeed.

it doesn’t fit every app, but it fits our app like a glove and many others that I’ve considered writing that I didn’t feel like bothering to do so before discovering htmx.

[robertoandred]

Sounds like your backend devs are just bad at frontend.

[wibblewobble124]

this is a shallow and dismissive comment lacking any basic charity or nuance: dijkstra was just bad at “goto.”

this doesn’t worry me, though. those in the react crowd that insist on this arbitrary and newfangled “frontend/backend” stratification and are dogmatic about it are by definition going to stick with what they know and won’t come and bother us who choose tools based on real experience and their practical merits. better off they make themselves easy to spot from a distance.

[robertoandred]

"Frontend/backend" is neither new nor pointless. The people who pretend they are are usually backenders who are under the false impression that frontend is simple.

[wibblewobble124]

if you’ve been writing HTML since 1999 like me then it’s newfangled. in 2008 when i got my first paid job writing ASP and PHP at a web dev shop, nobody was “frontend”. there was the content person, the designer (photoshop wiz), the builder (convert design into HTML) and the dev. we still had to support IE6 or our manager would yell at us. i wrote my first SPA at work in 2011, and that was radical—everyone thought it was a bad idea. some people thought backbone.js might be a cool approach. took ages for react to appear.

took until maybe 2015 before i remember seeing any job ads of “frontend” positions, it takes a while before a job market develops around a technology.

i didn’t say it was pointless. i said the stratification of “dev” into “frontend dev” and “backend dev” is newfangled and arbitrary. you could also split devs into other classes (DB only, CSS only, etc.).

it is funny when people who don’t know you accuse you of incompetence because you don’t like their tools or methods. dogmatic. i prefer some other tools and methods and i am delivering value to customers. pragmatic.

[ihateolives]

And? Your average React dev is bad at proper backend too.

[robertoandred]

So then doesn't it make sense that frontend devs focus on frontend and backend devs focus on backend?

[CRConrad]

It makes sense that application developers focus on getting an application to work. In the case of these newfangled “Web applications”, that would be focussing on getting HTML to render in the user's browser. That focus doesn't have to have anything to do with an arbitrary split into “frontend and backend”.