11 ms·

They seem pretty confident about Sass; It seems outdated and clunky to me, in part because it's always going to be the only Ruby dependency in any of my project

They seem pretty confident about Sass; It seems outdated and clunky to me, in part because it's always going to be the only Ruby dependency in any of my projects. The Javascript parser never found parity from what I know. By contrast, PostCSS is faster and has massive adoption. Seems like the way forward. Anybody think this is wrong? > PostCSS can do the same work as preprocessors like Sass, Less, and Stylus. But PostCSS is modular, 3-30 times faster, and much more powerful. https://github.com/postcss/postcss https://github.com/postcss/postcss

StavrosK 11y ago
If I'm going to have to choose between Ruby and Node as a dependency for my project, I'll go with Ruby, and be unhappy regardless. Installing a whole programming language/framework and package manager just for a transpiler isn't my idea of fun.
- curun1r 11y ago
  I think a lot of people feel that way, but it's a false dichotomy based on what I've seen. The more real choice is between Node/Ruby and just Node. When building a web application, you're basically forced to use JavaScript. It would be nice if this wasn't the case, and there are some transpilation tools that can basically get around that requirement, but it's almost always more painful to go that route. So if you're basically going to need the Node toolchain anyways for stuff like Babel and Webpack/Browserify, having your CSS abstraction library also use it means not needing an extra Ruby dependency. But there's not really an option to use only Ruby.
not_with_retard 11y ago
Ruby? Yeah sure, if you're a sucker. https://github.com/sass/libsass https://github.com/sass/libsass
mbreedlove 11y ago
They mentioned they're using libsass, a C/C++ port of the compiler. Although it's only an issue if you're using the source and not the compiled CSS. The same issue exists with v3 needing a LESS compiler.
- coldtea 11y ago
  >The same issue exists with v3 needing a LESS compiler. Only there are TONS of LESS compilers, even a straight PHP one, a pure JS etc, whereas Sass has either Ruby or a C/C++ dependency.
  - tacone 11y ago
    The last time I looked at the PHP one, it compiled fine, but wasn't handling variables scopes in the same way of the JS one. This was a big deal for me.
    - coldtea 11y ago
      I used to use it (lessphp) for some light LESS use, so it might be faulty for more advanced stuff, but was OK for me.
    - girvo 11y ago
      Yeah, which is one of the reasons why I'm not a fan of Assetic in Symfony. The PHP versions of front-end build components are always lacking, unfortunately. But that's not a big deal in my opinion, you basically always need Node for a front-end application at this point for other needed tooling (Browserify/WebPack, Babel, etc.) so better to use the best-of-breed tooling and ignore Assetic as much as possible.
      - conradfr 11y ago
        Yes, I tried using the React filter and failed. I switched to Gassetic (https://github.com/romanschejbal/gassetic https://github.com/romanschejbal/gassetic) which is interesting but quite new and not well maintained. I couldn't make Reactify working with it which lead to way too long Browerify compilation time. Next project I'll just use directly Gulp-or-whatever-is-fancy-then and find the simplest way to integrates it in Symfony/Twig.
thegeekpirate 11y ago
There's no reason to use Ruby https://github.com/sass/libsass https://github.com/sass/libsass
- davexunit 11y ago
  libsass is very strange. It must be statically linked and it requires copyright assignment for contributions.
  - Vespasian 11y ago
    The LICENCE file looks like standard MIT to me. Where did you find this info?
    - davexunit 11y ago
      Here: https://github.com/sass/libsass#contribution-agreement https://github.com/sass/libsass#contribution-agreement I think it's unfortunate. While I'm comfortable with assigning copyright to nonprofit organizations with a commitment to keep code free and enforce the license, I'm not comfortable assigning copyright to individual people.
tmcdonald 11y ago
v4 will compile with libsass by default. You can set the TWBS_SASS environment variable to use the Ruby compiler if desired.
jscheel 11y ago
I've been hearing a lot of noise about that. As a person who went from LESS to SCSS, is there any reason I should again switch my focus to PostCSS?
- pyre 11y ago
  Not unless you like chasing the "latest and greatest" fad. If Sass (or Less) is working for you, then use it. If you are running into issues, then research alternatives. Both Less and Sass are actively maintained projects, so there's not reason to run around switching frameworks unless there is a concrete need for it.
  - jscheel 11y ago
    I ran into significant issues with LESS that forced me to switch. I haven't seen any with SCSS, so that's the question. Is it just another new fad, or have people exhibited a real need for switching?
    - AhtiK 11y ago
      would you mind sharing what were the significant issues with LESS? I'm using LESS and just wondering what I might be missing.
      - jscheel 11y ago
        Well, I built a theming engine that utilized LESS in combination with a whole host of other stuff. It became a big problem there, but that's not really a use-case that is applicable to most. For more common issues, the way LESS does guarded mixins was super annoying, the breaking changes in minor version release, etc.
    - bshimmin 11y ago
      (I wanted to post this reply to DarkTree too, since it seemed equally applicable.) I've looked at PostCSS a couple of times lately and it seems "interesting", but the cited benefits (speed, modularity, the ambiguous "more powerful") aren't really things I've ever paused to worry about with Sass. And when I look at the first example of PostCSS, it seems dauntingly weird, though presumably some of that is actual future CSS - I have enough trouble keeping up with future JavaScript, so forgive me if I've not really kept au courant with whatever is happening in the future of CSS (I think I lost interest around the time they decided to make variables really, really complicated). Sass seems to solve all or most of the problems I care about most of the time with CSS, and it's easy to onboard people who've never used it before. In fact, to be honest, I only really use a subset of the features of Sass (variables, nesting, mixins, inheritance), so switching to something that has more powerful features that I would probably more powerfully have to eschew is... not very high on my list of priorities.
pyre 11y ago
> in part because it's always going to be the only Ruby dependency in any of my projects. The Javascript parser never found parity from what I know. Now that libsass (C or C++ implementation) has matured, the Ruby dependency is not necessary. I always resented Sass (vs. Less) a bit because of the Ruby dependency (in projects not using Ruby otherwise). Now that you can link against libsass, I don't feel like that's an issue anymore. There are JavaScript libraries linking to libsass (if you are using Grunt/Gulp/etc to build your css). [Note: I looked into libsass a little over a year ago (around June 2014) and they were openly stating that it wasn't production-ready, and they were targeting (I think) August 2014 for some features.]
- o_____________o 11y ago
  Thanks for the overview, that was about my timeline too. The other thing is that PostCSS just looks cleaner, extensible and more future-forward. cssnext+autoprefixer is awesome, for example. There's even a Sass-like DSL. I had been on Less for a long time, but some of its limitations bothered me.
