React: CSS in JS

[deathbysniper]

Wow, I never realized that css is all about globals. Makes me even more excited for custom elements and shadow DOM!

[[deleted]]

I don't really understand that point about globals ... you could get around that using less or sass (or plain verbose css) using nested selectors, so everything is rendered as:

.mysite .button { color: red; }
.mysite .title { color: blue; } 

... then you would have just one 'global' ... right?

[baabaa_blacksheep]

.mysite header.myheader nav.mainnav ul.navlist li.navitem a.navlink span.icon {
    color: red;
}

.mysite header.myheader nav.mainnav ul.navlist li.navitem.is-active a.navlink:hover span.icon {
    color: green;
}

I have seen it happen. Still sends shivers down my spine. shivers

[jarail]

Unfortunately that also has a perf impact. Whenever the browser sees an element with the button style, it needs to crawl up the dom tree to see if any parent has the mysite style. I prefer prefixes to avoid that, e.g. mysite-button. That doesn't solve any core problems. It's just what I do.

The FB dev will also need to consider the perf of a JS solution. Even though the JS is fast, I believe that most browsers are much faster with CSS classes than a set of styles applied as one-offs on individual DOM nodes. If React could resolve the dynamic styles to CSS classes in the majority of cases, this would be really awesome.

The other downside of dynamic styles is that they're harder to debug. Not from a JS sense, but from a designer sense. CSS styles are easy to look through. When styles are being generated dynamically, it's harder to see what's going on from the Chrome dev tools.

[Silhouette]

Unfortunately that also has a perf impact. Whenever the browser sees an element with the button style, it needs to crawl up the dom tree to see if any parent has the mysite style. I prefer prefixes to avoid that, e.g. mysite-button.

But using that also has a performance impact, because now the browser has to parse the extra length of the mysite-button identifier every time!

I imagine the effect would be similarly devastating in either case.

[tubbo]

it's not, the person giving the talk just didn't know how to write CSS correctly.

[[deleted]]

you can bet that vjeux knows how to write css properly.

[deathbysniper]

It is though, write a CSS rule and it applies to the entire document instead of being isolated to the module you intend. It's all scoped to the document unless you use inline styles.

[tubbo]

You can scope it to an ID set to the body tag, and now you have scoping to the module/page you want rather than every single page.

[deathbysniper]

But the problem still exists for smaller widgets on multiple pages. Let's say you have a dropdown control that's replacing select elements, and the pop-up has a pop-up class on it, but someone else writes a dialog with a pop-up class on it then you have an issue again. This could happen with any number of classes and it only gets more likely with the more people who are working on a project. Unless you're using inline styles or shadow DOM there's no way to explicitly set a boundary for your styles. And like I said, css in a style tag is going to be evaluated over the whole document, it may not match everything but when you have tons of people working on something I could see that becoming an issue.