Can you please decide for one and build a stable toolchain around it? Having less half-baked support for 6 variants of the same thing doesn't help anything. Kthxbai.
The SASS, Less and Stylus compilers and CLI apps are all stable and full-featured, both Less and Stylus have a client-side compiler, and all three are supported by various asset preprocessors. It'd be nice if one of them became the de-facto standard simply because they're all so similar anyway and having a clear go-to solution is always nice, but I don't think crappy toolchains are a real problem with these tools.
SMACSS is a set of recommendations for reducing CSS bloat in large web applications. Compass is a library of convenience classes, and the others you mention are preprocessors. Apples and oranges.
SCSS and Less are similar enough that porting code between them is usually just a matter of changing a few symbols and keywords. Compared to the fragmentation of the rails ecosystem I don't consider this too overwhelming.
>I hear what you're saying, but isn't that "problem" what open source is all about?
It's an artifact of Open Source, but it doesn't mean it's what "open source is all about". It would still be Open Source even if there was only one best-of-breed project with an open source license, instead of several fragmented options.
If people were unhappy with that, they could then fork that ONE project to their taste --or start others but in a much smaller scale.
Like, say, Linux: it's still Open Source, but gets 99% of the love, user base, and community and enterprise support that other open OSs get. So you have some alternatives (FreeBSD, etc) but not the more dire effects of mass fragmentation.
It's not like, say, LESS vs SASS are THAT different to warrant two different projects, anyway.
These are all improvements, I'm sure, but I'm less convinced they help address the problem I've most often confronted with on large projects, which is roughly this: You need to make a change to a specific item because it looks crap on a specific screen. Do you:
a) Special case it, thus adding to the bloat and making it tougher to use elsewhere.
b) Change the general case, but then need to spend a lot of time going through the app to make sure this hasn't blown up elsewhere.
c) Create a new general case, which adds bloat and might never be reused.
Compounding the problem is that often the CSS is third party. For example you find yourself overriding this or that Jquery component, but then it turns out that the style you overrode is actually used in a completely different component.
Read through smacss.com, if you haven't already. It advocates a modular approach that should minimize the impact that components have on other components, thus a style change to one component won't blow up the rest of the site.
Third party tools can be hit and miss. Hopefully you're working with plugins/libraries that don't inject inline code and rely on namespaced classes to achieve the result you need. Then, you have control of the CSS to style as you wish.
(disclaimer: I wrote smacss (but didn't write the blog post))
Can you please decide for one and build a stable toolchain around it? Having less half-baked support for 6 variants of the same thing doesn't help anything. Kthxbai.