Login/Register
Styled-Components vs SASS (SCSS) or LESS [closed]
Asked Answered
cssreactjssassstyled-componentsreflow
E

2

50

I came across a ReactJS Boilerplate which had good reps and is community driven. Styling section emphasized more on styled component CSS but never stopped from switching to conventional CSS styling methodologies. Although this pulled my interests what makes the Styled-Component CSS stand out and why need to adopt it.

My Understanding of Styled component CSS:

  1. Component Driven idealogy. Your CSS also is now a component. - This is pretty cool!
  2. Load what you need and when you needed, kinda lazy CSS
  3. Theme provider, skins, modularity and dynamic - This can be achieved by other libs too
  4. Server side construction of your component DOM and its style.

My questions are:

  1. Browsers are evolved to parse CSS separately from Javascript parsing, why are we trying to deviate from this and fit all in Javascript?

  2. Styled-component CSS ships its javascript library to the client end, which actually parses styles at the runtime and put inside <style /> tag when each component loads on demand. This means extra load and logic eventually contributing to execution cycles on browser. Why need this?

    (By the above question i mean for every component loaded, corresponding CSS is computed, created and inserted in head via style tag / Multiple style tags - Re-inventing CSS interpreters)

  3. Does continuous computed style text banging via <style /> in the head tag cause browser reflow/repaint ?

  4. What are the performance advantages i get from this?

  5. With add-on libraries / options like Post-CSS & SCSS classname hashing for dynamic classnames which pretty much solves the problem that everyone states. Why SC still ?

Community, please clear the air for me or correct me if i am wrong.

Some good articles that talks about repaint or DOM re-flow how it is performance expensive for browser when CSS styles are modified.

Expansion answered 14/10, 2017 at 16:52 Comment(2)
It's good to add that in styled components CSS loses its C - Cascading – Module
@MatthewBarbara - it can be viewed as gain, as the point is to isolate components' stlyes from each-other. internally, per-component, it is still plain CSS (with cascading) – Bash
B
30

I've been using SCSS (SASS) for many years now, and also have been using Styled-Components for a few projects, some large.

I love both, and Styled-Components feels, for me, like a step forward:

Styled-Components - Pros

  1. Total styling isolation; prevents potential bugs when working in teams, when one team member can never override a style of another. (unless multiple places share the same styled component)
  2. Remove the need to manually handle class names as they get auto-generated (name-picking components is somewhat easier IMHO than class names)

  3. I've found it easier to work with CSS within the JSX file itself (Opposing my judgment for many years before)

  4. Easily use javascript variables within styles (eliminate the need for 2-sets of theme variable)

Styled-Components - Cons

  1. Each style component is yet another wrapper function, and many styled-components means more functions, which means less efficient since all that code needs to be "compiled" and so on.
  2. Biggest drawback: changes to styles require bundle re-compilation and the app's state might reset.

The cons can be only viewed as such on some scenarios but not necessarily all.

SCSS/LESS pros can be viewed as opposite to the cons listed above, while having some more cons such as mixings and faster development when working with variables (IMHO). it can get "ugly" defining a local selector variable:

Compare these simplified examples:

SCSS example:

.icon{
  $size: '20px';
  width: $size;
  height: $size;
  margin-left: $size/2;
}

Styled-Components local scope example:

const Icon = styled.i(props => {
  const size = 20; // easier to use Number instead of String for calculations 
  return `
    width: ${size}px;
    height: ${size}px;
    margin-left: ${size/2}px;
`});

Obviously the variable could have been defined outside of the Icon styled wrapper and then internally used, but that won't make it isolated, because styled-component CSS might be composed of sub-components styled and look more like CSS:

const Header = styled.header`
   > ul{
     ...
   }

   li{
     ...
   }

   img{...}

   navigation{...}
`

Not always it is desirable to extract each individual HTML element to its own styled component. it is done mostly for components that are or might be repeated across the app.

Regarding SASS mixings, they can be converted to javascript functions, so there's not much advantage to SASS here.

