Back before component libraries were really a thing I was an engineer at a mature startup. The front-end world hadn't really blossomed yet; you could still reassign null, we didn't have TypeScript or even React. My company was well known for their engineering in Boston, top grade stuff. And they tried to do the right things on the front-end, but there weren't all that many right things defined at that period in time. Most developers went off of the book JavaScript: The Good Parts by Cockford at the time, if they were serious about front-end engineering and this company was no different. We read all of the top books, subscribed to O'Reilly, went to conferences, all of it -- always keeping up on the latest and greatest.
Despite all of that, the front-end always seemed to suffer from some problem.
Before I got there they we constantly overriding styles, but reusing them as much as they could. It made sense, but it got so out of control that Internet Explorer would just ignore the override of the override of the override. Divs ended up with so many classes sometimes, that IE would just cut it off. I think the max was 32 classes per element or something like that.
We'd do hack weeks, so during mine I analyzed some of what was going on. We had a small common toolbar used across dozens of pages, but I found we also had dozens of variations of the thing, mostly around how to position it for that specific page. But that's a lot. It's too much really, who can understand when to use which variation when? It's too much to grok.
I took those findings and made a presentation at the end of the week. And then I introduced them to BEM. They loved it and surprisingly my biggest ally ended up being the Director of Product. I think he understood the story I told and could understand how fixing problems like the one I surfaced could speed up development, so it's a win for everyone: engineering, product, and the customers. More product, consistently made, with consistent UX -- faster. So we ran with it, BEM changed a lot for us, in a positive way of course.
Fast forward to 18 months ago or something and I'm doing work for a front-end team and... they use MUI. It's not my first choice, my biggest problem with it is that components have way too many props. It's too much to learn and in the name of being agnostic about as much as possible. That's great for a component library that you want to build your own on top of, but many companies don't think of it exactly like that. They might make their own abstractions on top of them to style them or change behavior, but they usually allow for all props of the based component to be passed in as well. For a library like MUI, that means a lot of props, which allow for a lot of variation, className being the worst of them.
That is to say, this company, like many others, made their own dialogs, drop downs, etc, but they allow for className too, well "classes" in the MUI world. And they use classes... a lot. Oof. Yeah, dozens of variations of everything, even a regular old button was being styled on pretty much every page. Drop downs were very difficult to make, because they had to be composed of multiple components; some others were like this too.
The question is: how can we create an atomic, self-documenting, easy to use components when they can be heavily altered by external sources? It's really just not possible. You could improve on some of those desired characteristics, sure, but you won't get too far using the general approach they did when abstracting MUI.
That which can be abused will. That should be a rule in engineering. We have a rule about always sanitizing inputs because they can be abused otherwise, it's not too dissimilar.
The company wanted to create a second offering, so it was the perfect time to introduce a real component library and a monorepo. No more className, classes, etc. The words variation, variant, and pattern were used a lot in the months following. No more one-off styles. For example you can style a button by changing it's variant (primary, secondary, danger, etc) and it's size prop (small, medium, large) -- that's it. If I saw someone doing otherwise in pull requests, I'd teach them the ways. It was easier to get people to adopt than BEM really, it's far less structured.
So we lifted and shifted the components we had into their own package, but dramatically altered how we created them. Once we were done migrating the bulk of it, we were free to create the second product. There was more involved of course, but this post is just about component libraries.
Magic. The UI became so much easier to work on, it's difficult to express. I think the big shift was essentially moving from writing css all of the time to rarely since we could simply use props like variant and size props to compose the correct styling, effortlessly.