Anecdotally I've built hundreds of websites, and worked on many product teams building web applications all with varying team/product sizes and in my experience BEM scales very poorly. I have never worked on a BEM codebase without a shocking level amount of tech debt. Adding new UI requires creating new CSS files, refactoring existing UI requires also refactoring the separate CSS files, removing UI is the same thing. Due to this disconnect, old code tends to stick around.
One of my product teams moved from BEM to Tailwind and productivity/maintainability improved tremendously.
Adding new UI requires creating new CSS files, refactoring existing UI requires also refactoring the separate CSS files, removing UI is the same thing. Due to this disconnect, old code tends to stick around.
To me this says more about the development practices of that team than about BEM. Chiefly you should be able to automatically determine if a given block, element or modifier is still used/needed. How did they wind up in such a situation?
Meanwhile Tailwind is functionally equivalent to this:
I would say that this is nice for prototypes, but given how it disincentivises reuse, refactors take an amount of time proportional to the number of instances - that's really bad.
Also since there's no composition, just by looking at the codebase it's not clear if a change is something that should propagate to other, similar instances or land only there.
I'm not sure what gives you the impression that there is "no composition". It's been common practice on many large scale Tailwind builds that I've been a part of to use the @apply directive[0] to create reusable components when appropriate.
> To me this says more about the development practices of that team than about BEM
Well you could say that BEM requires strict development practices to work well. This is could be a downside for many teams, seeing as this comes at a cost which grows as your team/product do. Organizational overhead is a significant factor when considering a technical solution.
> Meanwhile Tailwind is functionally equivalent to this:
It's a funny platitude, similar to the argument that "Tailwind is just like inlining CSS" but it's of course overly simplified. Variable support, hover/active/other states, and of course breakpoint-specific variants for all of the classes making responsive styles possible.
> Also since there's no composition, just by looking at the codebase it's not clear if a change is something that should propagate to other, similar instances or land only there.
Even with BEM, you usually store components in partials/templates to keep everything contained and to reduce duplication. So in this regard the composition is the same. You import a button in your code, you aren't writing out this every time:
The composition happens within the templates themselves.
EDIT: I'll follow up and say that the "composition" for Tailwind components works very similar to CSS Modules (CSS is scoped to a component, and delivered with the component itself), or StyledComponents (similar to CSS Modules, but built into the React component itself). But with a few more benefits:
1. Does not rely on a build system to bundle/deliver styles
2. Less abstraction; no need to create scoped classes even (in the case of CSS Modules)
3. Works outside of the JS/React ecosystem
Anecdotally I've built hundreds of websites, and worked on many product teams building web applications all with varying team/product sizes and in my experience BEM scales very poorly. I have never worked on a BEM codebase without a shocking level amount of tech debt. Adding new UI requires creating new CSS files, refactoring existing UI requires also refactoring the separate CSS files, removing UI is the same thing. Due to this disconnect, old code tends to stick around.
One of my product teams moved from BEM to Tailwind and productivity/maintainability improved tremendously.