- xrstf 11y ago
  <rant>Yeah I really love how I now not only need Node and npm, but also gcc to install/build a frickin' web project. Because f*ck the platform-independence we got with Node, who cares if a simple `npm install` takes 30 minutes to complete.</rant>
  - pyre 11y ago
    Nothing is requiring you to use these tools, but as web projects become more and more complex we develop tools to deal with the complexity. You could just as easily ignore all of this and use server-side rendering in your language of choice.
  - rubiquity 11y ago
    You would need GCC to install Node anyway. Not to mention the fact that you probably have GCC or Clang already anyway...
rattray 11y ago
@mdo recently tweeted that v5 will likely be in PostCSS: > Oh, btw—Bootstrap 4 will be in SCSS. And if you care, v5 will likely be in PostCSS because holy crap that sounds cool. https://twitter.com/mdo/status/591364406816079873 https://twitter.com/mdo/status/591364406816079873 EDIT: also, elsewhere on this thread, he mentioned: > Sass is really similar to Less, so it's an easier transition to make than jumping right to PostCSS.

StavrosK 11y ago

If I'm going to have to choose between Ruby and Node as a dependency for my project, I'll go with Ruby, and be unhappy regardless. Installing a whole programming language/framework and package manager just for a transpiler isn't my idea of fun.

curun1r 11y ago
I think a lot of people feel that way, but it's a false dichotomy based on what I've seen. The more real choice is between Node/Ruby and just Node. When building a web application, you're basically forced to use JavaScript. It would be nice if this wasn't the case, and there are some transpilation tools that can basically get around that requirement, but it's almost always more painful to go that route. So if you're basically going to need the Node toolchain anyways for stuff like Babel and Webpack/Browserify, having your CSS abstraction library also use it means not needing an extra Ruby dependency. But there's not really an option to use only Ruby.

not_with_retard 11y ago

Ruby? Yeah sure, if you're a sucker. https://github.com/sass/libsass https://github.com/sass/libsass

mbreedlove 11y ago

They mentioned they're using libsass, a C/C++ port of the compiler. Although it's only an issue if you're using the source and not the compiled CSS. The same issue exists with v3 needing a LESS compiler.

