4 ms·
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 c
by ramesh31 4y ago
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.
- toastal 4y agoIt's Sass, not SASS. The native libsass is much faster. The headaches come from people trying to distribute binaries and libraries through NPM.
- jbenner-radham 4y agoIf we're being pedantic technically it's npm and not NPM ;)
- toastal 4y agoOof. 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.
- no_wizard 4y agoYou 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 https://sass-lang.com/documentation/#older-versions
- ramesh31 4y ago>[0]: https://sass-lang.com/documentation/#older-versions 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.
- Rapzid 4y agoFor 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.