Vanya Yani
2 min readApr 29, 2017

--

First of all, what are we comparing here? Styled-components to raw CSS or styled-components to some kind of CSS processor? Raw CSS and CSS processor isn’t the same. The implied difference here I think is run-time vs compile-time. It’s true that styles in styled-components are currently processed in the runtime. But there’s nothing that prevents it to be precompiled (given we don’t have non-const template substitutions). Provided adequate examples, styled-components wins.

#1 Doesn’t even sound like a myth to me. Styled-components does solve the global namespace problem. Doesn’t it?

#2 provides inadequate example

#3 is laughable. Why do you need to know which tag is used? To me all tags are all the same with only difference the default styling. If you don’t need a special styling, why create a dedicated component? An adequate example would be comparing <ul className=”fancy-list”> to <FancyList>. If you want all the lists to be the same, just use the global styling like you would do now. If you want specific list styling you’d have to name it. And naming it using tag name to me is a more nice way. Otherwise why all these fancy HTML5 semantic markup tags were invented?

#4 inadequate. It is impossibe to extend classes in CSS without some kind of preprocessor

#5 implies that css overriding rules are easy to grasp. Readability can be improved using styled-props

#6 tells you that forcing people to create a separate file even for a single rule is a good thing

Regarding #7 I think tooling will improve eventually. For example, I don’t see why it’s hard to append a component name to the className. I think there should be some plugin already

#8 has a lot of mixup. I don’t see how having a separate file improves performance. Parsing is single-threaded. For what I know, having a separate file worsens network loading performance as there’s a connection latency.

Never heard of #9, nothing to say.

--

--