menu

styled-components

Visual primitives for the component age. Use the best bits of ES6 and CSS to style your apps without stress!

Channels
Chat
view-forward
# All channels
view-forward
# General
view-forward
# Help
view-forward
# jest
view-forward
# Off Topic
view-forward
# Website
view-forward
Team

BEM + SASS vs Styled Components

February 23, 2018 at 11:08am

BEM + SASS vs Styled Components

February 23, 2018 at 11:08am (Edited 2 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 previous messages

February 23, 2018 at 1:34pm
CSS-in-JS scales much much better than any naming methodology could ever scale.
Imagine working in a team with fifty frontend developers, all of whom work on the same site(s). You might split your CSS into multiple files with Sass, but even then you end up with (what some people lovingly refer to as) append-only stylesheets: you never delete anything from them, because you never know where it might be used, so you can't. That's why they're append-only, all the developers only add to them but never take any CSS away.
like-fill
2
  • reply
  • like
It takes a lot of focused effort to scale a naming methodology. It can surely be done, and any naming methodology is better than none, but nothing scales better than not even worrying about a global namespace.
The best naming methodology is no naming methodology.
  • reply
  • like
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"
  • reply
  • like
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_!
like-fill
3
  • reply
  • like
Deleting a component cannot be done without deleting its styles
  • reply
  • like
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.
  • reply
  • like
Computers are much better at managing namespaces. Why not let them do the work?
like-fill
3
  • reply
  • like
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.
  • reply
  • like
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).
  • reply
  • like
As a reference I want to share Max answer for structuring styled-components: https://stackoverflow.com/questions/42987939/styled-components-organization
  • reply
  • like
you just convinced me with those two thoughts about being afraid to delete styles and managing namespaces 👍
like-fill
2
  • reply
  • like
Ohh I totally forgot about those two posts by ! I'm sure he can answer any question about the switch y'all have
like-fill
1
  • reply
  • like
Hey! 👋 Thanks, Max. I'm just getting started this morning ☕, but I'll read a little more and respond in a bit.
  • reply
  • like
TL;DR: BEM + 💅 is actually a nice pairing.
  • reply
  • like
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.
like-fill
1
  • reply
  • like
So, Max is right. 🏆
like-fill
2
  • reply
  • like
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.
like-fill
1
  • reply
  • like
Yeah, basically, you was using BEM -> switched to SC -> implemented some of BEM concepts in a SC way, amirite?
  • reply
  • like
(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)
  • reply
  • like
I also find that just not having to think so much about creating the perfect classnames is a great byproduct of switching to styled-components
like-fill
1
  • reply
  • like
Well, we started with SC, but we had a lot of duplicate or near-duplicate components, and it wasn't clear where everything went. So we created a BEM-inspired structure for structuring our components.
  • reply
  • like
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.
  • reply
  • like
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.
like-fill
1
  • reply
  • like
Show more messages