Ask HN: Why prefer CSS-in-JS over inline styles?
I've been using inline styles in my React apps for awhile now, and I've found it makes styling much, much easier.
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.
What am I missing?
10 comments
[ 3.4 ms ] story [ 26.1 ms ] threadAt 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.
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 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 (https://css-blocks.com/) 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
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.
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.
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.
More reading:
- https://houdini.glitch.me
- https://css-houdini.rocks
- https://developer.mozilla.org/en-US/docs/Web/API/Worklet
Also, it doesn't look like browser support for those new APIs is going be very good for quite some time.
CSS custom properties, which already do have browser support, are a wonderful example of allowing JS to set values that CSS is able to take and use dynamically - check out libraries like Splitting.js or ScrollMagic for examples of applications of that.
Houdini worklets (pluggable Layout, Paint, Animation worklets) are definitely coming - this is what's currently being worked on as well as the 'Typed Object Model' for CSS where they're tightening the bolts and helping JS become aware of the different values and types inside the CSS language.
Also, when looking at support, keep in mind that as of Jan 15th, Edge will have the same support as Chrome :D
Also, I think you should not use the HTML "style" attribute; it is bad for accessibility. Use the "class" attribute instead.