Сергей Бережной veged

мы пробуем и удалённые форматы тоже — например, в этом году параллельно со Школой в Москве будет Школа в Минске, которую частично будем подключать удалённо к лекциям в Москве — глядишь скоро отработаем эффективную практику чтобы вообще полностью онлайн обучать, но пока устное оффлайновое общение (и с кураторами, и с другими студентами) выглядит как очень важная часть процесса

всё ещё можно попробовать сделать задание (как минимум это может быть интересно и полезно само по себе) и отправить его до 31 — если оно будет действительно хорошее, то вероятность попасть на Школу большая

если открыть картинку в новом табе, то будет всё видно — hsto.org/getpro/habr/post_images/4d0/640/c91/4d0640c9171d50028e3ae6dfb7ccb67d.png — или речь о том, чтобы саму картинку завернуть в такую ссылку?

да, у Алисы есть команда, а ещё во многих местах отдельные команды сервисов делают интеграции

да, вы правы, материал рассчитан на более широкий круг читателей и не содержит многих технических подробностей

crosswalk и ionic2, это конкретные способы разрабатывать на платформе Cordova, а wk-webview подразумевается, в том числе, когда мы говорим о кастомных гибридных архитектурах

подробнее про это и про то, какие части можно делать в виде нативных плагинов, мы говорим на самой Школе Разработки Интерфейсов (https://academy.yandex.ru/events/frontend/shri_msk-2017/)

такого опыта не так много, т.к. в большинстве случаев мы используем или полностью нативные или html+css+js технологии

вот ещё пара докладов по теме:
https://events.yandex.ru/lib/talks/689/
https://events.yandex.ru/lib/talks/302/

конечно БЭМ применим для JS кода! главная суть БЭМ-а это «многоязычность» https://ru.bem.info/method/key-concepts/#Технология-реализации
вот документация про основную реализацию https://ru.bem.info/articles/bem-js-main-terms/ https://ru.bem.info/technology/i-bem/v2/i-bem-js/
если появятся дополнительные вопросы всегда можно получить ответ на форуме https://bem.info/forum/

настоящая карма всегда со мной ;-) а вот почему нельзя оценивать комментарии не написав ни одного поста, это пусть останется на карме разработчиков хабра

то что ты говоришь, это уже следствие — после ухода Андрея мы его вполне развивали аналогичными темпами с Лёшей и Лёней, вот только нужно было экспоненциально растить темпы (без опенсорса это практически не реально)

кроме того, про что написал tadatuta habrahabr.ru/company/yandex/blog/276035/#comment_8767005 (жаль у меня нет кармы ставить плюсики каментам), не могу молчать про похороны y5, т.к. «из первых рук» знаю про ситуацию — основная причина была в закрытости кода и невозможности подключить к сообществу внешних людей

честно говоря я почитал ваш подтред с Zenitchik, но не смог понять, что Вы называете неименованными объектами и связано ли это с id

случайно речь не про

<div class="my-block" data-bem='{ "my-block" : {} }'>...

пустой объект в атрибуте data-bem?

id обязан быть уникальным, и отсюда вытекают два неприятных свойства:
1) это очень трудно гарантировать
2) если использовать id для идентификации, то на странице может быть только один инстанс такого типа — а это может «выстреливать» в самые неожиданные моменты, когда вдруг понадобится второй

class же во всём может заменить id и при этом не обладает такими недостатками

раньше (лет 10 назад) у id было преимущество про скорость (браузеры не сильно оптимизировали DOM-дерево и не строили никаких кешей по class), но со временем эта разница существенно сгладилась

основное отличие: БЭМ-методология — если вы не разделяете этих идей и действительно верите в свои пункты 1, 2, 3, то вам незачем никуда переходить

в React нет встроенных средств про единую предметную область между разными технологиями

можно сделать миллионом разных способов, но я надеюсь мы все одинаково понимаем, что это, само по себе, не является аргументом, чтобы не делать другим ;-)

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

БЭМ термины хорошо зарекомендовали себя на практике, как удобный способ описания страниц. Они позволяют иметь единую предметную область в разных технологиях (например, в документации, тестах, css и т.п.). Не вижу причин не поддержать БЭМ в реактивной модели.

см. также 42gag.com/img/gag/494.jpg ;-)

про реакт история гораздо больше, чем XML/JS-синтаксис — нужна поддержка БЭМ предметной области

люди просто не знают, что им нужны возможности асинхронной модульной системы ;-) например, jQuery грузится через неё (а это совсем не 2% пользователей)

1. кроме модульности и инкапсуляции как таковой в БЭМ есть важная методологическая составляющая про «многоязычие», т.е. что один блок реализуется в разных технологиях, т.о. получается построить обобщённые термины и для CSS, и для JS, и для любых других «технологий» (например, документация и тесты)

