Комментарии 9
— Добавляем 10 слоев и увеличиваем комплексность программы, чтобы упростить написание кода…
— Тратим большое количество времени на изучение и создание сложной системы, с помощью которой можно будет писать код всего лишь на 10% — 20% быстрее, и в итоге окупим временные затраты через пару месяцев — лет? Хотя из примеров я так и не понял как именно будем экономить время, ведь мы пишем столько же кода, только в краткой форме, но зато, используя более сложную логику. А логика ведь обычно и является самой время-затратной частью в написании любого кода
Таких инструментов очень много. Конкретно этот неизмеримо сложнее LESS/SASS.
Чем дальше от нэйтива, тем сложнее learning curve.
Такие инструменты становятся малопопулярными очень быстро.
Даже если некий разработчик возьмет этот инструмент, сделает как правильно, воспользуется лучшими практиками, но потом уйдет на другой проект/в другую компанию, проект сколлапсирует до состояния "переписать, нельзя поддерживать".
Как результат, вы получаете проект на старой малоизвестной технологии, разобраться в котором новому разработчику будет не под силу (да и не захочется) за ожидаемое от бизнеса время. Найти знающего эту технологию разработчика будет не под силу.
Чтобы выполнить задачу в срок, придется писать костыли, использовать поверхностное знание инструмента, что превратит код в мешанину. Все лучшие практики первого программиста потеряются или затеряются в костылях.
P.S.: А еще синтаксис похож на регулярные выражения. Шуток про них предостаточно.
Согласен со всем, что остальные комментаторы сказали выше по поводу читаемости и поддерживаемости такого подхода, но хочу добавить про идеологический вопрос.
Основное преимущество атрибута class — возможности отделить семантику от представления. На уровне HTML указывается, что это за элемент ("блок комментария", "элемент меню", ...), а на уровне CSS конкретизируется, как он должен выглядеть ("черная рамка", "отступ 2 пикселя", ...).
Ваш же подход это преимущество отвергает. По сути, вы переизобрели атрибут style, только с самопальным синтаксисом.
Народ использовал классы раньше потому что тогда не было такого распространения компонентов и классы это был возможно единственный способ не дублировать стили при добавлении какой-нибудь кнопки в разных местах.
А теперь с появлением компонентного подхода какой смысл в классах? Нет больше той проблемы с дублированием зато есть неудобства в лишних переключениях между тегами и стилями и необходимость придумывать имена для классов.
Вопрос — если у меня есть уже компонент кпопки или какой-то карточки, зачем мне дополнительно создавать класс "button" или "card" и выносить стили в отдельный файл, или в отдельное место в том же файле? Или вот, например, когда мне нужно что-то изменить в дизайне. Я уже зашел в файл компонента <Card/> или <Button/> с целью изменить или поправить дизайн — зачем мне еще раз видеть на теге класс "card" и затем переходить в другое место для того чтобы увидеть стили? Почему бы просто не писать стили прямо рядом с тегами если мы уже разбиваем верстку на атомарные компоненты?
Далее. У нас есть обычная кнопка и, скажем, кнопка с выпадайкой (иконкой, бэджиком, счетчиком — куча вариантов). Это отдельный компонент со своим поведением, но в большей части визуальных стилей он совпадает с обычной кнопкой. Общее надо куда-то выносить. Или в классы, или в какие-то миксины.
Похоже на очередную попытку НЕверстальщика заново изобрести вёрстку.
Ребята, пожалуйста, прежде чем пытаться выпилить css из нашего бренного мира, разберитесь в том, как им правильно пользоваться, и тогда вы поймёте, что все потенциальные проблемы легко решаемы. Давно придумано и проверено временем множество методологий и инструментов, для проектов любой сложности. Почему бы не поисследовать рынок, вместо того, чтобы изобретать свой велосипед. Возможно, если бы вы знали тот же Emmet, то и желания создавать MN у вас не появилось бы.
Страшно представить, как будет выглядеть исходный код более-менее оформленного дизайнерами проекта. MN сгодился бы, разве что, для построения шаблонов. И все равно, лучше уж использовать инлайн стили и специально придуманный для них атрибут style. Код будет подлиннее, зато в 100 раз понятнее.
А ещё лучше сделать небольшое усилие, и стилизовать все с помощью минимального набора классов.
Atomizer vs Minimalist Notation (MN)