Текущий подход достаточно заморочен, если знаешь все прелести БЭМ.
Сейчас мы делаем:
0. Дизайнер нарисовал макет
1. Верстаем руками html: a.html
2. пишем руками стили: a.css
3. пишем руками js: a.js
4. Это все передаем бекендеру и он:
5. Доверстывает хтмл и разбивает на шаблоны, из a.html получает A.tmpl, B.tmpl, C.tmpl, ...
6. Дописывает стили в своих файлах, а часто еще и разбивает их на части: A.scss, B.scss, ...
7. Дописывает js, и тоже часто разбивает: A.js, B.js, C.js
8. Какой-то бэкенд собирает из кусков шаблонов страницу, и часто создает css, js только из нужных кусков
А дальше: Пришел новый макет. И что делать?
И БЭМ в данном случае решает проблему, поскольку у него есть стек технологий, позволяющий верстальщику работать сразу с шаблонами и разобранными js/css(less/sass/stylus) файлами.
На практике получается так:
0. Макет.
1. Верстальщик смотрит на макет, и разбивает его на куски (компоненты) сразу;
2. Пишет bemjson (или jsx) вместо html;
3. Создает шаблоны, стили и js для каждого из блоков;
4. Передает это все бэкенд программисту (обычно через гит, потому что так удобнее);
5. Бэкендер без изменений использует эти файлы для генерации страницы, и просто генерирует описанный верстальщиком bemjson (или jsx).
И, О МАГИЯ, они могут работать над проектом параллельно, даже если придет новый макет.
C php действительно есть нюансы, которые сложно разглядеть, просто потому, что нет большого кол-ва пользователей и стек не устоялся.
Мы у себя используем велосипед, который собирает все сам, и почти готовы перейти на enb используя bh-php.
Большая проблема, как оказалось, использование декларативных шаблонизаторов — верстальщики не сразу въезжают что и как. Но когда въехали — я не знаю тех, кто возвращается на императивные (типа мусташей, джейдов, smarty, etc.).
Можно начать с
https://github.com/bem/project-stub/tree/php-bem-bh и позадавать вопросы на форуме
https://ru.bem.info/forum/ — люди поделятся своими историями.
