
Ask HN: Why prefer CSS-in-JS over inline styles? - mmckelvy
I&#x27;ve been using inline styles in my React apps for awhile now, and I&#x27;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&#x27;ve tinkered with both of these libraries a bit, and I have to say I can&#x27;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&#x27;ve found with a real programming language at my disposal (i.e. JavaScript), I don&#x27;t really need many pseudo-selectors beyond :hover.<p>What am I missing?
======
jf22
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.

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.

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.

------
err4nt
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.

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://houdini.glitch.me)

\- [https://css-houdini.rocks](https://css-houdini.rocks)

\- [https://developer.mozilla.org/en-
US/docs/Web/API/Worklet](https://developer.mozilla.org/en-
US/docs/Web/API/Worklet)

~~~
mmckelvy
So a lot of that sounds good, and the Houdini stuff looks interesting, but how
does "extending CSS" with JS or worklets solve the two main problems of CSS,
namely the ability to define local styles and the ability to dynamically
change or define styles on the fly?

Also, it doesn't look like browser support for those new APIs is going be very
good for quite some time.

~~~
err4nt
I'm not quite sure what you're asking about the 'two main problems of CSS' \-
can you explain more about what's problematic about defining 'local styles' or
updating styles dynamically?

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

------
Porthos9K
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.

------
Chyzwar
Css-in-JS Pros:

    
    
      - Enforce only local styles
      - Developer productivity
      - Better theming support
      - Better support for dynamic styles
      - Easier to consume packages
      - Typesafe styles
    

Cons:

    
    
      - Worse runtime performance
      - Bigger bundle size
      - Fragmentation of ecosystem
      - Idiosyncratic additions to css
    

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.

------
arenaninja
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 [https://material-
ui.com/api/select/#css](https://material-ui.com/api/select/#css) 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

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/](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

------
floppiplopp
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.

~~~
mmckelvy
Can you elaborate? Specifically curious about how you get local styles and
dynamic styles in vanilla CSS.

------
zzo38computer
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.

Also, I think you should not use the HTML "style" attribute; it is bad for
accessibility. Use the "class" attribute instead.

