3 ms·

Sass/Compass/SCSS, Less, Stylus... Can you please decide for one and build a stable toolchain around it? Having less half-baked support for 6 variants of the

by moe 15y ago

Sass/Compass/SCSS, Less, Stylus... 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.

twog 15y ago
I hear what you're saying, but isnt that "problem" what open source is all about? I personally prefer Less, but that doesnt mean there shouldnt be multiple options. Everyone has different things that work for them.
- batista 15y ago
  >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.
pault 15y ago
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.
stdbrouw 15y ago
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.

by moe 15y ago

twog 15y ago

I hear what you're saying, but isnt that "problem" what open source is all about? I personally prefer Less, but that doesnt mean there shouldnt be multiple options. Everyone has different things that work for them.

batista 15y ago
>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.

pault 15y ago

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.

stdbrouw 15y ago

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.