coldtea 11y ago
>The same issue exists with v3 needing a LESS compiler. Only there are TONS of LESS compilers, even a straight PHP one, a pure JS etc, whereas Sass has either Ruby or a C/C++ dependency.
- tacone 11y ago
  The last time I looked at the PHP one, it compiled fine, but wasn't handling variables scopes in the same way of the JS one. This was a big deal for me.
  - coldtea 11y ago
    I used to use it (lessphp) for some light LESS use, so it might be faulty for more advanced stuff, but was OK for me.
  - girvo 11y ago
    Yeah, which is one of the reasons why I'm not a fan of Assetic in Symfony. The PHP versions of front-end build components are always lacking, unfortunately. But that's not a big deal in my opinion, you basically always need Node for a front-end application at this point for other needed tooling (Browserify/WebPack, Babel, etc.) so better to use the best-of-breed tooling and ignore Assetic as much as possible.
    - conradfr 11y ago
      Yes, I tried using the React filter and failed. I switched to Gassetic (https://github.com/romanschejbal/gassetic https://github.com/romanschejbal/gassetic) which is interesting but quite new and not well maintained. I couldn't make Reactify working with it which lead to way too long Browerify compilation time. Next project I'll just use directly Gulp-or-whatever-is-fancy-then and find the simplest way to integrates it in Symfony/Twig.

thegeekpirate 11y ago

There's no reason to use Ruby https://github.com/sass/libsass https://github.com/sass/libsass

davexunit 11y ago
libsass is very strange. It must be statically linked and it requires copyright assignment for contributions.
- Vespasian 11y ago
  The LICENCE file looks like standard MIT to me. Where did you find this info?
  - davexunit 11y ago
    Here: https://github.com/sass/libsass#contribution-agreement https://github.com/sass/libsass#contribution-agreement I think it's unfortunate. While I'm comfortable with assigning copyright to nonprofit organizations with a commitment to keep code free and enforce the license, I'm not comfortable assigning copyright to individual people.

tmcdonald 11y ago

v4 will compile with libsass by default. You can set the TWBS_SASS environment variable to use the Ruby compiler if desired.

jscheel 11y ago

I've been hearing a lot of noise about that. As a person who went from LESS to SCSS, is there any reason I should again switch my focus to PostCSS?

pyre 11y ago
Not unless you like chasing the "latest and greatest" fad. If Sass (or Less) is working for you, then use it. If you are running into issues, then research alternatives. Both Less and Sass are actively maintained projects, so there's not reason to run around switching frameworks unless there is a concrete need for it.
- jscheel 11y ago
  I ran into significant issues with LESS that forced me to switch. I haven't seen any with SCSS, so that's the question. Is it just another new fad, or have people exhibited a real need for switching?
  - AhtiK 11y ago
    would you mind sharing what were the significant issues with LESS? I'm using LESS and just wondering what I might be missing.
    - jscheel 11y ago
      Well, I built a theming engine that utilized LESS in combination with a whole host of other stuff. It became a big problem there, but that's not really a use-case that is applicable to most. For more common issues, the way LESS does guarded mixins was super annoying, the breaking changes in minor version release, etc.
  - bshimmin 11y ago
    (I wanted to post this reply to DarkTree too, since it seemed equally applicable.) I've looked at PostCSS a couple of times lately and it seems "interesting", but the cited benefits (speed, modularity, the ambiguous "more powerful") aren't really things I've ever paused to worry about with Sass. And when I look at the first example of PostCSS, it seems dauntingly weird, though presumably some of that is actual future CSS - I have enough trouble keeping up with future JavaScript, so forgive me if I've not really kept au courant with whatever is happening in the future of CSS (I think I lost interest around the time they decided to make variables really, really complicated). Sass seems to solve all or most of the problems I care about most of the time with CSS, and it's easy to onboard people who've never used it before. In fact, to be honest, I only really use a subset of the features of Sass (variables, nesting, mixins, inheritance), so switching to something that has more powerful features that I would probably more powerfully have to eschew is... not very high on my list of priorities.

pyre 11y ago

> in part because it's always going to be the only Ruby dependency in any of my projects. The Javascript parser never found parity from what I know. Now that libsass (C or C++ implementation) has matured, the Ruby dependency is not necessary. I always resented Sass (vs. Less) a bit because of the Ruby dependency (in projects not using Ruby otherwise). Now that you can link against libsass, I don't feel like that's an issue anymore. There are JavaScript libraries linking to libsass (if you are using Grunt/Gulp/etc to build your css). [Note: I looked into libsass a little over a year ago (around June 2014) and they were openly stating that it wasn't production-ready, and they were targeting (I think) August 2014 for some features.]

o_____________o 11y ago
Thanks for the overview, that was about my timeline too. The other thing is that PostCSS just looks cleaner, extensible and more future-forward. cssnext+autoprefixer is awesome, for example. There's even a Sass-like DSL. I had been on Less for a long time, but some of its limitations bothered me.
xrstf 11y ago
<rant>Yeah I really love how I now not only need Node and npm, but also gcc to install/build a frickin' web project. Because f*ck the platform-independence we got with Node, who cares if a simple `npm install` takes 30 minutes to complete.</rant>
- pyre 11y ago
  Nothing is requiring you to use these tools, but as web projects become more and more complex we develop tools to deal with the complexity. You could just as easily ignore all of this and use server-side rendering in your language of choice.
- rubiquity 11y ago
  You would need GCC to install Node anyway. Not to mention the fact that you probably have GCC or Clang already anyway...

rattray 11y ago

@mdo recently tweeted that v5 will likely be in PostCSS: > Oh, btw—Bootstrap 4 will be in SCSS. And if you care, v5 will likely be in PostCSS because holy crap that sounds cool. https://twitter.com/mdo/status/591364406816079873 https://twitter.com/mdo/status/591364406816079873 EDIT: also, elsewhere on this thread, he mentioned: > Sass is really similar to Less, so it's an easier transition to make than jumping right to PostCSS.