This is a great question, I used to think exactly the same until I became enlighten ;). Well OK, to be honest I'm still not entirely happy with how things are modularized, but I see advantages. This is a very good presentation which explains key ideas: https://speakerdeck.com/vjeux/react-css-in-js
Understanding the problems mentioned in the slides was literally eye opening. I was already trying to solve the problems with CSS, without fully realizing that I'm solving them. For example, my "solution" to namespaces was creating a naming conventions for all classes/IDs, like ".header-search-box-button" and this approach becomes PITA quickly. Also, after a while I had more and more dead code, which wasn't easy to identify and I couldn't be sure that if I remove some class, I don't have any elements that depend on it. Non-deterministic resolution was also an issue for me - say user was on a page A (therefore had loaded A.css with class .main-button) where particular boxes are blue. If the user goes to page B (we load B.css which also has .main-button) he should have red boxes. But if the user gets back to page A, the boxes that are supposed to be blue are red (browser cached the style and when browser have 2 classes definitions, the one that was loaded the last "wins"). Sure, we could use IDs for everything, bundle all styles into 1 file etc., but bigger sites would have like 5MB CSS file and at the end of the day it's still hard to maintain the codebase.
I'm sure that "normal" way works for regular/medium sites (it worked for a few good years, right?), but I see ton of advantages for using the inline styles in the JS. It's not easy to "convert" to new approach, but I honestly don't look back. As I've said - it's not ideal solution, but a very important step forward.
This is a good 3-part tutorial on react, flux and some other things:
This is the first time I saw Basscss, so take all this with a grain of salt. It seems well written, but I would put it in the same/similar category as for example Bootstrap. Basscss seems to be more modular - you can build your own "version" of Bootstrap - but Basscss gives you npm modules, so you could do something like/equivalent of require(basscss-grid). So, there are some differences that can be interpreted as a advantage of Bootstrap/Basscss, but react tries to solve the bigger problem IMO. Did you see that we're adding more and more "logic" into CSS (like animations calculations, :first, :even etc)? Where is the line? Does CSS is still "only" description of the presentation or something more? To be honest, I don't know where we are now, all those things start to merge/mix. I'd say that we're still on a quest to find the best paradigms for the web. "Regular" HTML, CSS and JS were working fine, but we're moving forward and new problems arise (how to handle different screen sizes, how can 1000 people work on the same code base, ...), so we're trying new solutions (like react and flux).
So, to answer your question: Basscss could help with some of the problems with CSS but I think that react solves problem on a higher level and does it better than any other solution we have now.
BassCSS is very different from Bootstrap or any other CSS framework. It's more like "classed inline styles", so you build your element styling like 'border border-blue blue bg-white p1 m1' (blue border, blue text on white background, 1 unit padding, 1 unit margin) e.g. you mix-and-match different CSS classes to style your elements.
So, I was thinking using React + BassCSS, and build the class string in my React components. Not sure if it makes sense, but at least it would probably be a bit more manageable and faster to develop than inline styles. Inline styles could be added on top of that of course.
If that's the case, I stand corrected. But the thing is, I still consider Basscss a solution from the "CSS world". React, IMO, takes it to the next level and combines inline styles with JS features (simple example: https://youtu.be/7YwmS0ny-58?t=58m38s - the scalable font can be done in pure CSS but I could imagine more complex use cases). Still, everybody picks the tools that are best suited for the problem and his/her preferences.
Understanding the problems mentioned in the slides was literally eye opening. I was already trying to solve the problems with CSS, without fully realizing that I'm solving them. For example, my "solution" to namespaces was creating a naming conventions for all classes/IDs, like ".header-search-box-button" and this approach becomes PITA quickly. Also, after a while I had more and more dead code, which wasn't easy to identify and I couldn't be sure that if I remove some class, I don't have any elements that depend on it. Non-deterministic resolution was also an issue for me - say user was on a page A (therefore had loaded A.css with class .main-button) where particular boxes are blue. If the user goes to page B (we load B.css which also has .main-button) he should have red boxes. But if the user gets back to page A, the boxes that are supposed to be blue are red (browser cached the style and when browser have 2 classes definitions, the one that was loaded the last "wins"). Sure, we could use IDs for everything, bundle all styles into 1 file etc., but bigger sites would have like 5MB CSS file and at the end of the day it's still hard to maintain the codebase.
I'm sure that "normal" way works for regular/medium sites (it worked for a few good years, right?), but I see ton of advantages for using the inline styles in the JS. It's not easy to "convert" to new approach, but I honestly don't look back. As I've said - it's not ideal solution, but a very important step forward.
This is a good 3-part tutorial on react, flux and some other things:
https://www.youtube.com/watch?v=Pd6Ub7Ju2RM
https://www.youtube.com/watch?v=iR22EWW-CVc
https://www.youtube.com/watch?v=6fhTawDEE9k