2. почему невозможно покрыть модульными тестами? как раз наоборот, «технология» описания тестов ложится рядом с описанием блока в CSS/JS/HTML — вот, например, модульные тесты в библиотеке bem-core: github.com/bem/bem-core/blob/v1/common.blocks/i-bem/i-bem.test.js, github.com/bem/bem-core/blob/v1/common.blocks/events/events.test.js — причём с таким подходом мы используем разные системы тестирования, от обычных модульных JS-тестов, до сравнения скриншотов

3. интеграционные тесты делаются похожим образом, только они пишутся как тесты для составных блоков (блоков, использующих внутри себя другие блоки)

а какие методологии, похожие на БЭМ, вы ещё подразумеваете в сравнении?

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

не понял вопроса… если речь о профилировании работы сервера, то мы замеряем время сборки без учёта сетевых расходов

да, библиотеки выкачиваются по необходимости уже во время работы сервера

технически разницы между данными и модулями нет — поэтому, на мой взгляд, система должна выдерживать все эти кейсы

ну и см. каменды Димы ниже

предположи, что у тебя для синхронного провайда используется сторонний модуль в котором «вдруг» вылетает эксепшен — это ни чем по смыслу не отличается от любых проблем с асинхронным вызовом, все гарантии примерно одинаковые (а именно, никаких) и в обоих случаях по одинаковой стратегии нужно поступать

всё описанное также справедливо для синхронных provide — достаточно представить ситуацию, когда модуль начал делать синхронный provide (return) и произошло исключение и предоставить свой интерфейс он не может…

отставлю тут ссылку github.com/ymaps/modules

согласен с Димой, что эти функции правильнее вынести в дополнительный модуль, а не в ядро

Сам по себе БЭМ не диктует визуально-ориентированность, просто больше всего примеров с визуальными блоками, т.к. это понятнее всего. А на деле мы во всю делаем всякие абстрактные блоки, которые даже не имеют никакого визуального представления. Но при этом они по прежнему реализуются в нескольких технологиях (например, клиентский js, тесты, документация, примеры).

в посте теги все слиплись в один

«Не просто», это уже вывод из каких-то более низкоуровневых причин и проблем. Вот мне как раз они интереснее. Что не просто, создавать файлы, или писать длинные селекторы, или разделять всё на блоки, элементы, модификаторы? Если есть возможность показать код проектов (хотя бы лично) было бы вообще круто, тогда более предметно можно разговаривать.

Чем для вас принципы 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/.

ага, спасибо

Почему? У нас давно действует практика индивидуальных советов и ответов на вопросы — clubs.ya.ru/bem/replies.xml?item_no=1273 — мы в разной форме (текстом, по скайпу, лично) и с разными компаниями практикуем такое.

Позвольте не согласиться (хотя там «не» затесалось и я может не правильно понял). Если код писал человек со стороны, то наличие любых соглашений (например, БЭМ) будет положительно сказываться на принятии этого кода (хоть что-то знакомое будет, хотя бы общие принципы). Если же никаких соглашений нет (пишем как хотим или как наиболее коротко и элегантно), то вероятность не понять такой код от стороннего человека только возрастает.

А как вы пробовали и что не получилось? Интересно узнать, может мы что-то сможем посоветовать.

Бардак, это то что «никто ни с кем ни о чём не договаривается». В основе БЭМ-методологии как раз одной из идей лежит коллективное владение кодом и обсуждение архитектуры людьми разной специализации (т.к. одни и теже БЭМ-сущности существуют в разных технологиях). А когда люди, работая над общим проектом, начинают больше общаться, то там и побочных ещё бонусов куча всплывает!

P.S. Я предлагаю сократить до Бардак Элемент Модификатор ;-) а то такая смешная шутка, а никто повторить не может.

я имел ввиду «решение», а не «идею решения» — идей мы и сами отсыпать можем ;-)

а вы пробовали? ;-) нас немного спасает, но конечно не серебряная пуля вовсе

Я скорее на стороне тех людей, которые считают, что веб-разработчики это не дети и вполне могут иногда подумать. Но если нужны строгие правила, то легко — пельмени можно никогда не солить, каскад можно никогда не применять. А тот, кто почувствует, что ему эти правила жмут, тому и строгая инструкция не нужна.

Если вы уже преодолели порог входа (важное условие!), то делать даже простые сайты (ну где есть больше одного блока, а не просто текст в body) проще с БЭМ. Лично я все личные мелкие штуки быстро тяпляпаю с bem-tools/bemhtml/i-bem.js.