1. Backend and devops are disciplines rooted in _mechanical sympathy_. Basically, the better you can understand the needs of the stack (hardware on up,) the bet

1. Backend and devops are disciplines rooted in _mechanical sympathy_. Basically, the better you can understand the needs of the stack (hardware on up,) the better you can meet requirements, which, generally, are stipulated in clear-cut technical terms ('this many requests per hour', etc.) Minimizing complexity is a core value. 2. Frontend is rooted in _user sympathy_. The better you can understand the users, the happier you make them. There are bodies of knowledge (usability theory) that can help with this, but the users are often "irrational" (but, crucially, not _wrong_) in their preferences; e.g. preferring a complex PWA tech stack with a 5s initial load time (but buttery smooth responsiveness thereafter) to a simpler static htmx-style stack with a 0.2s load time per click. They also experience ever-changing needs, and respond enthusastically to trends that do not have any clear basis, (skeumorphism vs not-skeumorphism, etc.) but are nonetheless _vital_. If it's important to your user, it's important, and your job is to do anything and everything to meet those needs, even at the cost of enormous gobs of complexity (provided those gobs don't make them less happy in some other way, today or tomorrow.) CSS, in particular, has evolved over a period of decades to meet these requirements, and generally does an admirable job of meeting the whims of users, but at an ineluctable complexity cost. (Why do users want drop shadows? Why do they want masonry grid layout? Who knows, but here you go!) React, similarly, is a Rube Goldberg machine that, for whatever reason, seems to produce apps that meet user expectations better (more efficiently) than alternatives, without fudging the details (or going 'brutalist') Other strategies -- insisting on old-school 'simple' design, which while conceptually pleasing to non-frontend engineers (that mechanical sympathy!), trade off pizazz for maintainability; but often, I expect, they discover that a non-zero number of users _liked_ the pizazz; that it was a sotto-voce requirement; and that it is now out of reach; and that their solution now has worse product-market fit than it would otherwise have. This is why, while engineers love htmx, but it rarely shows up in big consumer-facing products. It would appear that for apps like Gmail, etc. something like the PWA model is a more natural centre-of-gravity.