Hacker News Reader

I would argue that any HTML + CSS framework stack is inherently flawed once you move beyond the most basic of UI components.

I have yet to work on a React + Tailwind codebase in the wild where the margin/padding metrics aren't hardcoded and repeated across tens of different components. We've traded the elegance of well-written SCSS for improved developer ergonomics and faster build times because webpack is so slow at compiling stylesheet changes.

If you want to practise proper DRY for spacing, typography, etc. in a React app, you'll just end up nesting tons of components that ultimately result in needless complexity.

Then you haven’t seen my company’s codebase ;) this is where CSS in JS done well shines - you can use JS standard modules to handle all this code sharing. Choose the right abstractions - in my experience 90% of UIs can be expressed as sets of evenly spaced stacks of elements (horizontal or vertical) and if you export well thought out mixins that express that concept and your team understands why they should use them, you’re most of the way there.

> Like on backend you will have a choice of database, choice of language, and the design of the Schema/API, most of which are easy to detach and replace at some point.

This is absolutely not my experience. Every company I've worked at has had some long running back end tech debt, trying to swap out old tech.

Every problem you listed for the FE has a BE analog. Is it just that there are a lot of choices for FE tech? IMO that's a strength and not a weakness. There's also a clear leader in the tech for each part of the stack to choose to get something running quickly.

> Or you can skip those above and use pure HTML+CSS+Javascript, but those usually end up as very spaguettified and idiosyncratic projects, I rarely see anyone even considering it unless it's a personal project.

This is like saying you're seeing BE devs consider writing all their DB queries in raw SQL in a production system rather than use an ORM. Sure, it's done sometimes but most of the time it makes sense to use an abstraction layer.

Again, it's mostly whether or not engineers have the time to plan ahead and also update old code.

Imagine complexity and chaos are the same thing. But at least you got the bags of interesting new problems to play with. Job security etc it isn't all bad.