Comments 20
@:ah_O1_h => (any-hover) { .@:ah_O1_h:hover { opacity: 1 } }
C-$myVar?#333 => color: var(--ml-myVar, #333)
@s_Ml1svw => @supports (margin-left: 1svw) { .\@s_Ml1svw { margin-left: 1svw } }Как генератор паролей пойдёт. В остальном - write-only код.
Изобретение очередного эсперанто чисто ради самого эсперанто когда все отлично общаются на своих языках.
Для паролей - точно пойдёт :)
Как опыт для резюме пойдет, как юзабельная вещь в текущих реалиях врятли.
Больше походит на то что сами придумали проблему, сами решили.
До сих пор не понимаю что все плачут над написанием этих стилей и пытаются максимально усложнить себе работу, прикручивают всякие tailwind/bootstrap или изобретают велосипеды, когда даже ванильный css сильно продвинулся. У вас ограничение стоит на использование букв? Или нравится так часто подглядывать в документацию - этакие вуайеристы документаций, когда вместо того чтобы потратить 1-2 минуты на написание класса со всеми свойствами, мы тратим 10 на просмотр документации как описать это свойство в classname.
Повторюсь, что если бы с написанием стилей все было легко, то не появились бы разные подходы и инструменты.
Ограничения на буквы нет, но так удобнее. Вряд ли кто-то будет спорить, что удобнее написать:
npm i -D mlut, чем npm install mlut --save-dev
И стоит понимать, что это инвестиционная история: 1 раз приложил усилия, разобрался в этих сокращениях, и потом всю оставшуюся практику наслаждаешься версткой) В этом случае, постоянно смотреть в доку не потребуется
Очевидно, что описанная система не взлетит. Почему взлетел тайлвинд? Разумеется, там комплекс причин, но одна из главных - супер-низкий порог входа. Это как в своё время было с jQuery: cмотришь на страничке get started буквально первый же пример и понимаешь его. Дальше по ходу дела всплывёт много нюансов, но базовая идея становится ясна сразу и интуитивно.
Здесь же мысли примерно такие:
боже что это? ничего не понятно...
причем о смысле происходящего речь вообще не идёт
объясните хотя бы, как эти хэши на отдельные токены разобрать?
даже разбираться не хочу
ладно, посмотрим доку
так-так... угу-угу...
нет, точно не хочу.
Со многим в статье не согласен. Особенно смешно, как автор относит плохо читаемую разметку к "мифам", и тут же усовершенствует её так, чтобы стало ещё лучше, ещё удобнее.
Тем не менее, плюсов я отсыпал. При всём моём несогласии, статьи с таким уровнем погружения нам нужны. Они помогают понимать, что происходит в головах людей с отличающимся мировоззрением.
Добавлю, что у меня нет цели "захватить мир" с mlut или "убить" Tailwind. Я прекрасно понимаю, что инструмент скорее нишевый и не имеет такого потенциала by design
Хотя про взлет: в свое время, как-то нашлись N тысяч человек, которые заценили и взяли в прод Tachyons и Atomizer. Хотя там тоже используются сокращения, а mlut оба инструмента сильно превосходит. Возникает закономерный вопрос: "чем я хуже"?)
причем о смысле происходящего речь вообще не идёт
объясните хотя бы, как эти хэши на отдельные токены разобрать?
Про это в статье вроде целые разделы есть. Хотя возможно, тут имеются в виду мысли того, кто смотрит инструмент
Миф в том, что разметка не читаемая только с первого взгляда. Как только разберешься - все становится норм. Вы, например, смогли отгадать свойства утилит в интерактиве? Я читал этот доклад 4 раза и почти всегда, люди угадывали их не дольше 5 секунд. Хотя в алгоритмах еще толком не успели разобраться)
P.S. за плюсы спасибо)
Я начал было писать ещё какие-то аргументы, но быстро понял, что дело в другом.
Самое главное: у вас лично - своеобразная, отличающаяся от большинства, система ценностей. Вы бьетесь за фантомные цели, которые другим кажутся маловажными. И наоборот, готовы жертвовать чем-то, что другим важно. В условиях, когда цели принципиально разные, бессмысленно обсуждать детали реализации.
Пример 1.
Удобочитаемость принесена в жертву ради консистентного нейминга. Но в реальности примерно все предпочтут интуитивно понятный синтаксис, даже если в 5-10% случаев он будет допускать разные трактовки. Да, это минус, но не критичный. А вот сношать себе мозг 100% времени ради светлых теоретических идеалов - это критично.
Пример 2.
Как я понимаю, много сил вложено в JIT. Наверное, чисто технически это значительное достижение. Но в реальной повседневной практике примерно всем плевать. Я уверен, что большинство даже не задумывалось об этом.
И в конечном итоге аргумент "можно один раз разобраться с сокращениями и дальше пользоваться их преимуществами" разбивается не столько о необходимость тратить время, сколько об отсутствие преимуществ в глазах медианного разраба.
По большей части верно, только что цели "фантомные" - слишком категорично сказано.
Сам JIT не так уж много усилий потребовал, кстати: JIT + CLI - всего около 400 строк на typescript) Вся сложность там в генераторе утилит на Sass - поэтому он и называется "бэкендом". JIT сегодня - это база для Atomic CSS инструмента. И "детали реализации" мне было бы интересно обсудить, поскольку не вижу причин, почему mlut не достоин получить, хотя бы 1/10 внимания, которое получили Tachyons.
Повторюсь, что "медианный разраб" - не моя аудитория. Я не беспокоюсь, что ему не зайдет. Могу привести хороший пример подобного явления. Сегодня есть куча фронтенд-фреймворков: 1 лучше другого. Но почему-то, уже N лет существует такой инструмент как Elm. И не просто существует, а у него 7к+ звезд и 18к подписчиков в твиттере! Хотя с первого взгляда, "медианный разраб" точно так же скажет: "зачем это, если есть react", "ничего непонятно" и т.д.
Отчасти правда, только проблема в том, что фронтенд не ограничивается SPA на JS-фреймворках)
Неправда. После сборки, минификации и сжатия обычный CSS будет весить меньше
После аглификации CSS - возможно, но опять же: ее далеко не в каждую сборку добавишь
Простите, но я лучше вспомню CSS-проп, чем буду учить ваши opinionated названия классов или запоминать логику сокращений
Ваше право. Хотя вполне логично однажды разобраться с сокращениями и дальше получать профит от них)
Плюсую за модули, что может быть проще
Лучшие решения уже давно есть (BEM, да хотя бы SMACSS). А здесь только жалко зря потраченное время на то, чем никто не будет пользоваться.
Что вы такого стилизуете, что вам приходится использовать такое везде? Неужели написать обычный класс и не лить грязь в разметку намного хуже?
Повторюсь, что если бы с написанием стилей все было легко, то не появились бы разные подходы и инструменты.
Стандартный путь в верстке примерно таков:
пробуешь верстать без методологии и вскоре понимаешь, что все плохо
пробуешь БЭМ. Сначала все норм, но вскоре понимаешь, что БЭМ-стек появились не просто так и все на самом деле сильно сложнее, чем добавление
_и-в названия классовпробуешь CSS-in-JS или scoped-решения (те же CSS-модули). Возможно они решают твою задачу, а возможно, их минусы начинают перевешивать плюсы. Или вообще не пробуешь, если это невозможно в твоем стеке
пробуешь Atomic CSS (либо сразу третьим пунктом) и приходишь к моему докладу)
Жаль нет кармы, поставил бы тысячу минусов такому подходу, как тактически, так и стратегически ;(
Atomic CSS Deep Dive