Comments 33
В чем смысл sass при наличии less, stylus и postcss — никогда не понимал. «Ура, мы додревнее легаси, которое не умеет медиа-запросы в миксинах»? И да, libsass под виндой — боль.
Windows для разработки — в принципе боль. А по поводу SASS, то он мощнее LESS и Stylus.
Ну, например, в SASS полноценные циклы и операторы if-else. Собственные функции можно определять непосредственно в коде SASS. Есть карты (map), они удобны для объединения параметров вместо использования нескольких переменных.
Насчет простоты соглашусь, сам стараюсь держать стили простыми. Но иногда попадаются задачки типа генерации классов или стилей в зависимости от каких-то условий. Вот тогда всякие if-else в помощь)
Порядка 90-95% стилей спокойно пишется и без них, но вот в оставшиеся 5-10% обходиться без них неудобно.
Я сам начинал с LESS-а — это очень хороший шаг в сравнении с нативным CSS, и все-таки неполноценность его ощущается.
С первой частью согласен (но рабы на галерах кровавого энтерпрайза не имеют выбора), а со второй — не очень. Циклы — это мило, но на практике за 10 лет вебдева они мне пригодились только один раз, и я спокойно их сделал в less. А вот неполная поддержка синтаксиса CSS в 2016 году — это уже нехорошо как-то.
(но рабы на галерах кровавого энтерпрайза не имеют выбора)
Я бы не стал всех разработчиков на C#, F# и проч. грести под одну гребёнку.
А вот неполная поддержка синтаксиса CSS в 2016 году
Тут могу чего-то не знать. В чем она выражается?
При чем тут C# и F#? Я в жизни на втором ни строчки не написал, но на работе у всех винда без права выбора.
Тут могу чего-то не знать. В чем она выражается?
Попробуйте сделать миксин с media-query внутри.
на работе у всех винда без права выбора.
А, вы об этом. Ну, немножко печально. У нас Linux/Mac/Win, кому как удобно.
Попробуйте сделать миксин с media-query внутри.
Хм, а в LESS так можно?
Я потому и сказал «кровавый энтерпрайз»:)
В LESS можно. Я согласен, кейс не очень частый… примерно как потребность в циклах и if-ах;)
Просто никогда такого не требовалось)
А с этим есть проблемы? Вот пример в Susy, постоянно этим пользуюсь
Ура, мы додревнее легаси
Именно в этом и смысл поста. Они переехали на Dart, чтобы быстрее развиваться и выглядеть современно.
Ваш вопрос можно перефразировать: в чем смысл less, stylus и postcss при наличии sass?
Именно в этом смысл поста.
Ага, переписать с одного экзотического языка на другой, еще более экзотический. Отличная идея!
в чем смысл less, stylus и postcss при наличии sass?
Я вам расскажу: в том, чтобы не тащить на фронтенд ruby, dart, C и прочее. Less почти сразу переписали с того же руби на js именно по этой причине. stylus сразу писали на js. Ну у postcss своя атмосфера парадигма.
Все, что не написано на джс, из фронтендерского тулбокса рано ило поздно выпадет, как всякие странные сборщики/минификаторы на php, python, .net и т.д. Если бы не emscripten (а еще синдром утенка), libsass бы не спас sass из Леты.
Я вот sass не пользуюсь именно по причине его сборки. Как минимум раз в месяц возникали проблемы с libsass на билд-сервере. Ладно там phantomjs требует сишных либ и node-gyp, но зачем они препроцессору стилей?
Всё, что мне нравится в LESS по сравнению с SASS — это data-uri.
В посте как раз и написано, что команда понимает необходимость поставки пакета на чистом JavaScript, поэтому выбрали Dart, который транслируется в JS.
Это такой же «чистый js» как libsass собранный emscripten. Формально — JS, а на деле требуется ставить отдельный тулчейн и знать посторонний язык.
Ну всё же они теперь могут сделать npm-модуль и туда поместить js-бандл без зависимостей от внешних сишных либ. Хотя бы так.
А js сгенерированный из dart всё же лучше js сгенерированного из C
Читайте статью. Там все объясняется.
1) Нет. Emscripten это слишком низкуровневый интерпретатор. Dart изначально строился с заделом на удобную трансляцию в JS. Поэтому генерируемый им JavaScipt будет проще и оптимальнее, чем чересчур абстрактный LibSass+Emscripten
2) Для использования тулчейн ставить не надо. npm install dart-sass и готово. Для разработки конечно же придется, но удобство для контрибьюторов не так важно для основных разработчиков, как их собственное.
и каждый следующий парсер все равно надо подгонять под ruby-sass, потому что каждый раз проблемы: libsass до сих пор лажает с упомянутыми @extend
Напишите issue разработчкикам, расскажите как надо, а то они глупые, не знают как разрабатывать.
Судя по исходному коду, парсер там не самая большая часть. Намного больше занимает собственно процес трансформации SASS -> CSS
Интересно, они не думали о выборе в сторону Go? Ведь это более лёгкий для работы аналог C, при этом всё ещё позволяющий писать быстро работающий код.
Анонсируем Dart Sass