I'm not sure the implementation is quite what we need, but I definitely agree with the rationale.<p>CSS is global, as they point out, and CSS makes assumptions that may not be true today. For example, most apps these days — at least the kind I build – gain zero benefit from separating the style from the DOM. We never, ever apply different stylesheets to a single app.<p>The few use cases where truly separate stylesheets would be useful aren't significant enough to justify the separation. For example, "themes" are implemented through SASS variables that drive the presentation -- not with separate stylesheets.<p>And generally speaking, apps are simply too complicated to reimplement the entire app's stylesheet multiple times. And CSS cascading rules are sufficiently gnarly (eg., the exactness of the selector guides priority, except !important, etc.) to make things too error-prone to work in practice.<p>CSS was designed for basic marked-up hypertext documents, not today's sites or single-page apps. It works fine for documents, but for everything else it's increasingly showing an impedance mismatch, especially with respect to isolation and layout handling. Even with "flexbox" it's very limited compared to constraint solvers like Cassowary. We have to face the fact that layout belongs to content.<p>Anyway, there are a few problems with the CSS-JS approach:<p>- Media queries aren't possible anymore and must be done with JS. (I usually end up doing a lot of this in JS anyway, because media queries only deal with viewport sizes, not parent container sizes, so media queries break component isolation.)<p>- When you have styles applied to almost every element in a complex component, the DOM will look increasingly messy. You can't do mass-application things like "div > li { ... }".<p>- It's going to massively increase DOM size.<p>- Surely browsers must have highly optimzied CSS processors these days. I can't help but think that applying entire style rules to DOM elements must be slower than just referencing an existing compiled style.<p>Personally, I suspect a better way to approach this would be a React-specific, component-oriented style language. Not the modest tweaks they demonstrate in the first slides, but something built from the ground up.
At the last slide author says that the goal of that talk was to convince us to drop CSS and use JS.<p>Can't say that those slides were very convincing. Right now it looks way too overengineered.<p>I'm not a fan of muddying JS with bits of HTML in general, and now CSS in JS?<p>Yes, that may work for Facebook. They've been inventing their own way of doing things for a while now, but I very much hope that won't go beyond Facebook.
I can see that this approach might be viewed with a lot of suspicion, but this gels with a lot of problems we saw while building the MontageJS framework.<p>CSS <i>is</i> global, and it is a big problem to manage while building a large web app (which of course Facebook is). I think everyone building a large site or app has come across a bug where a CSS rule is unintentionally overriding another. They are a pain to track down and almost impossible to prevent.<p>I haven't played with this approach (as it was only talked about today!) but I think it's on the right track. The only thing I would like to see is the "CSS" put into its own module and required into the component JS file. Not only would this maintain the separation of style and markup, but also make it more approachable for those CSS experts coming from the current way of doing things.<p>I'm really looking forward to seeing how this progresses.