3 ms·
I've spent the past 5 years with various blends of SASS, CSS, CSS-in-JS, Redux, Rx, React, Material-UI and a few other bits and bobs (and several years of front
by the_other 7y ago
I've spent the past 5 years with various blends of SASS, CSS, CSS-in-JS, Redux, Rx, React, Material-UI and a few other bits and bobs (and several years of front end dev with other tech before that, too).
I prefer by far keeping the CSS (or SASS) separate from the rest. React's mix of JS and HTML-ish is very comfortable, but I can't say I love it more than "native JS + some kind of templating". However, I'm absolutely certain that I prefer the CSS left outside the rest. My reasons include:
- you (probably) don't have to recompile the whole JS app to get your style changes
- it's much easier to see the relevant JS when you don't have to skip over CSS or lengthy class names
- it's much easier to see how bits of CSS relate to one another when they're in the same file (which I'll admit can make _some_ parts of that job harder, some of the time)
- when the browser's dealing with "proper" CSS, you can use the browser tools to test changes before updating the source files, skipping around the DOM, watching all the selected elements change (which doesn't always happen when you have CSS Modules style scoping going on)
- code editor tooling is usually better
- you don't have to remember whether you're writing your CSS in native CSS, snake-case, or JS style camelCase (I know some of the recent CSS-in-JS tech helps here, but why add a library to do something the browser already does?)
- you don't need to add libraries to do something the browsers already do