In the example provided, the problem is presented as a failure of cascading in CSS. But the problem as I see it, is in the structure of the HTML. The example is a component with a button inside a component with a button. Then global selectors are used which creates a result we don't want.
Slide 11 states global selectors are a problem. Which they can be, if used improperly just like every other tool we have access to.
So, the solution is to write Javascript that results in using classes. Which is what should have been done in the first place.
So, instead of creating a proper class structure in the HTML it is suggested to use Javascript to create classes, inject style sheets into the dom, and inject classes into the HTML elements on page load?
All to avoid using CSS properly?
I'm sure this is a wonderfully coded project, has interesting ideas, and may be useful to some, but as a front-end developer I seriously doubt I would ever use this nor recommend it. I would suggest just learning CSS, it's not that hard.
I would say that this type of project would be far more suited for a back-end library that generates stylesheets on the fly in an effort to maintain code efficiency. But doing all this in Javascript just seems to be about addressing people's attitude towards CSS and not about actual problems in CSS.
The problem this tries to address is the problem of maintainability when the entirety of the codebase doesn't fit in your head (because you have many people committing CSS at a fast pace, or a lot of junior devs, or because the codebase is large, or old, or the deadline is too tight, or any other number of reasons)
There's a world of difference between Facebook with its hundreds of devs commiting code to the same codebase over the span of many years, vs an agency where it's typical for one frontend person to own the entirety of the CSS codebase for a month-long project. In the latter case, you usually don't need the ability to scale the team (or can get away with enforcing ad-hoc processes). In the former case, having tooling that enables non-clashing class names by default is worth the trade-offs.
I would be the first to agree that there are problems with CSS, I use it nearly every day and I run into these problems quite a lot. But moving to the JS to attempt to solve these problems is taking several steps backwards to me.
All the problems you list in your example I would say exist as potential problems in any other aspect of a large-scale project. In most of the examples I've seen the problem seems to be giving developers who don't know CSS access to CSS and then wonder why it eventually falls apart.
.default-button(){ // properties }
.component-a button { background-color: red; }
.component-b button { .default-button(); color: green; }
If this tool is the solution, that the CSS it generates is the best way to do things, then why not code the CSS that way in the first place?
EDIT: As I'm seeing elsewhere in this thread; why exactly is globals bad in CSS?
Sharing a single scoping system between JS, HTML and CSS removes the need for global symbols (classnames or ids) to link the two together.
Abstractions in preprocessors are implemented by means of macros, and can lead to large file sizes.
Proper usage of CSS preprocessors will result in much the same code that this tool will generate. Because in the end they both generate the same CSS.
It doesn't help that in most of the examples the Javascript implementation is more complex than the css implementation.
I agree on the complexity issue with the examples, I don't see how the 30% savings claim would hold up.
The Cascade in CSS can be a real maintenance nightmare, and people seem to have very different ideas on how to handle encapsulation and modularization.
After a while with React, I thought it would be nice to define all styles for a component in the same location (inside my Component JavaScript). Setting the `top` property of a popup in JavaScript, but `width` or whatever in a CSS file just feels weird.
There's been some discussion about making this easier in React[1], but also resistance, so while waiting I wrote my own little library[2] (not React-specific), but it's not as feature rich as JSS.
I think that the fact that many projects[3] like this are popping up is validating the idea.
[1] https://github.com/reactjs/react-future/blob/master/04%20-%20Layout/04%20-%20Inline%20Styles.md
[2] https://github.com/jacobrask/marcssist
[3] https://github.com/js-next/react-style
https://github.com/tenphi/jcss
https://github.com/chenglou/RCSSI'm gonna go ahead and avoid repeating what's already mentioned in vjeux's presentation (https://speakerdeck.com/vjeux/react-css-in-js). Instead I'll focus on defending against the common "shortfalls" people tend to immediately point out with this approach.
Designers will be uncomfortable with learning this: React's JSX has shown that (surprise surprise) designers can bear modifying markup with a little bit of code mingled in it. In this case, JS objects in their simplest form map very well to css declarations. I don't believe designers will be scared away by this at all.
"Atwood's law", "we already have CSS", "stop reinventing CSS": no one's reinventing the idea of CSS; we're reinventing the implementation of it. Declaratively specify your layout is really nice, but you do want the backing of a real language to do so. Merging two styles is just a `merge()`, Overriding a style is just `bla.color = newColor` (assuming you don't mind the mutation; otherwise clone it or use persistent collections), and (!) reusing, importing, exporting styles is already solved with commonJS since you're working with normal js objects.
We already have preprocessors: except preprocessors are there to solve the exact problem "CSS in JS" is solving. The difference is that the latter, again, uses a real, familiar language instead of inventing an ad-hoc new syntax like we've done countless times with HTML templates. And since preprocessors need to generate the final CSS beforehand, this limits lots of potentials such as looping more than, like, ten times.
On this last point, I hope that none of the critics here used React's virtual DOM before; If you did, and are still complaining about writing CSS in JS, then you should go back and re-learn why the virtual DOM came to be. CSS in JS is the "virtual styling" equivalent for CSS. The potentials are huge (runtime feature detection for example). And this new layer allows us to map the neat, declarative style to something else than CSS: say, webGL. This is platform-independent; if anything, it's a nice conceptual model.
(Disclaimer: I made https://github.com/chenglou/RCSS)
Some people here assume that I am stupid and didn't learn the css basics. This is just funny.
These kind of things will receive lots of oppositions at first, but once you know the basics are right (e.g. trivial mapping from js obj to css) and build on top of it, this is bound to take off one day like JSX did =).
"This-is-not-what-I-am-used-to" objections notwithstanding, it's certainly an interesting approach to solve some CSS issues.
[1] http://blog.codinghorror.com/the-principle-of-least-power/
LESS is Javascript but with certain limitations. If you don't like it, write your own. Or better yet, contribute.