I've been using inline styles in my React apps for awhile now, and I've found it makes styling much, much easier.<p>That said, it seems the winds have shifted a bit and more people are eschewing inline styles in favor of CSS-in-JS solutions such as styled-components or emotion. I've tinkered with both of these libraries a bit, and I have to say I can't see how these are an improvement over plain inline styles. They introduce additional build steps, the use of string literals instead of plain JavaScript objects, and they mess with the core React.createElement function. The upside is you get to use pseudo-selectors, which is nice, but I've found with a real programming language at my disposal (i.e. JavaScript), I don't really need many pseudo-selectors beyond :hover.<p>What am I missing?
These days any new technology has a stampede of youtube tutorial makers, Pluralsight authors, and other programmer "influencers" that make it seem like it's the next new thing.<p>At the same time people who understand one technology may not want to learn new ideas and techniques. If it aint broke don't fix it.<p>The point of me writing these two conflicting ideas is inject some skeptisism into the conversation. Maybe you aren't missing anything and the tool is overhyped and you don't fully understand the benefits. Both of these things can be true.
I think the future of CSS is that we'll see all the innovation from the CSS-in-JS world come back home to CSS stylesheets.<p>It's hard to beat the high-level declarative nature of writing style rules in a stylesheet that can style any HTML or XML DOM you use them with. I think a lot of current CSS-in-JS tooling ends up being too limited in that it often requires you to know the DOM in advance and couples the styles tightly with the DOM - while also leaving you unable to style anything you run across or need to work with that was created outside your particular workflow or pre-exists outside of your app.<p>The future looks like CSS, augmented by Layout worklets written in JS, and augmented by Paint worklets written in JS, and Animation worklets written in JS, and Custom Property definitions that can be supported by JS. And we believe custom script-supported at-rules, functions, and selectors are next to come to CSS.<p>The long and sort of it - you should be writing CSS in CSS stylesheets, and JavaScript in your JavaScript files, and find ways to use Javascript to define the custom features you want to use in your stylesheets. This is how the technology is growing, and when you extend real CSS with real JS, you can style anything, any DOM made by any tools.<p>More reading:<p>- <a href="https://houdini.glitch.me" rel="nofollow">https://houdini.glitch.me</a><p>- <a href="https://css-houdini.rocks" rel="nofollow">https://css-houdini.rocks</a><p>- <a href="https://developer.mozilla.org/en-US/docs/Web/API/Worklet" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/API/Worklet</a>
I see stuff like inline styles and CSS-in-JS and I can't stop remembering what web development was like in the 1990s before CSS was a thing. It was horrible, and I refuse to ever go back.
Css-in-JS
Pros:<p><pre><code> - Enforce only local styles
- Developer productivity
- Better theming support
- Better support for dynamic styles
- Easier to consume packages
- Typesafe styles
</code></pre>
Cons:<p><pre><code> - Worse runtime performance
- Bigger bundle size
- Fragmentation of ecosystem
- Idiosyncratic additions to css
</code></pre>
It depend on your project. For small and medium sized projects I would recommend CSS-in-js. For large and performance-sensitive css-modules would be better.
One thing I've come to like with CSS-in-JS is the ability to define a CSS API. For example the MUI Select component <a href="https://material-ui.com/api/select/#css" rel="nofollow">https://material-ui.com/api/select/#css</a> it's a non-trivial amount of customization you can add (and you can define your own). As Chyzwar said in his post, this allows theming of custom components making it almost trivial for developers<p>I do think it's possible to have too much of a good thing, but for the most part I've seen developers ill-define a CSS API (with no easy way to override) which then becomes messy with !important all over the place. I do wish CSS blocks from LinkedIn (<a href="https://css-blocks.com/" rel="nofollow">https://css-blocks.com/</a>) had better support and adoption because I thought it looked promising. I may even try it on a project soon since my new employer doesn't have an onerous on what I do during my free time
Both create more problems than they solve, both essentially break the advantages of css. What bothers me about css-in-js, it does not have a single advantage over vanilla css. Every challenge it supposedly solves is a real world non-issue if you know how css works. Local styles, theming, dynamic styles, safety, maintainability, performance, you can have all of this in vanilla css without the issues associated with inline styles and the js-in-css abomination. Just learn the damn thing. js-in-css is a lazy workaround for software developers who want to do things the way they learned, not the way it was meant to be done.
I can suggest using JavaScript codes to create the CSS codes ahead of time and then just post the compiled CSS codes on the server for download by the client, rather than having the CSS codes being made up by the client.<p>Also, I think you should not use the HTML "style" attribute; it is bad for accessibility. Use the "class" attribute instead.