Hacker News Reader

Comment by ramesh31 | Hacker News Reader

The killer for SASS nowadays is CI. You're either using the (ancient, slow) Ruby implementation of SASS, or node-sass which requires a native binary build and causes headaches across environments. Furthermore, with Post-CSS, the feature set of SASS has been completely subsumed by the latest CSS standard. There's really no good reason to use it anymore.

View on HN

You should really be using the dart-sass[0] build (just `sass` on npm). None of the headaches of native binaries or using ruby, its pure JavaScript (its a dart codebase transpiled to JS). It is very fast.

[0]: https://sass-lang.com/documentation/#older-versions

>[0]: https://sass-lang.com/documentation/#older-versions

This is awesome, really glad to see things have progressed from the node-sass days. Might have to give it another look.

It's Sass, not SASS.

The native libsass is much faster. The headaches come from people trying to distribute binaries and libraries through NPM.

If we're being pedantic technically it's npm and not NPM ;)

Oof. I did not know this one.

> npm (originally short for Node Package Manager)

Acronyms can make sense to switch case, but initialisms... en-pee-em... I guess it happens. I originally was introduced it as Node Package Manager, but I'm gonna make an effort to correct this now.

For large apps yes; all Sass compile options are slow with embedded Sass being the least slow BUT:

Does your tooling even support embedded Sass?! Vite does not. Our version of webpack does not.. The Cenobites would LOVE Sass; never ending performance pain.

Reply on news.ycombinator.com