I'm not sure the implementation is quite what we need, but I definitely agree with the rationale. CSS is global, as they point out, and CSS makes assumptions t

I'm not sure the implementation is quite what we need, but I definitely agree with the rationale. 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. 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. 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. 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. Anyway, there are a few problems with the CSS-JS approach: - 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.) - 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 { ... }". - It's going to massively increase DOM size. - 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. 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.