Item — HN Reader

It's quite simple in my view.

The "separate markup and styling" paradigm with shared css will lead to refactors having a large blast radius. When you've organised your team by mapping people -> features(components), this makes this paradigm completely unviable. Tailwind wins there, that's it.

For web apps, having separate markup and styling makes absolutely zero sense, while it does for textual, reading content like blogs.

So, web apps like to use tailwind/bootstrap.

Reaaaaalllly large web apps (e.g GitHub) swing the pendulum all the way around, and make their own little bootstrap which adheres to their design language.

2 comments

Using semantic css doesn't always mean your markup and styling are separate.

There are plenty of modern frameworks nowadays that use single file components (pretty much every popular framework except react?) and often you even choose to scope the css to one component only, if you want.

Tailwind is not worse in this case either, and one might argue the “cascading” part of CSS is useless on such a local scope.

Also, tailwind gives you a pragmatic, limited selection of sizes, colors, etc, which is a very good basis for designing. (You shouldn’t be using a new px value for everything, they should come from a small custom-chosen set)

Again. This is purely a matter of taste. I personally prefer the semantic approach.

Of course. From each person's POV, it is a matter of taste.

But in real life, in the 80% case, a true software "team" doesn't exist. Instead, you have a bunch of individuals working on a product, who won't be ready to fix issues in another person's feature.

It is very common to map features/components to people when managing software teams, in the obvious case with react,etc, and even in Ruby on rails type stuff to a certain extent.

From a political point of view, aaas much as possible, you want changes to page A, to only involve pageToPerson.get(A).

So, the first thing companies want to avoid is people stepping over each other. Again, healthy collaboration does not exist in the 80% case.

It's the same pattern with other things that are questionable from a technical point of view.

- using docker, microservices, etc where not required, so no cross-team, common dependencies, or even common database in the extreme case. - making each part of your codebase its own npm package

N.B

My definition of "exist" is "present and dependable upon to such an extent you will risk your job on it".

Addition:

Of course, people without the problems use the solution because $bigtech does it.

That is a separate problem :)