Demystifying Styled Components | Hacker News Reader

Demystifying Styled Components

joshwcomeau.com

28 pointsenigmatic0210 comments

Fantastic write up! Very clear approach to breaking it down into understandable (simplified) chunks and piecing them together. Cleared up a few things I hadn’t thought too deeply about with styled-components, and I didn’t know until now you could used CSS variables with it like that. Thanks!

Big fan of styled-components here. Feels like just the right level of abstraction over styles when working with React for me.

It's a slick API, but it's worth noting that they come with significant runtime overhead. It may not matter for you depending on the type of app, but they create multiple times as many React component instances in memory and they force some extra work to be done on every render. Using them also means your CSS is blocked by your JS on initial load, instead of being a separate file that can be loaded and rendered in parallel.

> Using them also means your CSS is blocked by your JS on initial load, instead of being a separate file that can be loaded and rendered in parallel.

styled-components supports SSR (server-side rendering). Each page's HTML response from the server will contain a <style> tag which contains only the styles that were generated during the React render for the page.

https://styled-components.com/docs/advanced#server-side-rend...

And if you're not using SSR, then it probably won't matter that your CSS is blocked by your JS, since your HTML will also be blocked by your JS!

I also loved a similar article by my colleague.

He reverse engineered the api implementing the basic functionality, https://makersden.io/blog/reverse-engineering-styled-compone...

Speaking as a grumpy and primarily backend developer, how is this fundamentally any different from old-fashioned <FONT> tags?

The context has changed: for documents you’d want style separated from structure. With apps, some people strive for isolated components instead.

>Instead of eagerly generating CSS classes whenever a styled component is defined, we wait until the component is rendered before injecting those styles into the page.

The design department comes up with a fancy new "Leave Feedback" dialog box. Management declares that all products must include this new dialog box to maintain brand cohesion. The component is shared across teams.

If this were to happen with just <font> tags, you'd be pushing a lot of extra unused stuff to the browser every time management wants a new dialog box.

I have to ask: could someone please provide a good reason to prefer styled-components to emotion? Emotion supports a superset of s-c's features with comparable (or superior) performance.

What does Emotion have that Styled Components doesn't?

In a word: flexibility. It supports an identical API to SC, plus: `sx` prop; 0-config SSR (albeit w caveats); a history of superior performance... that's off the top of my head. Also [and with disclaimer that I'm not a huge fan of Material-UI], MUI's maintainers examined their options for their big v5 rewrite, and chose Emotion as the foundational styling engine of choice, aligning with other modern libs like Chakra and theme-ui.

Reply on news.ycombinator.com