Войти с помощью github
Форум
/
Что останавливает меня от использования bem-tools
Александр Баумгертнер
archive
poll
community
asktheteam
bem-tools
Ребята и девчата! Готовлю статью для Хабра по мотивам моего доклада
Alex baumgertner bem_in_small_projects
from
Alex Baumgertner
Нужны ваши отзывы, что останавливает вас от использования bem-tools. Спасибо!
Комментарии: 78
Поможем Саше с опросом!
Мы не используем bem-tools потому что сама идея сборки html из готовых блоков и bem-tools в частности, абсолютно непригодна для небольших проектов и компаний. Абсолютно.
Мы очень любим bem и пишем всё по bem, но только руками.
Вы просто живёте немного в другом мире и вам не понять как это - когда в 10 утра приходит макет (разумеется совершенно нового проекта, никак не связанного с какими-либо несколькими сотнями сделанных ранее), а через 4-6 часов уже надо показывать прогресс клиенту, а в конце дня - выкатывать на продакшен.
А интегрировать его возможно будут. А может и нет - оставят html. А может вставят в kohana, codeigniter, etc. А может клиент сам вставит его внутрь своего сайта. А может и правки сам сделает. Или менеджер клиента.
Кстати последнее не останавливает нас от использования sass и даже grunt со сборкой. Тут мы менеджеру можем рассказать и объяснить что как. Но сборка из библиотеки блоков - это полная утопия. Все эти доклады про то как надо писать код маленьким студиям, от лица тех кто работает в студиях больших или над несколькими проектами... вы просто не понимаете о чём говорите.
У нас десятки, сотни совершенно разных, никак не связанных друг с другом проектов. Не имеющих ничего общего в дизайне. Ничего. Написанных на разных движках, ведь сайт может просто прийти от клиента. На битриксе скажем. И что мне теперь - писать библиотеку блоков под новый проект, создавать bem-шаблоны под все шаблоны битрикса, ну ладно, хорошо пусть там wp, или даже kohana и свои шаблоны - напишем под них всё? Под каждый проект напишем библиотеку блоков? А потом под каждый будем модификаторы делать вместо тоого чтобы например просто заменить какой-то блок в каком-то шаблоне?
Кто будет оплачивать всё это время?
Кто будет работать со студией которая вместо того чтобы заниматься делом, будет делать какую-то совершенно бесполезную в будущем библиотеку блоков для проекта. Всё равно через пару лет будет полный редизайн делаться сайту, это традиция же у мелкого-среднего бизнеса.
Мы не можем позволить себе тратить недели только на написание новых блоков вместо того чтобы заниматься работой. Большие компании - могут. Да и они не тратят время - а расписывают свой единственный большой проект.
Bem-tools абсолютно не пригоден для небольших аутсорс-компаний, нам нужна библиотека сниппетов, готового html+css+js кода которые можно просто скопировать в новый проект и вручную отредактировать как нужно. Собственно сами уже начали такое писать, на основе своей старой билиотеки наработок (там не по bem наработки, а просто заготовки с разных проектов, я скидывал их Лене Глуховой) и ваших скомпилированных примеров из bem-bl. Харисов писал что Яндекс планирует такую библиотеку в мае начать публиковать, но пока её нет.
Хорошо, вы сейчас скажете - а давайте вы хоть на тех проектах что у вас часто повторяются, где делаются близнецы-братья, будете bem-tools использовать, у вас же есть такие проекты? Ага-ага. Ну вот есть у меня например серия лендингов Аэрофлота, 17 штук на текущий момент. Похожи? Очень. Применимы ли там bem-tools? Абсолютно не применимы. Потому что в реальной жизни приходят правки, приходят задачи вида "а добавь на этот лендинг подвал с текущего сайта Аэрофлота, там ещё есть попап Live-чата - его тоже перенесите". Потому что разработка быстрая, очень быстрая, это когда правится уже сразу на ftp, на продакшене. Потому что даже если нужно (а оно часто нужно) скопировать блок с другого проекта с вариацией, мы не будем пилить модификаторы на файловой системе, а просто внесём правки.
Поймите, bem-tools - это для Яндекса. Для Mail.ru, Для HH. Для других мега-компаний, где по сути один мега-проект. Где всё друг от друга зависит. Для есть сквозные блоки по всем проектам.
В остальном мире - этого нет. Там все сайты полностью независимы друг от друга. И даже просто по файловой структуре никто блоки раскладывать не будет.
Как писал Харисов - блоки в одном файле. Другого обычным проектам не нужно. Им bem-tools и всё остальное - не только не помогут, но будут мешать работать.
Пользуюсь enb под линуксом
html очень грустно руками набивать, хотя бы по причине устаревания вёрстки. Поэтому мы с Васей в своё время пришли к простому шаблонизатору, который генерирует html, а заодно и собирает стили по подобию bem-tools.
Использую ENB под Linux. Потому что там документация лучше, что ли.
Нет нормальной документации по bem-tools. Как писать свои технологии, как работает сборка на низком уровне и прочее.
Использую bem-tools под mac os и под linux.
У вас сложные процессы в компании.
Bem-tools будет работать в компании к которой клиенты обращаются за их опытом, технологией и сервисом, а не с запросами подобными "Нам нужен сайт на Битриксе"
Ну давайте без маркетингового булшита, что ещё за сложные процессы? Я привёл описание совершенно обычных, общепринятых сценариев. Ещё, раз: мы говорим про обычные, нормальные проекты. Про обычные компании, в том числе и крупные. Стартапы, мега-компании, и компании обслуживающие несколько проектов и только - не тема этого топика, они исключение. И им bem-tools конечно прописан.
Какое к этому всему отношение имеет опыт, технологии, сервис и бла-бла-бла? При чём тут битрикс, он как пример взят системы где куча шаблонов просто. Куча шаблонов на kohana - устроит?
Давайте тут обсуждать по существу пожалуйста.
Есть и такие проекты, есть и другие.
Разницы между поменять пять строк и добавить модификатор, при условии, что он есть, не много, другое дело, что нет желания готовить такие блоки, или непонятно как их готовить.
Я уверен, что если бы вы не касались HTML как такового, а могли вносить правки в страницу с помощью bem-дерева (в противовес дом-дереву в html) — то вы бы говорили про HTML тоже самое — "мы привыкли быстро править через ftp файлики на сервере и нам больше ничего не надо".
Не принимайте на свой счет лично, у BEM очень высокий порог входа, как показывает статистика, но именно так читается ваше послание.
upd: Уточню: bem — это не просто способ именования классов, это не только верстка — это в целом другой подход к разработке. Конечно, можно его урезать и использовать только для css, но я говорил не об этом. Научить называть классы по-другому — это не очень сложно.
Допилив в вашу кохану блоки — вы получите гораздо более мощный инструмент для разработки, чем изначальная версия коханы. Другое дело, что это потребует затрат, т.к. напрямую JS код из коханы вы не запустите.
А что, проекты на кохане вы тоже руками выкатываете через ftp? Серьезно?
upd: Я правильно понял, что вы занимаетесь только статикой? При верстке макетов БЭМ, имхо, дает бонусы, когда проект большой, много страниц, либо же, когда есть опыт использования и работа над проектом растянута по времени, или когда над одной страницей работают много людей и она сложная. Да много вариантов и бонусов. Но если вы не используете даже scm, то смысла от обсуждения этого крайне мало — очень много придется менять в вашем workflow.
делаю сайты как фрилансер используя уже полный стек техналогий и bem-tools c борщиком для сборки, мега проекты пока не замечаны, до Яндекса как самостоятельной единицы пока далеко. Уже не представляю как работать иначе. Что я делаю не так? Наверное не использую битрикс и не дурпалю )
Это будет чудесный, замечательный инструмент... для одного проекта. А у нас (и у большинства веб-студий) их сотни. Сотни, не десятки. Никак, вообще никак, не связанных друг с другом.
У вас есть предложения лучше если у клиента shared-хостинг?
Я напоминаю - тут люди и больших компаний пытаются рассуждать о том как писать проекты малым и средним веб-студиям. Сайт как правило находится на сервере клиента. Далеко не все наши проекты размещены на наших серверах, обычно у клиента уже есть свой хостинг. Конечно мы бы выкатывали тулзами, если бы была возможность, сейчас для одного крупного проекта это обсуждается.
Сорри, вы меня за дебила держите? Я знаю что такое bem, с Харисовым общался когда и слова такого БЭМ - не было. А вот вы - кажется не понимаете, говоря про именование классов. Именование классов там значения не имеет, а все тулзы выросшие из АНБ - это фичи для ускорения разработки в рамках Яндекса изначально.
Вы вообще понимаете что такое когда у вас не несколько связанных проектов, а сотни абсолютно разных? Лично вы готовы сверстать проект с bem-bl с нуля за 2 дня и потом делать правки в live-режиме при выкатке на продакшен? Я бы даже заплатил чтоб посмотреть как вы будете на файловой системе блоки создавать и собирать проект:))
Сколько времени делается верстка главной страницы нового проекта (в часах)? Сколько времени делаются правки от клиента (в минутах)?
Далеко не факт, что кохана будет удобна для проекта.
О чем мы спорим? Я знаю, сколько проектов у веб-студий. Вопрос в том, какое распределение задач именно в вашей студии и почему вы так открещиваетесь от бэм-тулс.
Скажем, если бы у вас были навыки работы с бэм-тулс, настолько, что вам было бы безралично есть он или нет — т.е. время сборки страницы на блоках ± такое же, как и текстом в хтлм, то был бы смысл писать хтмл руками?
Спасибо за диалог.
Что за бред, зачем выкатывать тулзами, есть ножом, копать ботинком, и т.п.?
Берете git, capistrano (или любую другую), настраиваете 1 раз проект или делаете настраиваемую под shared-хостинги заготовку и работаете с n-клиентами по этой схеме, где n прямо и линейно пропорционален кол-ву сотрудников.
Либо берете git, gitlab (или webgit), пишете/используете скрипт сборки ветки репозитория в архив, даете менеджерам — они скачивают последнюю версию и отправляют.
Нужна другая схема — берете другую схему.
Вы ноете про то, что это инструменты для одного большого проекта, что не подходят для мелких проектов — это не так, вы просто не умеет этим пользоваться, и не хотите учится.
Но самый парадокс в том, что в этот же момент вместо фокуса на сути вопроса вы не включая голову кичитесь знакомством с Харисовым (вашим кумиром) и "знанием" АНБ. Я не думаю, что диалог в таком ключе продуктивен.
Мы тут bem-tools обсуждаем или capistrano? Или мою биографию? Я не в том возрасте чтоб бравировать знакомствами)) Если есть сомнения в моём проф уровне - профили на моёмкруге и linkedin открыты.
По сабжу - вы можете описать реалистичную схему работы с сотнями проектов по bem-tools?
Вот отстаиваете bem-tools как культ карго какой-то. Как-будто от их наличия сразу всё станет круто, да не станет круто
Почему Яндекс bem-tools создали? Потому что их достало писать руками одно и тоже. Потому что у них было Лего (библиотека блоков). Это автоматизация. А в случае веб-студии - автоматизации не будет, понимаете? Нужно будет идти обратным путём создавая workflow для среды которая не нужна.
Если вам не круто от автоматизации — перестаньте пользоваться компьютерами. Вам резко полегчает.
К вопросу об автоматизации — автоматизировать можно что угодно, просто вы еще не научились это делать.
Не бравируете? Поищите свой пост на этой странице с упоминаем Харисова.
Если проектов сотни — то кол-во повторяющихся блоков резко растет. Но выделить их и сделать абстрактными — достаточно сложная работа, требующая не столько времени, сколько сильного ума. Я каждый день что-то автоматизирую, и если бы работал на вашими проектами — сказал бы и вам в каких местах у вас затык и что можно автоматизировать. Вы никогда меня не убедите, что у вас нет таких блоков.
Тут встает вопрос о том, что Лего библиотека блоков от Яндекса вашей студии не подходит, но это не значит, что разработку и деплой нельзя улучшить с помощью автоматизации, в т.ч. путем использования bem-tools.
И в обратную сторону — если вы выкатки делаете руками — то вам (вашей студии) просто рано об этом думать.
С чего вы решили что я против автоматизации? Я как раз за. Вот вы например используете grunt? Наверно используете с csslint, jshint и т.д. А PhantomCSS? А Dalek.JS? А вот мы - используем.
Правки: смотря какая правка, минимальное 3мин учитывая деплой. По поводу верстки не могу сказать, давно нету такого этапа, обычно это сразу дизайн и фронтенд разработка в одном лице )
Кстати. Вот чего действительно не хватает — живого примера сайта, которому совершенно не подходят имеющиеся в библиотеке блоки, и который реально сверстать за 2 дня на plain-html, пусть даже под 1 браузер.
А если адепт БЭМа покажет, как это делать в блоках — это будет лучшая реклама для веб-студий, имхо.
Ведь вопрос именно в том, что на блоках — все гораздно медленнее?
p.s. Я не адепт bem-tools. Сам бы посмотрел что и как.
Тогда вам просто необходимо начать использовать и капистрано или аналог на js. Если у вас есть тесты, то выкатки/откаты одной кнопкой вам точно понравятся.
Я предлагаю, чтобы не разводить тред, перейти к практике с bem-tools и завести тему о сборке странички на совершенно новых блоках, без использования bem-bl. И тоже самое, но с bem-bl. Таким образом будет возможно поставить рядом разработчиков bem-tools и рядовых верстальщиков, разработчиков веб-студий, работающих над небольшими проектами.
Каждый видит что хочет
Разумеется растёт. Разумеется нужно их выделять и делать абстрактными. Вы вообще читали мой пост, или так по-диагонали и "в интернете кто-то не прав?" Я о чём и пишу - нужна библиотека сниппетов. Я уже много раз писал почему сниппетов, а не блоков, устал повторятся - потому что проекты независимы, потому что так проще и легче развивать проект и самое главное - потому что в bem-tools вообще нет никакого профита для кучи проектов что не пересекаются.
Ну или положить кучу времени и сил, таки сделать библиотеку блоков под все десятки проектов, всё это время ничего не зарабатывать компании, перейти на bem-tools и узнать что проекты редизайнятся и всё это можно выкинуть в мусорку.
Хотя вру, у последнего проекта был уже готовый дизайн, до БЭМа еще сделал. Верстка главной страницы часа 4 заняло.
Знаете, вот что мне действительно сейчас интересно — это что за "такие разные" макеты, может поделитесь какими-то запущенными, но все еще "разными"? Желательно, парочкой самых "разных".
И еще мне непонятно, почему все надо будет выкидывать, если можно будет поправить блоки проекта, который редизайнится?
Сайты всегда разные, можете любые брать в выдаче гугла - они все разные. И разумеется проще поддерживать их по системе "все блоки в одном файле" (или переубедите - расскажите про профит bem-tools).
Выкидывать - потому что проще и быстрее написать заново. Ведь эти блоки все равно больше нигде не используются. А с редизайном как правило меняется и функционал, и достаточно сильно.
За 2 дня верстается не под один браузер, а с тестированием в том числе и на мобильных.
Вопрос не в том что на блоках медленнее - с этим ещё можно было бы смирится если бы это давало профит в будущем. Профита нет. У больших компаний, стартапов и студий нескольких проектов профит в унификации, в скорости разработки новых страниц, в поддержке, в атоматизации и т.д. Ну в общем все плюшки что явно видны, когда есть много всего что можно автоматиировать. А в случае обычной разработки - тут автоматизировать надо другое. Тут надо копать grunt, dalek и т.д. А когда руками сделать быстрее и проще чем автоматизированно - то автоматизация не нужна (в этой области).
Ну вот новый проект приходит, дизайн не похож на что-то имеющеся у вас в bem-библиотеке. 2 дня на вёрстку (16 часов). Легко или тяжело будет? Руками не проще?
Если на блоках быстрее — то я не знаю, почему вы их до сих пор не применяете. Я знаю, что на блоках можно делать быстрее, чем руками хтмл, но ботлнеки я пока не вижу, потому что я не адепт bem-tools. Размер компании, повторяемость кода, и т.д. — пока не роляет.
Очень странно слышать, что какой-то лендинг пейдж через некоторое время нужно редизайнить и выкидывать старые блоки, потому что проще написать новые. Честно. LP, как я уже говорил, может и не стоит рассматривать — сверстал и забыл, контент там не меняется, ничего внезапно не начнет прыгать, ничего не распучит, и т.п.
Берете (или собираете 1 раз) библиотеку блоков со страницей, списком, таблицей, в общем, со всем основным. Обновляете при необходимости. Никаких стилей, кроме служебных, типа reset.css для страницы.
Создаете все окружение (это, вообще говоря, стоит вынести в алиас или init скрипт). bem create level pages && bem create level --level bem-bl/blocks-desktop blocks ... собираете bemjson для страницы, допиливаете нужные блоки, собираете вторую страницу, допиливаете нужные блоки, повторить n-2 раза, профит.
Что-то сменится — поменяете в 1 блоке 1 раз (а не в n файлах страниц).
Опять же, если вам надо LP аэрофлота, у которой "хотим футер как на основном сайте" или "шапку тоже", или "вообще все окружение хотим" — то экспортировать json с основного сайта и собирать страницу будет намного проще каким-то инструментарием, нежели руками.
Простите, но я вижу ваши слова. что все сайты разные, но не вижу главного — примера такого сайта, который РЕАЛЬНО лучше не писать на блоках.
И еще мне стало интересно, как вы справляетесь с проблемой, когда одну страницу верстают 3 человека, и еще один js пишет? Блоки можно писать независимо, монолитную страницу — очень проблематично даже с scm.
Все-таки, я думаю, что "совершенно непохожие" страницы не такие уж непохожие, а если они действительно непохожие — такие страницы можно делать монолитными, но в терминах бэм (куча элементов, но who cares?), базируясь на странице или каком-то блоке, где все базовые скрипты и стили подключены.
В остальных случаях плюсы от использования автоматической сборки из кусочков, скажем, при выкатке — очевидны.
Все-таки вопрос именно в уровне порога входа, за 10 лет все слишком привыкли к HTML и это называется консерватизм, с этим тоже все понятно.
И про сниппеты — абстрагируясь, ваши сниппеты это как библиотеки функций, когда как в бэм — блоков — это как классы и объекты.
Функции можно было биндить, можно было писать свои — сниппеты тоже можно использовать, можно нет. Классы можно наследовать/миксовать.
Без сниппетов никуда в мелких приложениях, без объектов сложно представить большой проект. Все как вы говорите.
Но есть java, где все объект или его свойство, и есть БЭМ, где все — блок, а что не блок, то элемент или модификатор. Не все любят java, и не все любят бэм. Но объекты все равно используют, перегружают их при необходимости и не парятся.
Вопрос только в архитектуре базовых объектов (блоков).
Если вы посмотрите на БЭМ с этой точки зрения — вам станет понятно, что перл, где все строилось на сниппетах, умер, а java до сих пор жива и является примером для копирования удачного опыта в другие языки программирования (в т.ч. php, c#, etc.). P.s. я не сторонник Java, она очень тяжелая, но в случае с bem tools — в наших силах сделать его пригодным для использования для создания в т.ч. LP. Просто нужно понять, в чем именно проблемы, при использовании их в этом ключе.
upd: насколько я понимаю, именно про это и создан этот опрос, и поднята тема.
Сколько доп. времени это потребует по сравнению с тем чтобы просто написать руками блоки в одном файле?
В чём преимущество использования тут bem-tools? Если что-то сменится быстрее будет search& replace in files сделать по шаблонам.
"Страшно далеки они от народа". Какой ещё json основного сайта? О чём вы. Основной сайт и LP никак не связаны, делались разными компаниями, разные технологии, их вёрстка не имеет вообще ничего общего, даже логотипы разные.
Любой сайт лучше писать не на bem-tools если это не портал, не крупный ключевой сайт студии и у вас нет кучи свободного времени которое некуда девать.
Вы не поверите. У меня 7 человек в отделе, проекты ротируются между всеми, проблемы не то что один сайт - одну страницу одновременно писать нескольким разным людям не вижу вообще. Даже без bem можно, ну а по bem - вообще легко. bem != bem-tools.
На блоках быстрее развивать существующий большой проект. Развивать. Существующий. Большой.
Для обычного сайта никакой пользы нет.
Наберите в гуге цифру "1" и сравнивайте сайты в выдаче. Сильно похожи один на другой? Будете писать bemjsom для каждого?
Какой профит от сборки?
Вот есть сайт на kohana,codeigniter,symfony,назовите-свою-cmf. Вам нужно добавить новую страницу. Ваши действия?
BEM === методология.
bem-tools === всего-лишь один из инструментов. Хороший инструмент, полезный, но в своей сфере. BEM прекрасно существует без bem-tools. А тут в теме пытаются доказать что без них - и БЭМ не БЭМ, хотя сам Яндекс неоднократно говорил обратное.
Руками html в писать не надо. Написать в blabla.bemjson нужный блок и нужный контент — в полтора-два раза быстрее, чем оборачивать это дивами. Это очевидно. Если иметь какое-то IDE — то по скорости будет примерно одинаково. Писать стили и проставлять классы дивам меняя структуру дом-дерева — искать эти стили по всему файлу, либо сразу находить в маленьком файле про этот блок — тоже не большая разница, хотя в большом файле менее удобно, тоже очевидно. Основная разница — это кусок HTML в одном файле против bemhtml. Думаете намного дольше написать bemhtml? Ctrl+C, Ctrl+V против массива элементов и вечного Ctrl+H при рефакторинге, и т.д. О чем мы спорим? По скорости это не может быть дольше. Время примерно одинаковое.
LP с футером — как вы обновляете LP, если она динамически меняется на основном сайте? Для меня такой подход кажется не очень профессиональным, но все зависит от задач. Видимо, у вас несколько другие задачи, в общем, смысла спортить нет.
Это холиваром пахнет. Нет смысла обсуждать.
В то, что у них не бывает конфликтов кода, они не дублируют функционал — действительно не поверю. Либо у вас много времени уходит на расщепление задач, либо ваших менеджеров железные нервы. В любом случае, один файл с кучей правок — это всегда сложнее, чем куча правок, но в разных файлах, и на каждый файл по малу правок. Всегда видно, что и где менялось. Может быть для ваших LP это и не нужно, поэтому тоже смысла спорить мало.
С этим не поспоришь, но я говорил о другом.
Значит ли это, что верстать "принципиально новый" макет на блоках дольше? Если нет, то почему вы до сих пор пишете хтмл руками? Если да, то в чем проблемы, что тормозит процесс?
Набрал 1. Первые три: 1tv.ru, google +1 button, imdb, — все похожие, у них разные стили, но архитектура 1в1. Мне не повезло, наверное? Просто это большие и развивающиеся сайты? Не знаю, что вы хотите этим доказать. Последнюю LP, в которую я делал JS, хотела яндекс.карту с подгрузкой их офисов. Так вот, мне было бы намного проще вставить в эту страницу новый блок, расширенный блоком карты, в котором описать логику подгрузки и размещения офисов на карте, все биндинги (BEM.DOM.decl и поехали). Забирали эту LP архивом, но архив страницы после make можно отдавать автоматически. Может быть, просто мне не повезло и размер репозитория с LP этого клиента у нас в районе 0.5-1Гб. Может быть, пример плохой.
Да, я буду писать bemjson для каждого, вместо HTML. Но для блоков я буду просто доопределять стили (рюшечки/ромашки и прочее). И в лучшем случае я полностью избавлю себя от изменения html, в большинстве случаев — я напишу новый bemhtml, в худшем — я напишу "принципиально новый" блок, что и вам предлагаю делать при приходе "принципиально нового" макета.
По поводу сайта — это единоразовое действие? Админка есть у сайта? Зайду в админку и добавлю. Если админки нет — разберусь с маппингом урлов (покопаю код/спрошу у тех кто знает), добавлю новый новый урл. Готово?
ООМ тоже методология, объекто-ориентированная. ООП — программирование, основанное на ООМ. Простите, я слегка путаюсь в терминах, слабый не теоретик.
Я не спорю с тем, что bem-tools это инструмент, при чем, вероятно, не самый лучший, и уж точно не универсальный. Пусть пытаются, мы же понимаем, что первое и второе — это разные вещи, просто связанные. PHP и Java тоже разные, хотя ООП.
Я спорю с тем, что вы зря так открещиваетесь от использования блоков, даже в LP. Есть большая вероятность, что сборка таких страниц на блоках не только не займет больше времени, но и даст профит. Если у вас большой опыт создания оторванных от реальности страниц — поделитесь опытом, пожалуйста. Расскажите, в каких именно местах вы понимаете, что сборка замедляет процесс.
Еще раз про сниппеты — оторванные от всего куски css и js кода размещаются в разных абстрактных блоках. Когда вам нужен тот или иной кусок — вы просто наследуетесь от этого блока или миксуете его, перегружая только нужные куски. Да, для этого нужно будет провести какую-то работу, но в конечном счете процесс сборки страниц будет быстрее.
А еще лучше, если макеты будут в нескольких версиях (когда сверстали, потом редизайн, потом еще что-то подвигали) и чтобы в комплекте к макету шли бы какие-нибудь требования к js.
Думаю, не только мне одному интересно узнать, почему это bem-tools так уж «абсолютно непригодна для небольших проектов и компаний».
А потом вернемся к дискуссии. Идет?
enb, macos
1) переиспользование блоков между проектами и библиотеки блоков не является обязательной частью.
2) Руками не проще, а даже сложней, особенно если это уже 16 часов верстки.
3) В нормальном дизайне всегда есть место готовым блокам, а если дизайнеры лепят макеты между которыми ни чего общего и при этом таких заказов много, то гнать их в шею )
4) Не забываем, что БЭМ это уже далеко не верстка.
5) После bem make я получаю продакшен реди шаблоны и их не надо допиливать под бэкенд. В случае с обычным способом, потом надо их пилить на куски, рыскать по ним и встаялять теги шаблонизатора бэкенда и т.д.
Очень нужен подобный скринкаст, для завоевания мира.
О, конструктив, ура) С удовольствием бы посмотрел на PSD и на то, что получится у tadatuta в результате. Ну и другим потом показал.
Я говорю про опыт который получил в нашей совершенно обычной студии!
Поверь, такое бывает.
Вы похоже из тех людей которым опыт разработки мешает
Это правда! Это, возможно, единственная мысль всех ваших высказываний?
Как плюсануть?
Почему у ярушки нет лайка комментария?
Очень нужный скринкаст!
столько пользователей enb и не кто не может привести в нормальное состояние местный project-stub, удивительно)
Ура! Спасибо!)
а что с ним не так?..
давайте ссылку, накидайте issues и все придет в нормальное состояние.
раз и два - висят больше месяца.
Попробуйте этот форк https://github.com/iplus/project-stub.
Вкратце по первому issue - надо использовать не enb-bemhtml, а enb-bemxjst технологию.
А вот по поводу i18n промолчу)
за ответ спасибо. но я продолжаю ворчать - наличие кусочка решения в далеком-далеком репозитории не отменяет первоначальный тезис - project-stub находится в неактуальном состоянии.
блоки, использующие i18n без технологии i18n бесполезны. не поянтно, почему эту технологию делают опционально подключаемой. скорее это обязательная штука, с возможностью отключить, когда знаешь что делаешь.
Ну... если уж прям ворчать, то mdevils/project-stub писался для bem-bl, с ним и работает.
Надо новый project-stub
А по поводу i18n... надо посмотреть на досуге, должно работать же, пример взять из bem, для enb просто подключить технологии.
своим брюзжанием я в некоторой степени отвечаю на вопрос - "что останавливается меня от использования ... ?"
нельзя просто взять и собрать project-stub - для этого нужно быть глубоко в теме. честно. project-stub больше всего нужен тем, кто только начинает пользоваться инструментом. он дает возможность сразу переходить к экспериментам, минуя пляски с конфигурированием. судя, по местным комментам, bem-bl больше не развивается. какой прок от ветки на bem-bl? - не вижу ни какого смысла начинать эксперименты на доживающей последнии дни технологии.
на минувшем YaC mdevils@ рассказывал не только про bh, bt, bemtree но и про другие замечательные технологии, использующие модульную систему bem-core для автоматического разрешения зависимостей (без необходимости прописывать deps лапками), middleware, обеспечивающую для enb бесшовную интеграцию с express.js и т.п. замечательныше штуки . вот кто и как про это узнает?
Плюсуем комментами )
Меня ничего не останавливает использовать bem-tools кроме самого bem-tools
Начал пытаться использовать тулзы когда он еще не имел сборщика и поддержки в винде, пришлось смотреть в код, спасибо вам за это, я почерпнул много интересных вещей и даже законтрибьютил пару строк, но танцы с бубном в винде мне хоть и нравились - я не мог предложить использовать их на проекте, где надо делать работу, а не делать инструменты, makefile меня не устраивал, для маленьких проектов bemjson/bemhtml не устраивали - я очень слабо представляю как использовать действительно для крупных полектов, без замены на jade, haml и т.п., написание в консоли длинных команд не устраивало, невозможность использовать как полноценный шаблонизатор не устраивало и многие другие мелочи без которых не хотелось жить. но сама методология манила и выедала мозг еще за долго анонса бем-тулз.
из-за отсутствия полноценной налаженой цепочки разработки(верстки и реализация из верстки шаблонов - а это всё делаю обычно я один) один проект можно сказать завалил. итоговым результатом совсем не удовлетворился и отбросил бем тулс на неопределнный срок.
время шло и мои пробы разных инструментов всё таки увенчались успехом - asset pipeline из rails делает даже больше чем я нуждаюсь и главное быстро и без боли. поэтому для frontend разработки равных в простоте таких статичных генераторов как middleman я пока не нашел. А что касается БЭМ, то тут дела обстоят не хуже - краеугольным камнем претковенья является js-библиотека, которую голыми руками не возьмешь, как мне кажется это тоже минус. т.к. блочная/модульная архитектура всё же подразумевает некоторое разделение.
В общем специально для нового проекта написал я свою реализацию, чтобы было удобно манипулировать классами, а за базу взял мою любимую jquery ui widget factory, которая огромную работу делает за меня. в итоге получил огромное удовольствие работать с БЭМ и инструментами которые мне подходят для создания конечно не таких огромных как яндекс-сайтов, но всё же проектов. Тут тебе и миксины и события и наследование и всё-всё-всё что я давно собираю у себя по папкам с проектами.
В общем такая вот история. Так что сердцем я за бэм. но на практике ни одному проекту бэм тулс не подошел.
зы на правах рекламы вот ссылка на мою общедоступную недореализацию https://github.com/hunterman/jquery-ui-bem-block там еще многого нет, но если кто-нибудь здравомыслящий укажет на недочеты и побьет ногами, буду весьма благодарен.
зыы так же для тех кто больше склонен к плагинам jquery, обнаружил недавно что я не одинок и существует вот такая реализация https://github.com/ethernet1/bem
Согласен) Все так.
А можно ссылочку на доклад про bh, bt, bemtree но и про другие замечательные технологии. Что-то найти никак не могу, а очень хочется.
Кстати. Если у кого завалялись макеты. Приложите к посту) Идея ведь правда хороша.
я так понимаю это видео выложется где-то через месяц
Отлично, я только за!
Сорри, за задержку с ответом, был не у компа эти дни.
Взял для примера маленький, простой типовой сайт.
Вот дизайн 2010 года:
- http://yadi.sk/d/QukxuCiEAozyB
- http://yadi.sk/d/TQW_322KAp22q
При наведении на каждое лого, меняется блок с текстом, переходв по сайту нет.
Редизайн:
- http://yadi.sk/d/BY2gZ7ZfAp2JF
Классический паралакс.
я со своими вопросами поймал mdevils@ уже после доклада и от него узнал про все эти замечательные вещи в enb. парни говорили, что собираются всякие интересные штуки анонсировать в этом клубе. поэтому думаю, что инфа появится раньше докладов с BEMup, которые обещали начать выкладывать, не раньше чем месяца через два после мероприятия.
Возможно, позже
Владимир, а как у вас дела?
Можно этот дизайн взять для составления https://github.com/alexba
Да.