React-starter-kit: Replace CSS Modules with Styled Components

[koistya]

https://www.styled-components.com/

[JasonMHasperhoven]

@koistya I'm curious to know from your perspective why this is better than the current CSSModules implementation.

[howardya]

I guess it will make the code a lot cleaner. There will not be a lot of withStyles HOC in almost every page.
We do not need the global insertCss context props too.
SSR style tags can be obtained easily too.

From a different perspectives, any reason why is CSSModules better than styled-components?

[JasonMHasperhoven]

@howardya I'm not particularly for _or_ against it, hence I wanted to know from other people's perspective why they would favour it.

To me the coupling of JS and HTML as React does seem to make sense, but the coupling of CSS and HTML would introduce _a lot_ more code in the same files. From what I understand there's nothing you can do with styled-components that you can't do with CSSModules (even style changes dependent on props can be done). Having said that I am in favor of cleaner code and styled-components does fit Reacts JS first approach and the FP paradigm more.

[hulkish]

@koistya @JasonMHasperhoven I don't want to stir the pot here.. but this is great resource on the topic: https://medium.com/@gajus/stop-using-css-in-javascript-for-web-development-fa32fb873dcc

Not to rain on the styled-components or jss parade...but I personally have a strong stance in opposition of css-in-js based solutions. The article above highlights various reasons as to why. To quote a few reasons in particular:

Lack of separate files means that you cannot cache separately CSS and JavaScript.

All styled components are wrapped in an additional HoC by their nature. Thats an unnecessary performance hit. The same architectural flaw is the reason why I’ve discontinued https://github.com/gajus/react-css-modules (and created https://github.com/gajus/babel-plugin-react-css-modules).

Because of the HoC, if you are rendering server-side, this is going to result it a lot bigger markup document.

I suppose this touches on a larger discussion...but ultimately I think any solution should try best to keep these as absolute priorities;

• loading, parsing, compiling & runtime performance of css & js
• leveraging browser cache as much as possible

If at any point this criteria takes a back seat to asthetics (developer experience, code style etc) - we really need to question whether these are worth it as it is at the expense of the end-user.

[JasonMHasperhoven]

I'd like to chime in here again since I've actually tried it on a small production app now, whereas before I hadn't.

The developer experience seems to be better than CSSModules because of it's abstractions. SSR was quite easy and straight forward to implement, definitely easier than CSSModules. One thing which isn't discussed yet is that having the code in 1 file decreases cognitive load and enforces you to create small components, which is a good thing. Additionally the code seems to become much clearer in the render function. There's a library called polished which has everything you need really. So it's just these 2 libs you need vs a ton of postcss plugins.

As the above linked medium article states it has downsides for the end user. The use of styled-components increases your app's JS size (~50kb if I'm not mistaken) and because of the HoC wrappers it creates a performance hit. In my opinion this isn't too much of an issue, but if you are having lots of traffic whereby every second counts this could be a deal breaker for you.

A summary would be that it introduces a slightly better dev experience for a slightly worse user experience. Now I'm in favor of it 👍

@hulkish Have you actually tried it yourself? I had also read that article before, but it ignores the dev experience part imo.

[hulkish]

@JasonMHasperhoven I have tried it, yes. I guess the argument I'm attempting to make is:

• Gaining developer experience benefits in trade of sacrificing performance benefits of your app at the expense of your users is i(harsh words I suppose) irresponsible.
• I think it's really important to make technology choices which are not based on popularity. Instead, these choices should always be towards the goal of the best possible experience for the users of your application..
• In way, the css-in-js strategies really feel like "1 step forward, 2 steps back". I don't understand how a different code style justifies the negative impact to the end-user experience.
• Regarding the topic of developer experience for styled-components vs css modules; per my experience the differences are quite marginal.

I was originally really interested in the appeal of styled-components. I began using it initially as an experiment by porting a couple of my css-modules based components to use styled-components.

Once I understood the actual output of my application - I have to say...well I was just disappointed, really. The goals of the project seem to solely have a focus on the developer experience. I just think that is a poor way to make decisions in software.

I'd like to emphasize also that I am not suggesting that css-modules is the silver bullet or messiah of solutions. Some notes on this topic I'd like to further point out:

• I know that it has been somewhat of a rocky road for many developers to surpass the learning curve that is introduced with css-modules.
• However, this learning curve is really far more of a webpack learning curve than specific to css-modules.
• In this way, it is my opinion that styled-components and css-modules have trivial differences in complexity, as they both require at least some knowledge of webpack or alike.

Perhaps there is more to styled-components that I have yet to see or use. Yet, the concerns as described above really detour me from digging further into it.

I don't actually use react-starter-kit beyond using it as a test bed for experiments on my local machine. And I may be incorrectly assuming the vision for this project.

I just think that there is a real problem in the web eco system where hype seems to overtake logic.

For example: I've seen several claims (and this can.be said for so many npm packages) of "styled-components better than css-modules". That may very well be true... but a claim such as this demands evidence and the question "better for who?".

Lastly, If the experience with css-modules is really a pain point... I encourage more folks to consider it's planned replacement.

[JasonMHasperhoven]

