Hacker News Reader

Comment by o_____________o | Hacker News Reader

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

View on HN

> 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.]

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.

<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>

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.

You would need GCC to install Node anyway. Not to mention the fact that you probably have GCC or Clang already anyway...

Nope, I'm on Windows. I don't need GCC (or any other C compiler for that matter) to install Node, but now I need one because some of my coworkers on Macs decided to throw every possible dependency they could find into the project.

I don't use it, so I don't know, but I'm just wondering, why is it necessary to use gcc to use libsass? Isn't there a PPA for it? Would a PPA be the proper way to distrib what sounds like a really valuable program? Thank you.

System level package management falls quite short of what you want for applications in a lot of ways still.

Different apps will want to specify and build against extremely specific and different versions of their dependencies, and developers will want to be able to change these versions without lots of organizational coordination between owners of dev/CI/stage/production environments.

Currently, this is solved by things like npm/bower/bundler/composer/maven/etc. etc. The code repository describes all the dependencies and they get installed just for that app, testing and deployment process simply incorporate the app's packaging tools.

However, for any dependencies which use native extensions, you tend to need to be able to compile those - across all your environments - which means having working toolchain everywhere.

Not that this is strange or hard in my opinion, but it seems to discourage people somehow.

I'm on Windows and I don't want to install Visual Studio just because of libsass...

Should the people that wrote libsass have decided whether or not to write it in C based on whether or not you would have to install Visual Studio to get it working on Windows? As a C library, it allows linking from several different languages, so maybe their motivations were getting a non-Ruby Sass implementation that could be used in whatever language you need it in. Maybe then the people that wrote the JS to link against the C library are the people that burdened you with this hardship then? Should every person that wants to use libsass from JavaScript be deterred against creating that JS library linking against libsass just because it might cause you some sort of "software installation hardship?"

I'm really confused what you feel the "ideal world" of your rant is. That the libsass people should have written it in JavaScript? How then would (e.g.) Python compile Sass? By installing Node and calling out to run the JavaScript libsass? Wouldn't that just lead to more people saying things like "Why should I have to install Node just to compile some Sass?" I'm sure the initial implementation of Sass being in Ruby was great for Rails developers because Ruby was already a part of their toolchain. For other projects that were not using Ruby though, Sass required an install of Ruby just for the purpose of compiling Sass.

I can't help but feel like the anti-native-extensions point of view is short sighted.

Why shouldn't we have optimized implementations of algorithms that we can share across various languages?

I generally agree with you sentiment -- but with js being within an order of magnitude of C -- it seems the likelihood of incompatibilities between the js version (that could run in rhino, nodejs and the browser for in-place use of sass over css) outweigh the benefits of maintaining a C version (especially as specifications evolve, and need to be ported to C).

Then again, having (at least) two implementations is one way to test compatibility and nail down unclear specs...

FWIW it is possible to ship a native node.js module that falls back to an emscripten version when a c++ compiler isn't available - see http://insertafter.com/en/blog/native-node-module.html for an example.

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.

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.

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

libsass is very strange. It must be statically linked and it requires copyright assignment for contributions.

The LICENCE file looks like standard MIT to me. Where did you find this info?

Here: 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.

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?

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.

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?

would you mind sharing what were the significant issues with LESS?

I'm using LESS and just wondering what I might be missing.

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.

(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.

I wouldn't say chasing the "latest and greatest" is always the case when trying the new fads. A lot of times it comes down to 'you don't know what you don't know'. I was doing fine using regular old CSS, and then I came upon some SASS examples, and holy cow, you can make variables, mixins, and do math? I never knew that was even a thing and it certainly wasn't a problem I was having with CSS, but I am glad I found it and now use it and its luxury.

Because PostCSS allows you to write future spec compliant code, unlike sass. It's like writing ES6 then using a transpiler to generate ES5.

CSS shouldn't be so complicated. It's all about selector simplicity, scalability. If you make too complicated sass, css or less, you're doing probably wrong.

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.

>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.

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.

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.

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.

Yes, I tried using the React filter and failed. I switched to 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.

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

@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

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.

Reply on news.ycombinator.com