It's been a while since I post something here (Really busy, sorry!) and I will start to do it again with a polemic opinion. First, it's important to say that this is completely an opinion and I'm not trying to say "Don't use it!!", but creating a space to discuss some things I do not like about StyledComponents and why I don't use it.
- Not a natural syntax:
This is probably the main reason and I mean, it's weird...There is no natural syntax about
const Wrapper = styled.div`
width: 30px;
`
What the heck is that string template after the div?! (I know what it is, but come on). It's used to do function callings, method callings, prop passing, but it's weird to get used to tagged template literals for CSS at least.
- There's no clear convention to use it:
If you see this:
export const MyComponent = () => (
<Button />
)
It's <Button /> a component or a Styled-Component? Can be both and we have to search for it and, depending on how big your project is, can be a pain in the a$$.
Some code editors (sometimes VsCode does this) even have problems going to the code line when you cmd + click the Styled-Components making it a little awkward to track.
Sometimes even it's exported from a "General" style file and that makes it even harder to know what you have to do or fix.
Some projects use:
const StyledWrapper = styled.div``
to differentiate between a React Component and a Styled-Component, but there's not a real convention.
- You can do theming without it:
You can easily build a ThemeProvider using React Context API that could manage the theming for the whole app and can be accessed anywhere you want. You can even build a simple useTheme() custom hook to make it more descriptive and can manage a lot of things without installing another dependency on your project.
Again, I'm not saying that Styled-Components are bad or that the creators are bad people or something, this is just my personal opinion based on projects that I've been working with.
Do you have a different opinion? Do you think just like me? Do you like to add something to the post? Do it in the comments below!
I do this completely non-profit, but if you want to help me you can go here and buy me a coffee ;)
Top comments (13)
CSS in JS doesn't make sense, so there's that. My reasons for that include that CSS is a more declarative language than JS. We all agree declarative is good, because we agree React is good because it enables writing more declarative JS. So clearly a more declarative approach is better than a less declarative approach when it meets the purpose, which CSS does. It meets the purpose because it's a domain specific language for presentation and styling. And we all agree DSLs are good, because we agree React is good because it helps us implement DSLs for the apps we build. So clearly a DSL is better than a general purpose language when it meets the purpose, which CSS does. CSS is also better than JS for its purpose because of how browser engines deal with each language due to the clarity of their domain specific purpose. JS can be multi threaded now, but it always starts in and is orchestrated from the single main UI thread. When JS orchestrates everything, performance is bottlenecked on JS parsing, and execution in a single thread, which is slower than CSS. CSS in JS is re-implementing the browser engine in a slower language in the single UI thread users get to provide their interactive functionality.
And what if I told you that SC actually generates regular CSS stylesheets? Because it does.
And yes, JS is single threaded, but if it can run the most popular websites on the internet, I guess it's good enough.
So no, CSS-in-JS is not "re-implementing the browser engine in a slower language" any more than React is "re-implementing the browser engine [html rendering] in a slower language".
A browser engine is not just HTML, that's kind of the point.
It's not good enough. Even if it were sometimes, it's not all the time, and we'd be able to improve on it someday. But it's really not. Where have you been the last decade as JS dramatically bloated the network transport size of web UIs and spiked their startup and runtime CPU and memory requirements just as mobile devices were becoming a norm?
Oh, you mean it works on your machine? I bet it does! If it didn't, would you keep using it? Yeah. Neither will end users. And it doesn't work on their machines.
Why so many application engineers I encounter are stubbornly defensive about this subject despite the fact that (a) this is measurable and significant research and evidence is freely available (b) engineers who architect and implement web browsers and their underlying engines are among the ones who have been telling you this for years. And not because they are killjoys who want us all to fail. What kind of reasoning is, "everyone else does it so it must be fine!" Give me that and a quarter and I'll have exactly 25 cents.
Why not? The DOM has native methods for generating styles programmatically and inserting them into a document. It's not a new concept, even though it's been popularized and made easier by JS frameworks.
I highly recommend styled-jsx—it's basically just CSS.
Everything I said as well as several other things I haven't. Any solution to which what I said does not apply (such as shipping CSS that is not in JS or writing CSS that is not in JS or both) is categorically not what I am referring to. How much one considers writing a semi-sorta-vanilla CSS/JS hybrid embedded in JS, composed as special React components wrap or hooks control rather than as standard CSS composes onto nodes, and distributed as runtime-compatible CSS only after passing it through a stack of tools as "CSS" or as "CSS in JS" I cannot dictate.
PS: That particular approach is certainly one of the better in several ways. It's not as if I don't use CSS in JS sometimes. That's why I have an opinion on it.
I can't agarre more...the performance is something that decrease using css in js
I've been using styled components for roughly 3 years now (on-and-off) for work, and I can describe my relationship with it as a love-hate one. It does take some time to learn how to benefit from it, but I think the pros outweigh the cons, although I would definitely understand why some people would be deterred by it.
Regarding your first bullet - with proper tooling (which exists for both VSCode and WebStorm, and I'm sure others have it as well), it feels damn near close to writing regular CSS. You get the same auto completion, same syntax highlighting, and you can't feel the difference.
For your second bullet - why does it matter if a component is SC or not? Do you care if a component you use is a functional component or a class component? React makes it very easy to thread all those kinds together. You can create a Card component, and whether it's an SC or just a regular component you would use it exactly the same. If you ask me, that's a plus.
And regarding you third bullet - of course. I don't think anyone has ever pitched SC as a "theming engine". You can use SC for theming, same as you can with CSS Variables, or any other method. It's another tool in your belt.
I do think that SC has a lot of merits, but it's definitely not a hill I'd choose to die on.
the style passed into a styled component is just a parameter passed into a method --
buttonin this case -- so you could doconst StyledWrapper = styled.button('')if you don't like
const StyledWrapper = styled.button''.Maybe what you can do is
As the documentation says:
dev-to-uploads.s3.amazonaws.com/up...
But, still not a good way to do it and again, unnatural syntax. Also, even typescript is giving me an error because it's not a string that's expecting but a
TemplateStringArraysand when I try to do it always gives me an Ts errorAnd also it can be import like
import * as S from ./your-styled-component-file.And use:
But, that's a compound component pattern...not a styled-component pattern
Yes SCSS and Css modules, makes much more sense, you look to a component code and you dont know what HTML elements you have it, is horrible
Can't agree more, but somehow styled component in vue still make sense for me tho