| > 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: <a class="button" target="nofollow" onClick="...">
<span class="button__icon"><svg ...></span>
<span class="button__inner--withIcon">Blah</span>
</a> 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
|