Вариант предварительного процессора CSS Vue CLI: dart-sass VS node-sass?

При создании нового проекта с помощью CLI (v3.7.0) существует возможность выбора между dart-sass или же node-sass компилятор.

Как они соотносятся друг с другом, чтобы быть более конкретными, чем заявлено в Vue Docs?

Совет по Sass Performance

Обратите внимание, что при использовании Dart Sass синхронная компиляция в два раза быстрее асинхронной компиляции по умолчанию из-за накладных расходов асинхронных обратных вызовов. Чтобы избежать этих издержек, вы можете использовать пакет волокон для вызова асинхронных импортеров из пути синхронного кода. Чтобы включить это, просто установите волокна как зависимость проекта:

npm install -D fibers

Также имейте в виду, что, поскольку это собственный модуль, могут возникнуть проблемы с совместимостью ОС и среды сборки. В этом случае, пожалуйста, запустите npm uninstall -D fibers решить проблему.

? Pick a CSS pre-processor (PostCSS, Autoprefixer and CSS Modules are supported by default): (Use arrow keys)
❯ Sass/SCSS (with dart-sass)
  Sass/SCSS (with node-sass)
  Less
  Stylus
Источник

3 ответа

Согласно официальному сайту sass-lang:

Dart Sass является основной реализацией Sass, что означает, что он получает новые функции перед любой другой реализацией. Он быстрый, простой в установке и компилируется в чистый JavaScript, что облегчает его интеграцию в современные рабочие процессы веб-разработки.

Dart-Sass работает быстро, если вы запускаете его внутри Dart-VM, но он говорит, что компилируется в чистый JS. Пакет npmjs dart-sass это просто скомпилированная версия, которая медленнее, чем node-sass или же native dart-sass,

Если вы ищете измерения, я рекомендую прочитать об этом здесь, есть образцы и разные номера:

Это первое измерение с использованием Dart Sass в качестве заранее скомпилированного нативного кода, и результаты обнадеживают. Это намного ниже порога в 100 мс для крошечных файлов, и он находится на одном уровне с SassC для большинства тестовых случаев. SassC по-прежнему лидирует для тестов со многими расширениями, хотя и незначительно, и для одного из наших реальных тестовых случаев (хотя Dart Sass ведет в других). Две реализации могут быть справедливо описаны как имеющие примерно одинаковую производительность в целом.

Dart Sass на узле все еще существенно медленнее, чем на Dart VM, и это относительное замедление становится более выраженным по мере того, как необработанный код Dart становится быстрее. Решения для этого, такие как [встроенный протокол][] или [поддержка WebAssembly][], становятся все более и более важными.

Мой личный опыт использования dart-sass пакет npmjs вместо node-sass(который js обёртка родного C библиотека) это что dart-sass намного (для меня по крайней мере в 50 раз, потому что у меня много больших файлов тем) медленнее, чем node-sass,

Источник

24.01.2021

Как написано в официальной документации node-sass на github , node-sass устарел .

Предупреждение : LibSass и Node Sass устарели . Хотя они будут продолжать получать обновления на неопределенный срок, мы не планируем добавлять дополнительные функции или совместимость с какими-либо новыми функциями CSS или Sass. Проекты, которые все еще используют его, должны перейти на Dart Sass.

Так что я думаю, было бы лучше выбрать dart sass, если вы планируете долгосрочную перспективу или хотите быть в курсе последних событий.

Источник

Node -sass может быть быстрее, чем dart-sass, но на момент написания этого dart-sass является единственной библиотекой, которая реализует @use правило, которое настоятельно рекомендуется @import. Согласно официальному сайту sass-lang:

Что случилось с @import? В@import Правило имеет ряд серьезных проблем:

  • @importделает все переменные, миксины и функции глобально доступными. Из-за этого людям (или инструментам) очень сложно сказать, где что-то определено.

  • Поскольку все глобально, библиотеки должны добавлять префиксы ко всем своим членам, чтобы избежать конфликтов имен.

  • @extend правила также являются глобальными, что затрудняет прогнозирование того, какие правила стиля будут расширены.

  • Каждая таблица стилей выполняется и ее CSS генерируется каждый раз, когда она @imported, что увеличивает время компиляции и дает раздутый вывод.

  • Не было возможности определить частные члены или селекторы заполнителей, которые были недоступны для последующих таблиц стилей.

Новая модульная система и @use Правило решает все эти проблемы.

Дополнительно, @importбудет постепенно сокращаться в течение следующих нескольких лет и в конечном итоге полностью удален из языка.

Чтобы быть в курсе лучших практик Sass, вам следует использовать dart-sass (т.е. sass).

Источник
Другие вопросы по тегам