предположи, что у тебя для синхронного провайда используется сторонний модуль в котором «вдруг» вылетает эксепшен — это ни чем по смыслу не отличается от любых проблем с асинхронным вызовом, все гарантии примерно одинаковые (а именно, никаких) и в обоих случаях по одинаковой стратегии нужно поступать
всё описанное также справедливо для синхронных provide — достаточно представить ситуацию, когда модуль начал делать синхронный provide (return) и произошло исключение и предоставить свой интерфейс он не может…
Сам по себе БЭМ не диктует визуально-ориентированность, просто больше всего примеров с визуальными блоками, т.к. это понятнее всего. А на деле мы во всю делаем всякие абстрактные блоки, которые даже не имеют никакого визуального представления. Но при этом они по прежнему реализуются в нескольких технологиях (например, клиентский js, тесты, документация, примеры).
«Не просто», это уже вывод из каких-то более низкоуровневых причин и проблем. Вот мне как раз они интереснее. Что не просто, создавать файлы, или писать длинные селекторы, или разделять всё на блоки, элементы, модификаторы? Если есть возможность показать код проектов (хотя бы лично) было бы вообще круто, тогда более предметно можно разговаривать.
Чем для вас принципы OOCSS отличаются от БЭМ?
Использовать SASS или Stylus можно и с БЭМ: сама методология подразумевает возможность любых технологий реализации блоков (про это не плохо было в недавнем докладе для WebConf в Риге vimeo.com/53219242 + bem.info/articles/yandex-frontend-dev/), а в bem-tools есть поддержка и sass, и styl, и less.
Про свод правил и инструменты я не очень понял противопоставления. Почему или свод правил или инструменты? У нас есть и то и то — вместе только лучше работает.
Почему? У нас давно действует практика индивидуальных советов и ответов на вопросы — clubs.ya.ru/bem/replies.xml?item_no=1273 — мы в разной форме (текстом, по скайпу, лично) и с разными компаниями практикуем такое.
Позвольте не согласиться (хотя там «не» затесалось и я может не правильно понял). Если код писал человек со стороны, то наличие любых соглашений (например, БЭМ) будет положительно сказываться на принятии этого кода (хоть что-то знакомое будет, хотя бы общие принципы). Если же никаких соглашений нет (пишем как хотим или как наиболее коротко и элегантно), то вероятность не понять такой код от стороннего человека только возрастает.
Бардак, это то что «никто ни с кем ни о чём не договаривается». В основе БЭМ-методологии как раз одной из идей лежит коллективное владение кодом и обсуждение архитектуры людьми разной специализации (т.к. одни и теже БЭМ-сущности существуют в разных технологиях). А когда люди, работая над общим проектом, начинают больше общаться, то там и побочных ещё бонусов куча всплывает!
P.S. Я предлагаю сократить до Бардак Элемент Модификатор ;-) а то такая смешная шутка, а никто повторить не может.
Я скорее на стороне тех людей, которые считают, что веб-разработчики это не дети и вполне могут иногда подумать. Но если нужны строгие правила, то легко — пельмени можно никогда не солить, каскад можно никогда не применять. А тот, кто почувствует, что ему эти правила жмут, тому и строгая инструкция не нужна.
ну и см. каменды Димы ниже
Чем для вас принципы OOCSS отличаются от БЭМ?
Использовать SASS или Stylus можно и с БЭМ: сама методология подразумевает возможность любых технологий реализации блоков (про это не плохо было в недавнем докладе для WebConf в Риге vimeo.com/53219242 + bem.info/articles/yandex-frontend-dev/), а в bem-tools есть поддержка и sass, и styl, и less.
Про свод правил и инструменты я не очень понял противопоставления. Почему или свод правил или инструменты? У нас есть и то и то — вместе только лучше работает.
Если приложение в большей степени на JS, то БЭМ вполне может помочь. У нас часть про клиентский JS не плохо проработана на практике (например, при создании n.maps.yandex.ru — тоже не простой интерфейс). Про это есть несколько докладов: events.yandex.ru/events/yasubbotnik/msk-jul-2012/talks/302/, events.yandex.ru/events/yasubbotnik/msk-sep-2012/talks/323/, events.yandex.ru/events/yasubbotnik/msk-sep-2012/talks/324/.
P.S. Я предлагаю сократить до Бардак Элемент Модификатор ;-) а то такая смешная шутка, а никто повторить не может.