[RFC] Migrate to styled-components

[kybarg]

Can we switch to styled-components?

Outdated comparison

It has many advantages against JSS
Here comparison table, and next version is even going to avoid SSR styles re-render!

Features	styled-components	react-jss
No build requirements	✅	✅
Small and lightweight	✅	✅
Supports global CSS	✅	✅
Supports entirety of CSS	✅	✅
Colocated	✅	✅
Isolated	✅	✅
Doesn’t break inline styles	✅	✅
Easy to override	✅	✅
Theming	✅	✅
Server side rendering	✅	✅
No wrapper components	❌	✅
ReactNative support	✅	❌

Legend: ✅ = Yes, ❌ = No, 😕 = Kinda, refer to notes or parentheses

[oliviertassinari]

@kybarg Thanks for opening that issue! The CSS-in-JSS is a moving field, choices we made in the past may no longer be valid as problems and solutions changes.

Why not styled-components in the past?

We have been comparing the different styling solution available before selecting JSS.

We did not elect styled-components for the following reasons:

• Cost of the abstraction. css-in-js-perf-tests is a good resource, styled-components use glamor internally.
  • 126 kb unzipped over 22 kb for JSS
  • Time to first paint is slower. Compare the time to first paint on the equivalent demos of https://github.com/MicheleBertoli/css-in-js, JSS perform 40% better.
• Exposing the className and the CSS deep selector power allow performant implementation. For instance with the <Grid />: [Layout] styling specificity using > disallows easy override via classname #6010.
• No server-side rendering concurrency possible. It's relying on a singleton to collect the styles while JSS instantiate a new instance to collect styles at each request. Steaming is really limited.

Actually, styled-components wasn't even a thing (existing) when @nathanmarks started working on moving away from inline-style.

The comparison table

Supports global CSS

With https://github.com/cssinjs/jss-global you can write stuff like

const styles = {
  '@global body': {
    color: 'green'
  }
}

Easy to override

How is this not easy? Material-UI side we have a predefined injection order table. On user-land, they can use aphrodisiac that implement great aphrodite override API.

No wrapper components

We don't have any wrapper component on Material-UI side. We could have been using withStyles but we don't for performance reason. We expose that Higher-order Component to users to abstract the context implementation.

Theming

We use jss-theme-reactor internally. JSS is exposing a low-level API that makes it possible.

ReactNative support

That's a good point, react-with-styles API is quite interesting. That's something we could be improving!

The future

Going forward, I think that the most promising path is having an API allowing to switch the style implementation. That would bring us two benefits:

• Material-UI is less coupled to any styling solution
• Users using styled-components/aphrodite/... on their side can save the JSS overhead used internally.

react-toolbox is following that path. My only concern would be with the overhead it's adding. I mean, does it worth it?

I'm adding @kof and @mxstbr to the loop.

[oliviertassinari]

@kybarg Actually, I'm not sure to fully understand what you are suggesting.
We are not using react-jss as your question suggest.

When you say we, are you talking about users or Material-UI?

[kof]

My points are:

• styled-components is a much higher level library than the JSS core, you can for sure use it in your application layer.
• The comparison table above is about react-jss, not JSS core and is a subjective opinion of Max. It is partially not true and partially just a look from some specific perspective which we don't see from the table.
• We are working on dynamic rules rendering for more efficient dynamic styling, jss-theme-reactor does the job right now already, its just a matter of an optimization, which is probably not very relevant for MUI.
• What MUI uses internally should be totally out of concern for the end user. Everything a user needs to do should be possible without even knowing what MUI is internally using or at least its more or less regular cssinjs syntax for theming.
• We need to get use cases MUI doesn't support right now and solve them. I am always happy to help the integration process and available on gitter.
• What is react-native support anyways? Isn't it just a subset of the web platform? If so it should just work, otherwise let me know what JSS needs to be able to do to support react-native, here is the issue.

[mxstbr]

That table is indeed very subjective and based on my own experience. FWIW, styled-components works with any third party component library:

import { Button } from 'material-ui'

const MyButton = styled(Button)`
  // Only these styles will be overridden
  background: red;
`

This works as long as the components attach the className prop internally to some DOM node:

const MaterialUIButton = (props) => {
  /* ... */
  // As long as props.className is attached, the above usage will work
  return <button className={`bla ${props.className}`} />
}

---

What is react-native support anyways? Isn't it just a subset of the web platform?

Nope, it's not quite that easy 😉 Adding support to JSS shouldn't be hard though, as all you have to do is pass the style object through to StyleSheet.create(). This requires a bit more effort from the styled-components side to make CSS strings work.

---

I've been talking to @javivelasco for a while now and love where he's going with react-toolbox. His implementation is amazing, and I'd love to see all third party component libraries adopt it. Pinging him so he can chime in with his ideas here!

---

No server-side rendering concurrency possible. It's relying on a singleton to collect the styles while JSS instantiate a new instance to collect styles at each request. Steaming is really limited.

Totally unrelated, mind commenting in this issue with your ideas for an API that would allow this to be the case? We haven't decided what we're going to do, so your input would very much be appreciated.

[rainice]

Hi, I inquired about this in gitter. Just to get the views of others, I will post it here as well:

I know material-ui next is heavily invested in a custom jss solution.
Does anyone discovered any serious advantage of using jss over styled-components?

While jss is good as it enables several patterns like decorators (injectstyles) and plugins, I think styled-components straightforward approach is much cleaner as there is no need for decorators, custom setup and plugins cause it doesn't need to.

In styled-comp every component is already styled so no need to pass styles. and you pass props that can evaluated to produce a different style
no setup (createJss)
no plugins (prefix)
no JSON DSL

[kof]

Somebody has to lock this thread.

@rainice jss doesn't have decorators, a HOC is an implementation detail of react-jss and is not used here.

[javivelasco]

Why should this be locked? It's a sane discussion IMO

[kof]

Because end user based content here (not lib maintainers) is highly superficial and this is understandable because they didn't read a single line of code behind of what they use.

[mbrookes]

Since the choice of styling solution has been discussed at length, the rational behind the decision documented, and development work towards the next major release is ongoing, this is not a useful issue, so I am going to close it.

Hopefully people are mature enough to not continue posting to a closed thread, but we can lock it if the need arises.

[oliviertassinari]

I wish we could have moved forward that thread with a less coupled styling solution!
However, I think that our priority, for now, should be around finishing the migration/overall improvement of the components.