Думаю я не единственный, кто через это проходил. Прошу поделитесь опытом.
Пол года назад, как я начал углубляться в мир WEB технологий и с тех пор нахожусь в поисках. Суть в том, что начав из простого HTML и CSS я стал замечать огромное количество лишних телодвижений, которые приходилось делать каждый раз. Это и копипаст ранее написанного кода и бесконечное дублирование одного и того же из минимальными различиями ну и наконец адская навигация между сотен строк разноцветных букв, а также несколько часовые затупиты из-за ошибки которую во всем этом хаосе попробуй найди.
Естественно, я начал искать пути автоматизации и упрощения этого процесса. Сначала SCSS, затем BEM подход, Gulpи какие-то примитивные плагины для разбивки ужасно бесконечной html простыни на какие-то модули. После этого шаблонизатор Pug, который перевернул мое представление о верстке с ног на голову. И уже мне стало мало возможности просто структурировать код и следовать принципам DRY, давай делать умные блоки ... Блин, думаю, както стремно все время писать бэм классы руками, а bem-tools как то не прет, давай выдумывать велосипед. А тут еще и pug mixin-ы в которых отсутствует скоуп между дочерними и родительскими блоками, из-за чего вылезает 20 новых преград на пути, чтобы поймать Дзэн и уйти в Нирвану, а значит и здесь нужен велосипед. А потом велосипед для велосипедов... В конечном итоге мои умные блоки становятся настолько умными, что скоро начнут меня посылать и ходить ночевать к друзьям))). А если серьезно то я понимаю, что на пути к упрощению читаемости, поддержки и переиспользования некой единицы кода, все время сворачиваю в сторону создания универсальной сущности которая запрограммирует сама себья. Потом понимаю, что иду не туда, более того через день-два сам увже не могу разобраться как оно все работает (о какой поддержке может идти речь), все удаляю, создаю новую папку и снова все по кругу....
Как вовремя остановиться, как увидеть грань между здравым смыслом и маразмом? Возможно, также, есть какие методические рекомендации по этой тематике?
Ну, я не могу сказать, что это ускоряло, так как, почти всегда или пропускал какой то закрывающий тег после чего долго и нудно исправлял или в конечном итоге приходилось сделать какие-то изменения и начиналась эпопея - пойди найди все места где это использовано, исправь и не сделай еще 100500 дополнительных проблем. Благо есть pug и такая проблема отпала сама по себе.
На мой взгляд нужно писать велосипеды, особенно на начальном этапе, да возможно сначала будет одно только непотребство, но в конечном итоге должно получится что-то стоящее и удобное, и да, все что может быть автоматизированно, должно быть автоматизированно.
PS Чтобы не писать руками бем классы я написал вот это, стало гораздо легче.
Видел твой велосипед днями на бэм форуме. Но там какой-то глюк и не получилось написать коммент. Я так понимаю, что основное отличие от bemto это видимость элементом своего непосредственного родителя (блока), а не только корневого?
Vasyl Kovbassa: Нет в bemto это тоже реализовано, но мне его синтаксис не зашел, поэтому я решил написать свой велосипед, я добавил к jade поддержку pug, плюс добавил некоторые дополнительные плюшки, например колбеки позволяют реализовать любые хотелки, например грид колонка выглядит как-то так: +e( 'col', {xs: '12', sm: '8', lg: '6' } )
а на выходе бем простыня)
Ну я тоже делал что-то подобное, но так +e( 'col', mods={xs: '12', sm: '8', lg: '6' } ). Чтобы не было путаницы. И все таки bemto мне больше понравился. Так ты говоришь что там элемент видит свой блок, а не общий? А как? Ато я чет не разобрался..
Вот скажите, вы действительно думаете что это +b('title', {e: 'article:my-name', t: 'h1'}) Title проще и читабельней чем просто тег H1 c классами ?, порой велосипеды не упрощают, а делают все наоборот :)))
Сергей Громов: Если вы пишите бэм код, то у вас нет выбора, либо так, либо писать json, потому что руками писать вообще не вариант, конечно в таком простом примере мой велосипед проигрывает, у меня есть другой пример:
Я просто облегчил жизнь себе и выложил в общий доступ может и другим пригодится, все добровольно и я не заставляю пользоваться, тем более, если вам кажется это избыточным и вы не видите плюсов.
Не совсем про верстку, но актуально!
А вообще помните для себя одну важную вещь: лучшее - враг хорошего! Ставьте себя на место человека, который впервые увидит ваш код, поймёт ли он что к чему достаточно быстро чтобы поддержать его? Если нет, то дальнейшее усложнение не нужно.
Спасибо почитаю.
относительно человека после ...
Как раз понимаю. Но есть одна проблема - свой код всегда понятен и прост как ясен день, особенно в момент написания, пока все еще в голове. И вот здесь нужен стоп-сигнал, чтоб прогудел, когда стрелка весов перевалит от здравого смысла к извращениям.
Поэтому и ищу литературу, где были бы установлении какие-то правила. Вот так - можно, так - уже не желательно, а так - не надо. Как в Бэм, к примеру. => Уникальный селектор каждому блоку - Бро. Уникальный селектор-модификатор для разновидности блока - тоже Бро. Один уровень вложенности - терпимо. Более одного уровня вложенности - совсем не Бро.
YAGNI
Думаю, что даже в такой параше кода, как веб, этот принцип вполне применим. В любом случае нужно потратить некое кол-во человеко-часов на выполнение вёрстки.
Делать этот процесс слишком умным - себе дороже. Ведь очень умные программы должны предвидеть слишком много юзкейсов, поддерживать собственный код в читаемом состоянии и обновляться вслед за зоопарком нодовских, обезумевший зверушек, меняющих мажорные версии раз в неделю.
Серебряной пули нет. Хоть утверждение высказано не по теме вопроса, но вполне подходит в качестве ответа.
С одной стороны хаос, с другой оверинжиниринг.
Понять же в какой мере нужно применять "средста автоматизации", а затем "средства автоматизации средств автоматизации" и т.д. можно только в условиях конкретного проекта: подготовленность команды, сроки, продолжительность поддержки и т.д и т.п.
Важно понимать, что каждый новый инструмент увеличивает порог входа в проект и приводит к затратам на поддержку этих инструментов. Затраты эти должны чем-то быть оправданы.
Вспоминаются рассуждения Стива Макконнелла, о том, что когда мы "пишем код", наша первая задача - борьба с его сложностью, и то решение лучше, которое проще для понимания. Если инструмент делает проект проще в целом, то это хороший признак.
Однако, сложность может быть не единственным критерием, в каждом проекте условия индивидуальные.
Мне БЭМ как-то вообще не зашёл. Пользуюсь Emmet, SASS, Gulp, HTML includes.
Остальное, как по мне для крупных проектов с серьёзным фронтэндом. В силу специфики занимаюсь я магазинами и визитками, так что большая автоматизация тут и не нужна.
Простой
