BEMup в Питере

План доклада для BEMup (29 ноября 2013)

Дмитрий Кушников
Компания ДАС груп

Ведущий разработчик и архитектор проекта Repka.com. Занимается веб-разработкой более 12 лет. Активный участник БЭМ-сообщества :) 

"БЭМ глазами backend-разработчика" 

Мы используем БЭМ для организации фронтенда с самого начала разработки проекта. 
В докладе пойдет речь о том, как устроена архитектура нашего сайта, какие из технологий Яндекса и как мы у себя применяем, как мы пришли к использованию i-bem, что используем в качестве шаблонизатора, как устроен наш клиент-сайд и что в планах технологического развития проекта на ближайшее будущее. Расскажу о плюсах БЭМ с точки зрения бэкенд-разработчика.


1. Приветствие, представление себя и проекта:
Я архитектор и ведущий разработчик проекта в компании Репка.
Репка — сервис социальной торговли на основе совместных покупок.
Из интересного: 
- 400k MAU (20k DAU)
- 200k хитов
- Более 300k товаров

2. Стек + данные о разработке:
Проекту 2,5 года (9 месяцев разработки до публичной версии).
Storages: MySQL, MongoDB, Redis, OpenStack Swift
Backend: PHP (Yii)
Client: BEM (i-bem)

3. Выбор БЭМ в качестве решения для client-side:
- Во всех моих предыдущих проектах с client-side'ом был полный бардак: начиная от лапше-кода в dom:ready и заканчивая сложной структурой классов с использованием Prototype.js.
- Больше всего проблем доставлял CSS: особенно, когда нельзя было использовать id.
- В сентябре 2011, когда я думал над тем, как организовать клиент-сайд для нашего проекта - БЭМ был (и остается до сих пор) единственной полноценной реализацией АНБ. Собственно никакого выбора особо и не было _(Можно подумать и рассказать, почему отказались от MVC Spine)_

4. BEM на Репке:
- принцип построения интерфейса по блокам
- нотация классов (стандартное, с префиксами)
- i-bem (js в BEM-терминах)
_Подумать о том, чтобы показать какие-нибудь примеры?_
_Или взять какой-нибудь скриншот и разложить по блокам?_

5. Как мы пришли к i-bem:
- Начали со связки Spine + BEM-нотация
- После того, как написали свой набор хелперов для работы с классами - перешли на i-bem (это было очень просто, почти контекстная замена)

6. Шаблонизация:
- частично при помощи pure PHP, частично при помощи mustache (если необходимо использование шаблона на клиенте - mustache)
- зачем mustache - на тот момент был один из немногих js-шаблонизаторов с реализацией на php. 
- иногда к нам заходят роботы и для них очень важно отдавать html, а не json

7. Наш client-side:
- Структура хранения блоков совпадает с той, которая используется в стандартной библиотеке, но мы не используем уровни переопределения)
- Свой аналог decl.js - для структуры блоков и зависимостей (php-конфиги - по одному на каждый блок)
- Свой аналог page.js - для описание зависимостей страницы и сборки ассетов
- Самописный сборщик основанный на CClientScript (Yii), который собирает при деплое (csso, jsmin)

8. Из интересного:
- не используем plain CSS, пишем на LESS (который собирается сборщиком): используем миксины и очень удобно для описания блока (когда есть модификаторы)
- _что-то еще тут будет_

9. Планы:
- Обновление i-bem (bem-bl -> bem-core)
- Трёхуровневая архитектура:
Backend API (PHP) -> Frontend (NodeJS) -> ClientSide (i-bem)
BEMJSON, BEMHTML (BEMTREE) 
 

10. Выводы для себя (и для других)
- Для меня БЭМ - это парадигма разработки сродни ООП, но ориентированная для frontend-разработку, которая, как и ООП, позволяет легко проектировать и потом поддерживать сложные (а уж простые и тем более) программные продукты.
- _что-то еще тут будет_