@hulkish Your arguments are sound and valid, if all you care for is performance... Which can definitely be a concern for some. In a way jQuery would've been "irresponsible" if you follow your logic. It introduced ~100kb to your app and was slower in pretty much all of its functionally compared to plain javascript, mainly for a better dev experience. I know it takes care of some specific browser issues, but that's not why most people choose to opt for it.

I definitely acknowledge that UX is important, but certain tradeoffs are acceptable IMO. I think it's better to have a wholistic approach. In reality you can achieve performance gains in so many different ways which are probably more impactful than optimising HoCs. Just to mention this page is +800kb and I doubt that you find github to be slow. Sometimes we get too caught up in optimisations and don't realise that most people will not really notice or that it's the connection itself which is the main reason why something appears fast or slow.

There seems to be a paradigm going on to couple code together. Here's Evan You (creator of Vue) talking about collocation of Template, Script and Style, which is basically what styled-components introduces to React:
https://youtu.be/wZN_FtZRYC8?t=7m47s

This collocation is one of the selling points of styled-components. To me when I compare CSSModules to styled-components, the latter code just looks more beautiful and neat.

@koistya If you still need a contributor for this, then let me know because I'm willing to take this up. Additionally we could decide to make this (or CSSModules) into a feature, so that we support both philosophy's.

[Jaikant]

I have been trying out emotionjs and I must say working it felt a lot less messier. I liked not having to switch between my css files and js files. I read some performance reports and it seems it gives better performance, not something I have measured myself though.

[Jaikant]

I would like to build support for emotionjs into RSK. @frenzzy @koistya can you please guide me on how to go about it.

[koistya]

@JasonMHasperhoven, @howardya, @hulkish, @Jaikant thanks for sharing your opinion!

FYI, I'm thinking about replacing custom Webpack/Babel configs in RSK with Create React App. With a couple of tweaks it can be used with server-side code as well (see React App SDK). It was already integrated into RSK for Firebase. @Jaikant, will you be able to clone RSK for Firebase and check if it works fine with Emotion? It would be really great if RSK would work flawlessly well with CSS Modules, Styled Components, and Emotion.

[Jaikant]

@koistya thanks I will try that out and report back here!

[Jaikant]

@koistya I did a git clone of RSK for firebase. Installed the emotion npms and it worked 💯!

I then tried styled so components can have styles attached to them, by installing react-emotion. But got the below error while using styled. I tried installing the babel-plugin-emotion and also update the .babelrc but this error remained.

Error: You're trying to use the styled shorthand without babel-plugin-emotion.
Please install and setup babel-plugin-emotion or use the function call syntax(`styled('div')` instead of `styled.div`)
    at Object._get [as get] (/Users/jai/work/guides/landing/react-firebase-starter/node_modules/create-emotion-styled/dist/index.cjs.js:79:15)
    at Object../src/routes/Home/Home.js (/Users/jai/work/guides/landing/react-firebase-starter/build/static/js/home.chunk.js:33:73)
    at __webpack_require__ (/Users/jai/work/guides/landing/react-firebase-starter/build/app.js:645:30)
    at fn (/Users/jai/work/guides/landing/react-firebase-starter/build/app.js:49:20)
    at Object../src/routes/Home/index.js (/Users/jai/work/guides/landing/react-firebase-starter/build/static/js/home.chunk.js:113:64)
    at __webpack_require__ (/Users/jai/work/guides/landing/react-firebase-starter/build/app.js:645:30)
    at fn (/Users/jai/work/guides/landing/react-firebase-starter/build/app.js:49:20)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)

[koistya]

@Jaikant you can try react-app-tools v2.0.0-beta.10 (or, higher) which allows overriding default Babel/Webpack configs. Create override.js file in the root of your project with the following content:

module.exports = {
  babel: config => ({
    ...config,
    plugins: config.plugins.concat(require.resolve('babel-plugin-emotion'))
  })
};

[Jaikant]

@koistya thank you. I will try this out to see if it fixes the issue while using styled!

[ipselon]

@koistya,

I'm thinking about replacing custom Webpack/Babel configs in RSK with Create React App. With a couple of tweaks it can be used with server-side code as well (see React App SDK).

I'm just wondering why you think to migrate RSK configs into CRA. There is a quite good hot reloading configured for the server side in RSK. As far as I understand, using CRA will require to configure
the server separately along with hot reloading. Don't you think that may bring some inconsistency into the RSK?

[piglovesyou]

Personally, I concluded styled-components is not good fit to RSK.

Pros

• Less complexity around insertCss and withStyles
• ~❌We can get rid of withStyles HOCs~
  
  
  
  • This can be solved when isomorphic-style-loader supports useStyles in React Hook style
  
  

Cons

• It is redundant that it forces all children are also styled by styled-components. Otherwise, children are out of local CSS scope (= possibility to be harmed by global CSS) (= Sacrificing DX, it seems)
  
  
  
  • I tried it in Footer.css. The style of the root DOM is good, but subordinate DOMs have to have global classNames.
  
  
  • Styled-components seems more suitable for "reusable components", while projects using RSK will need their own original styles in most cases, I assume. This made me think RSK doesn't need it.
  
  
• ~❌Sacrificing UX in performance~
  
  
  
  • This has to be solved by babel-plugin-styled-components compilation.