BEM claims to fix a lot of organisational problems of CSS codebases, which is true, but it also creates tons of new problems which at the end are for the worse. I would be able to go deeper in this topic, but let me just highlight a few points.
BEM has a lot of rules which are not trivial to understand correctly at first sight. It's definitions of blocks/elements are debatable, and that's the reason every person understands BEMs rules a little differently, using it in their own flavor. This creates problems in teams, especially on a bigger scale. I've participated in and seen a lot of reviews the past decade on codebases using BEM arguing about the correct naming, structure, and selectors.
BEM requires deep knowledge of the codebase, otherwise people start reinventing already existing parts. This is true in general to well agrd code, but in BEM's rule-system individual pieces can hide well let's say. I don't know how to express this more clearly :)
BEM needs extra brainload which makes the process of site-building inefficient. It simply blocks the flow.
BEM is kinda immutable. By that I mean that it's hard to refactor. The structure and rules force a "non-flexible frame" around your codebase.
The mess and unreadability of the classes, and the 32 character long selectors at the end it's just the tip of this iceberg.
BEM simply has significant negative impact on productivity, and at the end it's not as maintainable as it claims to be.
Most people usually like the Modifier part of BEM, but that's not new or unique to BEM, only the double dash maybe...
To add something constructive to the table. I believe in those modern CSS-in-JS solutions that completely remove the overload caused by naming selectors, can do static-extraction for critical CSS, and uses a utility-class (1 rule per class) based approach to enable significant size savings on large codebases.
Hey, thanks for the reply..
I have worked in multiple enterprise level projects and My colleagues and I never faced any such issues..
But yeah! Thanks for sharing your insights :)
Besides, you have to use some methodology, either you create it yourself or use a ready-made one, such as BEM, going crazy is not good, not to mention diving into the past with CSS-in-JS. Anything *-in-JS is no good, so you can use the same CSS in any other non-React application.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
BEM claims to fix a lot of organisational problems of CSS codebases, which is true, but it also creates tons of new problems which at the end are for the worse. I would be able to go deeper in this topic, but let me just highlight a few points.
BEM has a lot of rules which are not trivial to understand correctly at first sight. It's definitions of blocks/elements are debatable, and that's the reason every person understands BEMs rules a little differently, using it in their own flavor. This creates problems in teams, especially on a bigger scale. I've participated in and seen a lot of reviews the past decade on codebases using BEM arguing about the correct naming, structure, and selectors.
BEM requires deep knowledge of the codebase, otherwise people start reinventing already existing parts. This is true in general to well agrd code, but in BEM's rule-system individual pieces can hide well let's say. I don't know how to express this more clearly :)
BEM needs extra brainload which makes the process of site-building inefficient. It simply blocks the flow.
BEM is kinda immutable. By that I mean that it's hard to refactor. The structure and rules force a "non-flexible frame" around your codebase.
The mess and unreadability of the classes, and the 32 character long selectors at the end it's just the tip of this iceberg.
BEM simply has significant negative impact on productivity, and at the end it's not as maintainable as it claims to be.
Most people usually like the Modifier part of BEM, but that's not new or unique to BEM, only the double dash maybe...
To add something constructive to the table. I believe in those modern CSS-in-JS solutions that completely remove the overload caused by naming selectors, can do static-extraction for critical CSS, and uses a utility-class (1 rule per class) based approach to enable significant size savings on large codebases.
Hey, thanks for the reply..
I have worked in multiple enterprise level projects and My colleagues and I never faced any such issues..
But yeah! Thanks for sharing your insights :)
I prefer BEM a thousand times over CSS-in-JS, it's like going back to the past, messing up all the code. Each one in its place.
Besides, you have to use some methodology, either you create it yourself or use a ready-made one, such as BEM, going crazy is not good, not to mention diving into the past with CSS-in-JS. Anything *-in-JS is no good, so you can use the same CSS in any other non-React application.