>but this Javascript solution does the exact same thing.
But with this lib I don't care about classes. I just put thing in, and I have 0 conflicts. I can do whatever I want and no conflicts. Try that in css. Also take a look at react.js this lib is perfect fit for that.
The code you write doesn't care about classes, but the CSS that is generated does. Why not do it the CSS way from the beginning and take JS out of the equation altogether so that everything is more efficient?
The most common answer I've seen is "because I don't want to learn CSS", which I don't feel is a good enough answer.
I can write CSS all day using classes that do not conflict in the manner described.
There is another answer pointed out multiple times throughout this thread which is "because name clashes happen if we want to write components in isolation from other teams". Its just that the "writing separate components" part never happens exactly because the infrastructure doesn't support it (except in situations of dire need like fontawesome), so there are "no problems" :)
Yup. Pretty much any virtual-dom approach benefits from this type of solution. Furthermore, if you adopt any sort of system on top of the v-dom approach that does layout management with CSS 3D matrices like famo.us does, you end up greatly benefiting from a solution like this as well. Cascading doesn't work really that well if you don't have explicit and persistent semantic nesting all the way down the tree of elements in a window.