Overall, working with Styled-Components is fun & easy, but has a side-effect of a tighter coupling between the styles and the framework/component and it obviously has some performance penalty (nothing that will actually slow you down, but still).

Bash answered 16/5, 2019 at 13:34 Comment(1)
I've written more about advanced variables with Styled-Components in this post – Bash
D
11

Browsers are evolved to parse CSS separately from Javascript parsing, why are we trying to deviate from this and fit all in Javascript?

When you mix both Javascript and HTML (namely JSX) and then also CSS (JSS or another), you make your component a solid module that fits into a single file. You don't need to keep styles in a separate file anymore.

Then, the functional magic happens: as JSX is a pure function of raw data that returns "HTML" (not really), the same way CSS-in-JS is a pure function or raw data that returns "CSS" (also not really). From this point, I think it's worth reading about JSX and also about CSS-in-JS.

Styled-component CSS ships its javascript library to the client end, which actually parses styles at the runtime and put inside <style /> tag when each component loads on demand. This means extra load and logic eventually contributing to execution cycles on browser.

Not only on the run-time. Because CSS-in-JSS is just a function of data that returns CSS, you can use it on any platform. Take Node, add SSR, and you have style elements delivered to the browser in response body, therefore parsed just like it would happen in the original case of getting CSS delivered.

Why need this?

Because it is convenient in development, just like React or Redux, just like jQuery, and just like any other lib, it comes at network load and browser performance cost.

You take a library because it solves a problem. If there seems to be no problem, why use library at all, right?

Does continuous computed style text banging via <style /> in the head tag cause browser reflow/repaint ?

There are so many things that force reflow.

Browsers are smart. They don't even make an attempt to repaint if the styles haven't changed. Which doesn't mean that they don't calculate the difference, which costs CPU time.

There's a good intro into the scope and complexity of style (re)calculations, it's really worth reading to understand the subject deeper.

Diarthrosis answered 14/10, 2017 at 20:9 Comment(7)
imo jsx went hand in hand with virtual DOM which is a performance win. Styled-component i really liked the part its Javascript driven and write inside a js, CSS composing at dev time became cool, but i cant trade off my end performance. Continuous style bang causes unwanted reflow. Browsers parse the static CSS tree and you dont have to worry about the rest at runtime, just deal with JS for models, logics and JSX for my visual data representation on screen. Styling those visual elements at runtime is imo unwanted until and unless it is needed. – Expansion
Because it's convenient. Because developers and developer time costs more than optimisation. Because if it continues to stick, the performance bottlenecks will undoubtedly be fixed. Because browsers are only getting faster and smarter. Because in the future we will all be only loading programs over the wire and we'll be exploring software ecosystems, not websites. Because global styling rules you need to override to be different suck. I don't know. I just don't know. But as @Fleischpflanzerl said, if the library doesn't solve a problem for you, don't use it. – Kristiankristiansand
@brokenthorn I am not against any library, but my point is this library worth using than SASS OR LESS which targets the same problem statement as Styled Components – Expansion
No, they do not. SASS/LESS aim to fix CSS which is still... CSS. SC are encapsulated pieces of HTML and CSS. CSS doesn't cascade anymore and you don't need a whole CSS framework either. – Kristiankristiansand
@brokenthorn then i guess you need to read this motivation post fully (styled-components.com/docs/basics#motivation) post which clearly say styled-components is the result of wondering how we could enhance CSS for styling React component systems in the start of the line. Ofcourse they are targeting enhancement of CSS – Expansion
@Nirus no, they are targeting React and CSS combined. They aim to fix React component styling. It needs to be encapsulated and distributable. SC fixes that. – Kristiankristiansand
@brokenthorn React is the common denominator for all my conversation and question posted in context with the asked question. I am not excluding react anywhere. If is say SASS or LESS with SC. Its understood that React with SASS or React with LESS in comparison with React with SC. Also read facebook.github.io/create-react-app/docs/… which is SASS with react – Expansion

© 2022 - 2024 — McMap. All rights reserved.