Great write up. I wrote a similar post which is comparing different CSS architectures. https://medium.com/@webPapaya/css-architectures-in-2016-fab5d14c9b6e CSS Modules and CSS written in JS plays a big role in it.
At my current job we came to the conclusion that we don’t want to use CSS Modules because we would need to add 2 different dependencies to our technology stack. (1. a preprocessor to be able to use variables and mixins, 2. a build tool like webpack). As there is no official standard for CSS Modules and we would have to use another 3rd party tool we’re not sure if this is the right approach right now. As those tool come and go on a regular basis.
We actually don’t want to use inline styles because we think that we have to reinvent the wheel for pseudo classes, media queries and pseudo-selectors.
What we actually found is a small 200 line long library called Stilr which can be seen as a CSS preprocessor written in JS. It takes a JS Objects as an argument and simply stringifies those objects to regular CSS. One advantage I see in Stilr is that you can either preprocess your CSS on the server or dynamically generate the styles during runtime. Also you can use Media Queries, pseudo elements and pseudo classes like (:first-child,…). As Stilr is a pretty small library we’re able to add bug fixes and would also be able to maintain it our selfs if the official maintainers decide not to support it anymore.
Also if we realise that Stilr doesn’t work for us we can still switch to inline styles or render the stylesheet once replace the hashed classes and use CSS Modules. So we’re currently pretty flexible with this solution.