These two technologies unfortunately do not play very nicely together[1], so I'm proposing that we pick one or the other to provide the best possible user experience. The ugliest part of the starter kit right now is the CSS configuration, where we support CSS, Sass, and a configuration-hell nightmare of dynamic CSS module application.
Personally, I think if we use CSS modules with PostCSS there is no need to use Sass, and this direction is a bit more inline with component-focused styling currently popular in the FE world. On the other hand, Sass is awesome and most people are familiar with it. Perhaps we could enable Sass support _only_ if CSS modules are disabled, and document the fact that there are known issues/difficulties with merging the two.
Thoughts?
I would prefer Sass, however that is probably just the web designer/old school grunt user in me talking. What are the big features of Sass that we would lose if we switched to just PostCSS?
Also I have not looked much at the webpack configuration for CSS but is there not a straightforward way to do SASS > Autoprefixer > minify?
@marshallford I will address your initial questions tomorrow when I have more time, but as for the latter: that is the basic setup we have right now (sass -> autoprefixer -> minification), but it's a bit daunting because we have to support the ability for the user to selectively enable/disable CSS modules, which tbh I'm not sure anybody uses anyways. Basically, I'd just like a simple setup where we say "this is how the starter kit works, if you wish to do X, Y, or Z you need to do it yourself."
I'm definitely a fan of CSS Modules because I never really liked the verbosity of systems like BEM. It's also been useful for a UI kit I'm building to avoid name collisions with other peoples code. I know react-tools and potentially other third party UI kits will require CSS modules to use but I also see your point in trying to reduce cruft for things that aren't used by the majority.
Extracting it into a recipe that is referenced in the README might be a good solution but since it is somewhat complicated the way it's currently implemented one concern I'd have is people filing more issues saying they can't get it set up properly etc. My 2 cents :)
@SpencerCDixon do you use CSS modules with Sass? That's the crux of it all; I'd be happy to keep CSS modules for just .css files, but there are some gotchas with Sass that quite honestly I don't fully understand or enjoy debugging. And, to the initial point, I'm not sure how necessary Sass is with CSS modules. It's nice, but doesn't seem like either a requirement or even something that's prominent in the community AFAICT.
Though I guess in the current setup _we_ could just demo with .css files and warn people of some of the issues with using CSS modules with Sass, but it's there if they choose to accept the risks.
Yeah I generally avoid using Sass with CSS modules. Tbh _occassionally_ I do just for convenience. (like simple nested selectors one level deep) Fortunately I haven't had to deal with any super frustrating debugging issues but could empathize how that could be a problem/frustrating for beginners to the kit.
I'm not sure how necessary Sass is with CSS modules. It's nice, but doesn't seem like either a requirement or even something that's prominent in the community AFAICT.
Like you, I haven't really seen anyone using LESS/Sass in combination with CSS modules and I also did a little research into how people DO do that since I'm inheriting a bunch of LESS that needs to play nice with my CSS modules. My conclusion was to import LESS for variables and everything else use CSS modules but I wasn't very happy with that conclusion.
At the end of the day I could really go either way with removing or keeping as long as it's documented how to set them up. Seems like there is still too much uncertainty as to best practices with CSS in React ecosystem.
With the redesign into the fractal system it appears to me there is a drive for better separation of concerns and being able to package almost mini apps inside a repo -- I do think CSS modules supports that philosophy.
Two questions regarding CSS modules.
Do CSS modules support nested selectors?
One of the benefits of CSS modules is that you don't have to nest that much.
How does compiling to a CSS file work if modules are injected in components with jsx? IMO bundling CSS into JS is not a great practice, although if someone disables JavaScript a SPA is not going to look right anyway...
It's probably best to extract it into a separate CSS file when building.
I would say Sass. The css modules approche might be a good idea, but it has some problem with the current ecosystem. I noticed some critical issues related to css module, like #525 and #621, and they have not been solved for a while.
I would suggest that we go for sass for the moment, and keep a branch with css module for further test.
I'm using both Sass and CSS modules. The only issue that I had was having my Sass variables (and other includes) being accessible from anywhere. Instead of requiring my Sass includes each time, I wrote a small Webpack loader that automatically appends a specific include file to each Sass file being imported into JS. So I have most of the benefits of Sass (mixins, shared variables etc..) while using CSS modules.
@ethanve Can you share that plugin? It sounds good.
I don't know about you all, but over the last couple years I have begun to rely on a lot of the features of Sass, in particular the nesting and declaring selectors. CSS modules seems to have its benefits in hooking into components more directly but I find it fairly easy to write modular CSS with Sass as well. Just split your SASS into smaller files and name your container classes appropriately.
name your container classes appropriately
This is the part I always had problems with. There are lots of naming methodologies, which means there is no good solution, only workarounds. CSS modules finally solve this problem. I can write tiny classes like .button or .label knowing that they will not collide with other classes. Here are some examples so you can see without having to try them out. They might not be for everyone, but they solved the most annoying problem for me.
Concerning Sass, I'm mostly using the nesting feature, which is really uncommon when using CSS modules. I'm planning to drop Sass and use stuff from cssnext instead, like custom properties.
@wedranb It's super bare bones, but here you go. https://gist.github.com/ethanve/598b614f2d0f1b8530c27757cdc08b21
@ethanve how do you use that loader. I am not really familiar with webpack and loaders.
I'm definitely for PostCSS. You can use PreCSS module for Sass like functionality.
Switching off Sass and adding PostCSS was first thing we did after starting new project with this starter kit.
In my personal, prefer like to use CSS Modules. Hehe. With BEM. We can do more
Have to give my vote to CSS Modules.
Another vote for CSS modules.
Anyone have experience with react-css-modules? Looks like it can support any preprocessor, easily supports global CSS frameworks and is only opinionated in favor of React. From their README:
Using react-css-modules:
- You are not forced to use the camelCase naming convention.
- You do not need to refer to the styles object every time you use a CSS Module.
- There is clear distinction between global CSS and CSS Modules, e.g.
<div className='global-css' styleName='local-module'></div>
I like CSS modules because it's easier to modularize (IE I don't need to think about modularization if you follow simple directions).
Doesn't CSSNext provide some of the benefits of SASS (Nesting, automatic vendor prefixes, variables)?
I would be absolutely fine removing Sass if CSSNext supports the big features of Sass.
What about people who use some sort of sass framework e.g. foundation or bootstrap. How would that work without sass in the mix?
My knowledge of css modules is very sparse.
Another vote for CSS modules. What does Sass do that PostCSS can't do? If you wanted a Sassy clone, couldn't you do that with PostCSS/PreCSS?
In regards to @davezuko's question
we have to support the ability for the user to selectively enable/disable CSS modules, which tbh I'm not sure anybody uses anyways
I think the ability is needed because it seems to be the only way to work around the @font-face issue with Font Awesome, Material UI, etc. inside CSS Module global scope (see #670)
I like the idea of going all-in on CSS Modules, but with a single supported built-in escape hatch for cases like the above.
I'm further down the line and seeing where Sass and CSS Modules seem to clash. I am trying to put my colors in a colors.scss file to be DRY. But when I compose Sass code into a module, the Sass vars pass through as plain text. Tried messing with the build to force Sass to process the files but couldn't get anywhere. Anyone else run into an issue like this?
.link {
composes: grayText from "styles/typography.scss";
/* … */
}
/* typography.scss */
.grayText {
color: $grayText;
}
In the browser, it looks like I'm trying to set the color to $grayText, not #8d8d8d.
My vote is for SASS. In my case, designers make a static version of the app with examples/pages/layouts/etc. They use SASS, along with some CSS/SASS framework like Foundation or Bourbon. How do CSS Modules deal with frameworks like Foundation (or others)? Do you not use these types of frameworks? Do you style your sites/app yourselves?
I just drop their SASS files in a styles directory and don't deal with styling. I _do not_ separate out CSS/SASS/? into their /fractal/ components for a couple of reasons:
I have the same concerns as @rkoberg.
CSSModules seems like cool technology, but using a CSS framework alongside seems a bit quirky.
First thing I do when I start a project using this starter-kit is drop the SASS stuff. CSS modules with PostCSS all the way. :)
I'm currently using both;
For global styles using Bootstrap and Fontawesome I use a slightly modified version of the method here (https://github.com/davezuko/react-redux-starter-kit/issues/474#issuecomment-186809885)
Then for the css-modules side I use a webpack loader (https://github.com/shakacode/sass-resources-loader) to include the bootstrap and my own variables and mixins that I can then use.
So far I don't see a downside, I get to carry on using mixins and variables, and I get seperated out styles for my components.
Thanks for taking this poll. It actually made me look into the issue and learn more than I anticipated. I vote for CSS Modules. Here's why.
For all the reasons you might expect, I've stopped using Bootstrap. I never use all of it. And while it is powerful and fast to work with, it also feels like Rails (writ small). You get a lot of magic you can't easily understand or know how to effectively override (I don't want to slam Bootstrap, it is an important and useful project). So, for those reasons I've started using Bourbon and it's family for their modularity and slimness.
But, I feel like CSS Modules are a useful evolution of that approach. I hope that the CSS modules world starts quickly pumping out small useful things like grids to help give devs the kind of hand up they got from Bootstrap, Bourbon and the like.
I just fall in love with bourbon and neat, . . . But I understand that sass and css modules doesn't play well, as many have been experiencing issues with it.
I've been reading all about ccs modules, and i think I will do just fine without bourbon and neat.
Thanks for everyone's thoughts on this!
Most helpful comment
I'm using both Sass and CSS modules. The only issue that I had was having my Sass variables (and other includes) being accessible from anywhere. Instead of requiring my Sass includes each time, I wrote a small Webpack loader that automatically appends a specific include file to each Sass file being imported into JS. So I have most of the benefits of Sass (mixins, shared variables etc..) while using CSS modules.