[exogen]

Because many web sites and apps aren't as simple as "my first homepage" and don't only consist of first-party code. Think component libraries. Reusable code. Content management systems. Third-party SDKs (chat widgets, support widgets, payment widgets like Stripe, etc.).

One of my earliest webdev jobs was at a company whose product was a widget you could add to your site by adding our `<script>` tag. Thus, our CSS needed to coexist with the first-party site's, not to mention any other third-party widgets on there. In other words: the same exact reason you need modules in traditional languages.

[bryanrasmussen]

It's true in a case where you are doing the described thing you will need to come up with your own module system and ways to not step on other people's stuff but it isn't actually difficult. Although I have noticed some stories recently were quite big companies evidently didn't put in the work to keep from messing up other people's stuff.

Of course one drawback with that is you are also depending on developers and content managers at sites following your documentation on how to use your products, which is a different problem.

on edit: obviously if you have been writing css since 1997 and one of your first webdev jobs was this kind of thing, things were much more difficult back then. I did the same sort of thing in 2014-2015, not particularly difficult to make work. I worked web dev since 1999, first job was dynamic generation of web sites and other media from single source data.

[pjaoko]

> Because many web sites and apps aren't as simple as "my first homepage" and don't only consist of first-party code.

CSS is there to style HTML tags. Yes, your complex webb app is dealing with a lot of third party code and whatnot... but CSS is just there to style your HTML tags. Why is it so hard to get that?

[exogen]

Because that third-party code adds its own HTML tags.

Because that third-party code adds its own CSS.

Because my HTML and the third-party HTML live in the same document. Thus, my CSS could target their HTML, and their CSS could target my HTML. There are no modules and therefore no module boundaries.

Because my CSS and the third-party CSS share a global namespace. Thus, their CSS selectors might overlap with my CSS selectors. Hopefully nobody called anything ".container" or ".wrapper" or ".button" since there's no namespacing, right?

Keep in mind these components might be arbitrarily nestable. Maybe my elements can be a child of theirs? Maybe theirs can be a child of mine? Can I opt out of the cascade? Should I?

Maybe we could all use the Shadow DOM? I don't really have control over what third-parties do, but let's say I dig into their implementation (what fun) and choose only ones that use the Shadow DOM. Now I've massively bumped up the complexity and ensured my document can't render without JavaScript; lots of user-agents go right out the window and see nothing.

Let's reduce it to the simplest possible case: you and I are working on the same website, but I'm responsible for the header and you're responsible for the footer. We even have our own separate .css files. Yay, no merge conflicts.

Can you and I safely write our selectors without coordinating with each other?

(If you think the answer is yes... you're wrong.)

Now add a few dozen more team members and several third-parties who we in fact CANNOT coordinate with.

Everywhere you turn there are tradeoffs and half-solutions. Turns out "Just Do X" is not very helpful. Thus, I don't blame people at all for developing their own solutions to scaling CSS - like OP's framework.