UI developers till a few months back were writing styles in a separate SASS files which would compile down to CSS and be included into the HTML.<p>With modern frameworks, developers started writing their styles in the HTML directly. It felt natural to new developers who liked keeping their HTML/JS for a component in a single Template/JSX file.<p>In my 'opinion', inline-styles polluted the DOM and get in the way. Browsers have to take a break while laying out to process each inline-style they encounter with the DOM nodes.<p>Keeping styles for each component in their own JSX makes it difficult to visualize the entire hierarchy in a large project. It is very easy to visualise in case of a SASS file (if done properly.)<p>Enter, styled-components which lets you write CSS as templates in JS and auto assigns a unique class name to every component. Hence no more element level styles. It also auto links the class to every instance of the component.<p>Under the hood, we are adding <style> nodes via JS and the browser has to generate the same class during every execution of the app/page (showcased as a feature - no build process). IMHO, this does not seem to bring in any advantage over the fact that browsers can easily parse external stylesheets once and cache them.<p>Consider the case where you are creating a UI framework from scratch. You would encounter nested elements, e.g. button inside a modal needs to be different than a button inside a hero component.<p>Of course having the ability to add custom CSS via JS is a good feature to have. Would you use it while building a React version of Bootstrap from scratch or go with a tool like SASS to create the styles for such a framework?<p>Looking for inputs from developers who work on modern UI/Frontend on how you handle styles for your components.
I think a global style file helps when the same HTML markup is repeated in several parts of your application.<p>However, a component based architecture, by definition represents the reusable HTML markup of your application. Since such a component brings along its own styles wherever it is used, there is negligible loss of reusability of styles.<p>This is in theory of course, but my experience (with Vue.js) has been the same in practice too.<p>With Vue.js at least, you have the optional "scoped styles" feature which gives you tuneable reusability in case you really need it. Most of the time, I find my self writing<p><pre><code> <style scoped>/*styles here*/</style>
in my component files.
</code></pre>
Edit: Regarding performance, I believe it could potentially be an issue on mobile devices (for now), and if so I would solve it by creating a global stylesheet by merging all individual stylesheets and appending the component name as a prefix in all selectors in both the styles and the markup.<p>This would be done programmatically using webpack or some other front end build tool. I doubt I'd ever need to do that TBH.
As the front end community moves to a decentralized component based model, it doesn't make sense to keep your styles seperate. Being able to see exactly what a component does, how it renders, how it looks, how it manages state, in my opinion has these benefits:<p>1 makes the code easier to test
2 easier to onboard new developers
3 better developer experience
4 easier to scale
5 easier to create decoupled chunks for single page apps/progressive web apps.
Styles in components are the next pattern to be figured out for components. The considerations should be<p>1. Styles should only apply to the component that they intend to style
2. Keep styles decoupled from any specific component library
3. There needs to be a communication layer between application interactions and the styles applied
4. Provide scalable patterns
5. Cache styles effectively
6. Chunk styles to optimize site
I agree with most comments which say that the modular approach is good for maintainability. But what about performance that takes a hit when the JS is creating and linking styles. Also, browser caching of styles is not possible in these cases.