>Co do modułów to są przecierz w SASS (gemy), plik konfiguracyjny rownież z opcjami od includowania po ustawienia dokładności przybliżeń przy obliczeniach.
To nie jest rozwiązanie dobre do wszystkiego – ma bardzo specyficzny zasięg stosowania. Modułem jest bazowy selektor rozszerzany przy pomocy nadpisywalnego configu (coś jak !default w SCSS) i warunkowych mixins (mogą, ale nie muszą być zadeklarowane). W LESS dało się to osiągnąć przy pomocy hoistingu mixins, w Stylusie tę rolę przejął zewnętrzny plugin wprowadzający prawdziwą modularność. W SASS było ten problem najtrudniej rozwiązać ;)

>To z tą niezależnością od języka – dla mnie argument na siłę podobnie z redefinicją wstawek
Masz cały system w C++ – napiszesz do niego dodatek w Javie?

>Debugowanie kodu, którego wynik zależy od miejsca jego umieszczenia w arkuszu… coż, do przyjemnych pewnie nie należy.
Hoisting jest przewidywalny przecież. Znasz JS = rozumiesz hoisting.

>Co do zdalnego konfigu to jakoś na szybko nie widzę płynących z niego korzyści
Jeszcze raz powiem, że to system w gruncie rzeczy przypominający !default w SCSS

>Jaka jest wydajność takiego rozwiazania przy 16 tyś. linii CSS?
Dobra. Jeśli głównym zmartwieniem jest optymalizacja build toola, to musicie mieć naprawdę wydajny produkt ;)

>Jeżeli faktycznie to takie dobre rozwiązanie to chętnie je wypróbuję.
Jest cholernie profilowane, więc ma bardzo wąskie zastosowanie. Niemniej w tym, do czego zostało stworzone, jest o wiele lepsze niźli mechanizmy oferowane out of box we wszystkich preprocesorach.

Co do modułów to są przecierz w SASS (gemy), plik konfiguracyjny rownież z opcjami od includowania po ustawienia dokładności przybliżeń przy obliczeniach. To z tą niezależnością od języka – dla mnie argument na siłę podobnie z redefinicją wstawek. Debugowanie kodu, którego wynik zależy od jego umieszczenia w arkuszu… coż, do przyjemnych pewnie nie należy.

Co do zdalnego konfigu to jakoś na szybko nie widzę płynących z niego korzyści, których nie dałoby się zrealizować w bardziej naturalny sposób.

Jaka jest wydajność takiego rozwiazania przy 16 tyś. linii CSS? Bo kompilacja tego na PC zajmuje nawet ponad kilkanaście sekund (jest cache, więc zależy gdzie nastąpiły zamiany).

>Fajne przy mniejszych projektach, przy większych siłą rzeczy kończy się na nadaniu wielu elementom i tak sztywnych wartości, bo niektóre elementy interfejsu po prostu muszą mieć określone proporcje i wymiary.
Przy mniejszych projektach również przecież. Oczywiście nie ma sensu wszystkiego trzymać w rem/em, ale na pewno wszystko, co się da, lepiej w tym mieć

>Czego nie mogłeś zrobić w SCSS?
System modułów z configiem ad hoc, redefinicja mixins, definiowanie mixins po ich wywołaniu (czyli hoisting)… dużo by wymieniać. W Stylusie udało się to dorobić tylko i wyłącznie dlatego, że po prostu udostępnia parser JS…

> IMO w przypadku używania BEM coś takiego jak selektory stanów i selektory do pracy z JS są całkowicie redundantne.
Zależy. Przy stronkach wizytówkach, możliwe. Przeciwnie przy dużych projektach, taka separacja oszczędza potem wiele czasu.

> Co do rem/em: http://css-tricks.com/rems-ems… – bodaj najlepszy pomysł na modułowy CSS jaki widziałem. Genialne uzupełnienie dla BEM.
Fajne przy mniejszych projektach, przy większych siłą rzeczy kończy się na nadaniu wielu elementom i tak sztywnych wartości, bo niektóre elementy interfejsu po prostu muszą mieć określone proporcje i wymiary.

> Przeszedłem na SASS-a, ale wciąż pozwalał na zbyt mało.
Zbyt mało? To chyba bardzo starą dokumentacje czytałeś. Czego nie mogłeś zrobić w SCSS?

Co do OOCSS – wydaje mi się akurat, że przykład w BEM to nie to ;) BEM bowiem zabija natywną obiektywność CSS (zarówno kaskadowość selektorów, jak i dziedziczenie), wprowadzając płaską hierarchię klas i polimorfizm (aka modifiers, co właśnie widać na Twoim przykładzie). Dla mnie OOCSS to bardziej to, co przedstawił logeen: http://www.kurshtml.edu.pl/css/css_zorientowane_obiektowo,dobre_praktyki.html
Jeśli używamy określenia OOCSS w stosunku do BEM, należy uściślić, że chodzi nam tak naprawdę o przeniesienie obiektowości z CSS na poziom abstrakcyjnego modelu BEM.

Co do rem/em: http://css-tricks.com/rems-ems/ – bodaj najlepszy pomysł na modułowy CSS jaki widziałem. Genialne uzupełnienie dla BEM.

Co do id w CSS i jego 255 razy silniejszego działania: błąd w implementacji ;) Stara Opera nie miała tego buga (AFAIR zapisywali to w 64-bitowej zmiennej, zamiast w 32-bitowej jak cała reszta).

Co do preprocesora: pracowałem na LESS, ale pozwalał na zbyt mało. Przeszedłem na SASS-a, ale wciąż pozwalał na zbyt mało. Teraz siedzę na Stylusie i dalej mnie drażni, że tak mało w nim można… ;) Chyba dla takich jak ja zostaje Absurd.js