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 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 previous messages

February 23, 2018 at 1:48pm
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
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.
  • reply
  • like
Absolutely! It’s worth getting right, especially at the component level. But with BEM you get _so much naming_. The Blocks/Components are one thing, but then you also have your Elements and Modifiers which you also have to think a lot about. With styled-components any bad naming of sub-elements is confined to one place, and not spread throughout your entire app
  • reply
  • like
yeah, great point. 😀
like-fill
1
  • reply
  • like
I like how I can link to this thread from now on. Real people used both in real projects.
  • reply
  • like
I actually used BEM + PostCSS 2 years ago on a relatively medium to large React project and it wasn't a total disaster at the development time (It shutdown, so I can't say about maintaining haha) but I was getting nervous for structuring, refactoring, separating things, and the worst thing, I didn't like the separation of CSS and JS which lead to not so easy refactor/reusability in different project.
  • reply
  • like

June 18, 2018 at 9:39pm
using BEM + SCSS in a monolith front end and about to swap everything over, here is some stuff iv'e noticed.
styled components offers no way to extend styles on JSX therefore elements passed through to render props that clone elements and append styling, now have to append styling in the parent.
styled components offers no replacement and there seems to be none out there for SCSS scale-color function and others.
styled components opens your projects up to potentially dangerous coding practices simply because you have 10000000 times more power with what you can do and in React its generally considered good practice to follow the "principle of least power".
styled components best practices are still being figured out where-as scss has been battle-tested for alot longer and best practices are fairly well known.
styled components adds cognitive overhead and abstraction to your project I.E team members coming in will now have to learn styled components API and syntax as apposed to just scss which is pretty much just css which every good front-end should know.
Time for BEM
BEM in production is troublesome because the class names can't be minified easily because modifiers are based on props.
I.E button button--primary the "primary" string there is coming from props at run-time so you can't minify unless you provide a run-time mapping.
BEM in a component model has actually worked insanely well for us because the root style always shares a name with a uniquely named component.
I.E
.filter-builder {
&--active {}
&__dropown {}
}
BEM has problems sharing "animations" because you can't define keyframe variables that compile to nothing like other SCSS variables that means everytime you want a opacity 0 -> 1 animation you have to write it from scratch in every components scss file. We have a animation heavy project so this was one of the aluring factors of styled-components is that now we can define shareable animations.
BEM has problems with specificity when you have to calculate a style like "left" or "top" or something with maths that style now has to become an inline-style with javascript however styled-components allows you to calculate styles with math's and inject them with class-level specificity.
  • reply
  • like
Thanks for sharing this. Can you explain what you mean by: "styled components opens your projects up to potentially dangerous coding practices simply because you have 10000000 times more power with what you can do and in React its generally considered good practice to follow the "principle of least power"."
  • reply
  • like

June 20, 2018 at 5:48pm
Can’t really see the point in using BEM syntax with SC since the whole point of SC is to step away from having to name our classes based on how we want to style elements
like-fill
2
  • reply
  • like