Show previous messages
BEM + SASS vs Styled ComponentsFebruary 23, 2018 at 11:08am (Edited 3 years ago)
Do we have anyone switched from one another OR thinks either one is better suit his / her needs?
We'd love to hear your thoughts and reasons!
Show more messages
February 23, 2018 at 1:36pm
February 23, 2018 at 1:36pm
YMMV and this all depends on your team and your teams experience, but I don't think it makes sense to choose BEM over any CSS-in-JS solution because "BEM scales better"
Are you ever afraid to delete styles when using styled-components? No, why should you, they're only used in that component _and you know it_!
Deleting a component cannot be done without deleting its styles
On top of that, you don't have to constantly be on the lookout for duplicate classes or anything like that. You can focus on the code, rather than having to worry about managing global namespace.
Computers are much better at managing namespaces. Why not let them do the work?
BEM is not only naming convention for Blocks btw. You can use my bemto-components with styled-components (and its the best way to use them), and get easy ways to do: batch modification based on a prop (especially if its only visual ones), really easy way to declare and use “elements”, which would be coupled with the initial styled component, would have classnames inherited from its name etc.
Its totally possible to use styled-components AND bem together, to mutual benefits.
Thanks a ton for putting it together, something I couldn't say clearly. Mostly because I did BEM 2 years ago on relatively big React project and after that project I found styled-components and chose it without hesitate.
So I clearly love SC and not just emotional but practically, I'm so productive when I have CSS be writing with the same concepts I'm using throughout the app (components, modules, JS interpolations, etc).
you just convinced me with those two thoughts about being afraid to delete styles and managing namespaces 👍
A team went from BEM to Styled Components:
And why they use it:
Ohh I totally forgot about those two posts by ! I'm sure he can answer any question about the switch y'all have
Hey! 👋 Thanks, Max. I'm just getting started this morning ☕, but I'll read a little more and respond in a bit.
TL;DR: BEM + 💅 is actually a nice pairing.
I've been on teams where BEM is a successful pattern, and on teams where styled-components is successful. The difference being that the team using BEM was smaller with fairly strong CSS skills and working on smaller applications. BEM is still a useful pattern for providing structure and preventing unintentional style collisions. But the main problem is that at some point (what some people call "at scale") maintaining consistency becomes really time consuming.
So, Max is right. 🏆
And to clarify those articles ^^ aren't about switching from BEM to SC, they're about how we were using SC, but still wanted some structure to help us organize and reuse components. That's something that BEM does really well, so we applied the pattern to our structure and it's been really helpful for our team.
Yeah, basically, you was using BEM -> switched to SC -> implemented some of BEM concepts in a SC way, amirite?
(By the way, just to clarify, I just wanted to answer this for some of my friends, and when I said about scaling and etc they weren't my words 😅, I'm happy with SC with some structuring + theme)
We’ve structured our components in folders and subfolders (i.e. /Forms/Checkbox, /Layout/Flag, etc) to help with keeping everything organized. S-C meshes really well with React because they’re both centered around the idea of the encapsulated component.
BEM is a really great system when working with systems that don’t enforce component-based structures. Also I feel that the React-way of separating concerns with styled-components works much better than what you can achieve with separate files.
Naming is both good and bad. A lot of times thinking about how to name something will lead you to define its purpose and structure. That usually leads to writing more thoughtful code. But at the same time, naming is hard and error-prone. One of the superpowers SC (and CSS in JS) gives us is that we can let the library handle the cognitive load (which I think is what you're referring to, ). But naming is still a valuable practice, IMO.
yeah, I usually like to qualify "at scale" when I use it. A lot of people think about performance or lines of code when they use that term. For whether or not to use SC I usually ask someone, "Is the cost of maintaining your current CSS pattern hindering your ability to provide a consistent application and ship code?" If so, CSS-in-JS may be for you.
But when your team hits that point could be different than another team. As Max said, your mileage may vary.