Mark Node Sass as deprecated
nex3 opened this issue · comments
After much discussion among the Sass core team, we've come to the conclusion that it's time to officially declare that LibSass and the packages built on top of it, including Node Sass, are deprecated. For several years now, it's been clear that there's simply not enough engineering bandwidth behind LibSass to keep it up-to-date with the latest developments in the Sass language (for example, the most recent new language feature was added in November 2018).
For the past couple years, we've all been hoping that this pattern might turn around. Marcel's excellent work porting code from Dart Sass looked promising, but it hasn't translated into concrete support for the latest Sass features or major compatibility bugs. At the same time, LibSass's slow pace has begun causing substantial concrete problems for Sass users. We regularly see users confused as to why plain-CSS min() and max() don't work and assuming Sass as a whole is at fault, when in fact it's only LibSass that doesn't support that feature. And we've been unable to move forward with the slash-separator proposal because of LibSass's lack of support.
All of this means that it's time to start directing users away from LibSass, standardizing on Dart Sass as the primary (and for now the only) recommended language implementation.
What does "deprecated" mean?
The term "deprecated" carries a lot of weight in the programming community, and provides a strong signal that users should start planning to move away from a piece of software. That said, it's not rigorously defined, which leaves us a lot of flexibility to determine exactly what it means to us. Most of that is in the hands of the existing maintainers of LibSass, Node Sass, and related tools.
The core team's hope is that the maintainers of these packages can continue to maintain them at least enough to fix critical bugs and address any security issues that come up. In this case, "deprecated" would mean "we don't expect to release any new features or support new CSS specs, but existing SCSS will continue to run." Ideally you would provide a time horizon where maintenance is assured, giving users a clear timeline to migrate away.
What about portability and performance?
LibSass today has two major benefits over Dart Sass:
-
Portability: since it's written in C++, it's easy to embed LibSass within other programming languages and provide a native-feeling API.
-
Performance: calling out to LibSass via the C++ API is very fast relative to the speeds of code written directly in scripting languages. In particular, this means LibSass is substantially faster in JavaScript than Dart Sass-compiled-to-JS (although it's comparable to Dart Sass's command-line executable).
We're working on addressing both of those with the Sass embedded protocol, which runs a Sass compiler as a subprocess that communicates with the host language via message-passing. The embedded protocol supports all the features of a native Sass API, including the ability to define custom importers and Sass functions, while also providing the high performance of the CLI app. Dart Sass has already implemented the compiler side of the embedded protocol, and we intend to launch a JavaScript host for it within the next couple months.
What do we do now?
The immediate next step is to coordinate how we want to mark the LibSass and Node Sass repositories as "deprecated". This should include adding a notification to a prominent spot in the READMEs and, for Node Sass, deprecating the npm package. I also plan to write a post for the Sass blog, which I'd like to post concurrently with these deprecations landing.
Thank you
Finally, I want to thank everyone who's put so much time and energy into LibSass and Node Sass over the years. It will always be a towering achievement, and Sass's popularity outside of the Ruby community is undoubtedly due in large part to its existence. Many people have tried to implement Sass only to find that the language is much deeper and more complex than they expected, and LibSass alone among all of those implementations managed to become fully-featured enough to provide real value for thousands if not millions of users. You deserve to be proud of that work, and I hope you still consider yourselves part of the Sass community going forward.
Maybe it's time to double down on this one then?
dart-lang/sdk#32894 (comment)
@bertyhell dart2native already gives very good performance and very nice, dependency free executables for linux, macos and windows.
I wonder what will be the path for platforms where dart does not run? (like dart-lang/sdk#10260)
I wonder what will be the path for platforms where dart does not run? (like dart-lang/sdk#10260
@saper https://www.freebsd.org/doc/handbook/linuxemu.html ??
I wonder what will be the path for platforms where dart does not run? (like dart-lang/sdk#10260
@saper https://www.freebsd.org/doc/handbook/linuxemu.html ??
For that, you'd need Linux node running etc. which defeats the point. I guess we have stick with dart-sass pure JavaScript npm package, with dart2native being out of reach.
@saper I'm not sure I understand. According to that documentation:
FreeBSD provides binary compatibility with Linux®, allowing users to install and run most Linux® binaries on a FreeBSD system without having to first modify the binary
Do you mean you have tried using a Linux executable produced by dart2native on freebad and it doesn't work with Freebsd's Linux emulation?
@saper As an learning exercise I tried this out and mostly got a Linux dart2native "executable" working on FreeBSD with it's linux compatibility layer.
I expect that someone who (unlike me) actually knows how the dart2native wrapper works with it's bundled snapshot could get this working properly.
Thank you @maks, much appreciated. I'll comment on the gist.
For how long will node-sass issue maintenance releases to support new node releases?
There are no immediate plans to stop support node releases. We're working on a v5 release to bump dependencies, drop legacy engine support, and add support for node 15.
I hope this project will be revived in the future. Dart Sass is extremely slow compared to this (the non-VM implementation)