Как стать автором
Обновить

Комментарии 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 код.

Я прекрасно понимаю, что сокращения - это спорная тема. У них есть свои плюсы и минусы...

Кому-то они вообще не зайдут чисто эстетически, и это тоже норм

Да, наверное, найдутся люди, которым нравится писать обфусцированный код. Спорить тут не о чем, карательная психиатрия поможет и им тоже.

Изобретение очередного эсперанто чисто ради самого эсперанто когда все отлично общаются на своих языках.

Для паролей - точно пойдёт :)

Если бы "все отлично общались на своих языках", то не появились бы разные подходы, такие как: БЭМ, Atomic и т.д.

Как опыт для резюме пойдет, как юзабельная вещь в текущих реалиях врятли.
Больше походит на то что сами придумали проблему, сами решили.

До сих пор не понимаю что все плачут над написанием этих стилей и пытаются максимально усложнить себе работу, прикручивают всякие 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 названия классов или запоминать логику сокращений

Ваше право. Хотя вполне логично однажды разобраться с сокращениями и дальше получать профит от них)

Вот ты выучил всё это, потом приходишь на проект без mlut и за пару месяцев всё забываешь.

Плюсую за модули, что может быть проще

Лучшие решения уже давно есть (BEM, да хотя бы SMACSS). А здесь только жалко зря потраченное время на то, чем никто не будет пользоваться.

Что вы такого стилизуете, что вам приходится использовать такое везде? Неужели написать обычный класс и не лить грязь в разметку намного хуже?

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

Стандартный путь в верстке примерно таков:

  1. пробуешь верстать без методологии и вскоре понимаешь, что все плохо

  2. пробуешь БЭМ. Сначала все норм, но вскоре понимаешь, что БЭМ-стек появились не просто так и все на самом деле сильно сложнее, чем добавление _ и - в названия классов

  3. пробуешь CSS-in-JS или scoped-решения (те же CSS-модули). Возможно они решают твою задачу, а возможно, их минусы начинают перевешивать плюсы. Или вообще не пробуешь, если это невозможно в твоем стеке

  4. пробуешь Atomic CSS (либо сразу третьим пунктом) и приходишь к моему докладу)

Жаль нет кармы, поставил бы тысячу минусов такому подходу, как тактически, так и стратегически ;(

А будут ли какие-то аргументы, с учетом того, что успели обсудить выше?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации