Статьи

Знакомство с LibSass

LibSass становится все более популярным с каждым днем. Не проходит и дня, чтобы кто-то не утверждал, что он с гордостью перенес свою кодовую базу в LibSass. О, круто.

Вы чувствуете себя немного потерянным? Не совсем уверен, что такое LibSass, как он работает и в чем основные отличия от оригинального Sass ? Ну, не беспокойся, мой друг, я тебя покрою.

Прежде чем объяснить, что такое LibSass, давайте сначала вспомним, что такое Sass . Sass — это препроцессор CSS, написанный на Ruby. Чтобы использовать Sass, вы должны установить его на своем компьютере как гем (пакет Ruby). Затем вы можете взаимодействовать с Sass либо из интерфейса командной строки (CLI), либо с помощью приложения, такого как Prepros .

LibSass — это порт Sass, написанный на C / C ++. Видите ли, Ruby не самый быстрый язык на земле. И это оказывается довольно медленным, когда дело доходит до Sass.

«Ruby — не один из самых производительных языков в мире, если не сказать больше», — Камиль Белавский

Я не являюсь разработчиком на Ruby, я не могу точно сказать, почему; возможно, запись в файл не так эффективна, как могла бы быть, честно говоря, не знаю. Но по какой-то причине Ruby Sass работает медленно, а в массовых проектах — еще медленнее.

Это дошло до того, что некоторые люди устали от отставания в производительности и решили начать писать Sass на C / C ++, чтобы ускорить время компиляции. Они придумали LibSass .

Вы не можете использовать LibSass сам по себе: вам нужна оболочка. Например, Node-Sass — это оболочка NodeJS для LibSass. Это позволяет вам использовать Node-Sass для компиляции вашего Sass из Node с использованием LibSass внизу.

Node-Sass на нпм

Также есть SassC , Perl-Libsass , PHP-Sass и даже Ruby-LibSass , и все они используют LibSass. Однако эти последние примеры не совсем актуальны, поэтому мы чаще используем Node-Sass.

Подводя итог, можно сказать, что LibSass — это порт C / C ++ оригинальной программы Sass, написанной на Ruby. Он предназначен для упаковки, как Node-Sass, чтобы использовать Sass из среды Node. Основная цель: быть невероятно быстрым по сравнению с оригинальным Sass.

Итак, мы знаем, что такое LibSass. Мы знаем, что LibSass должен быть таким же быстрым, как робот-единорог-радуга . Хорошо. Так почему бы нам всем не использовать LibSass прямо сейчас?

Основная проблема с LibSass состоит в том, что он отстает от оригинальной реализации Ruby, когда дело доходит до функций. На момент написания, LibSass 3.1 полностью совместим с Sass 3.3, однако многие функции из Sass 3.4 по-прежнему недоступны. Например, LibSass упускает использование селектора ссылок ( & ) в SassScript (возможность читать и обновлять его на лету с помощью функций и тому подобного).

К счастью, разработчики ядра Sass решили подождать, пока LibSass наверстает упущенное, прежде чем перейти к Sass 3.5, поэтому обе версии должны быть вскоре синхронизированы. Тем не менее, версия Ruby всегда будет основной версией: патчи и выпуски всегда будут сначала размещаться на Ruby Sass, а затем внедряться LibSass.

Здесь наступает момент, когда вы должны решить, какой движок Sass вы хотите запустить: оригинальный Ruby Sass или новый LibSass? Как и все в нашей области, это зависит .

В общем, я бы порекомендовал LibSass, потому что он, как правило, быстрее, чем Ruby Sass, а скорость — это все, что есть в этом мире. Однако, если вам нужно, чтобы Sass делал что-то сумасшедшее, требующее новых функций, которые еще не добавлены в LibSass, Ruby будет лучшим выбором.

Чаще всего вы обнаружите, что дело не в том, чтобы выбрать компилятор Sass для нового проекта, а в том, чтобы переосмыслить тот, который вы уже используете, чтобы он соответствовал вашей ситуации. Если вы работаете над средне-крупномасштабными проектами, у вас может возникнуть время компиляции в диапазоне от 2 секунд до 30 секунд (да …) с Ruby Sass. Это может быть хуже с сильными логическими зависимостями, такими как Compass .

В этот момент вы устали терять 25 минут в день, ожидая компиляции Sass, и всерьез подумаете о том, чтобы отказаться от некоторых функций, чтобы набрать скорость. В этом случае LibSass выглядит как гигантский кекс в форме котенка, а Ruby Sass больше похож на старое и сухое печенье …

Чтобы помочь вам решить, можете ли вы портировать всю базу кода на LibSass, я настроил проект Sass-Compatibility . Sass-Compatibility намеревается перечислить все основные несоответствия между различными движками Sass (в основном Ruby Sass 3.2, Sass 3.3, Ruby Sass 3.4 и последний LibSass). Я недавно представил проект в SitePoint , если вы хотите наверстать упущенное.

Проект Sass-Compatibility

Примечание : Sass-Compatibility использует SassMeister для запуска своих тестов. SassMeister использует Node-Sass для запуска LibSass. Однако Node-Sass еще не совместим с LibSass 3.1 (хотя это должно произойти в ближайшее время ), что означает, что результаты Sass-Compatibility для LibSass выглядят хуже, чем на самом деле.

Вот и мы, ребята. Я надеюсь, что эта статья помогла вам понять, что и почему в LibSass.

В настоящее время мы находимся в странной ситуации, когда LibSass чрезвычайно удобен благодаря своей скорости, но не предоставляет всего того, что делает Ruby Sass, поэтому его нельзя безоговорочно принять. Это все скоро успокоится, когда обе версии станут полностью совместимыми.

Теперь, поскольку LibSass намного быстрее, чем Ruby Sass (и я думаю, что, как бы ни старались разработчики ядра Ruby Sass, так будет всегда), я не знаю, какое будущее может быть у реализации Ruby. В какой-то момент я не думаю, что будет иметь смысл использовать Ruby Sass, если он медленнее, если только он не приносит что-то дополнительное на стол. Как говориться: подожди и посмотри.