Комментарии 17
Автор, хоть бы расшифровал бы разок, что тако БЭМ…
А то — БЭМ-БЭМ-бах-бах… ;)
А то — БЭМ-БЭМ-бах-бах… ;)
Блок, элемент, модификатор: ru.bem.info
Нет, я умею пользоваться поисковиком.
Я имел в виду, что в подобной статье, следует давать хоть какое-то определение объекту обсуждения, чтобы статья имела целостный вид. Ведь целевая аудитория — не только те, кто уже знает, что такое БЭМ.
Я имел в виду, что в подобной статье, следует давать хоть какое-то определение объекту обсуждения, чтобы статья имела целостный вид. Ведь целевая аудитория — не только те, кто уже знает, что такое БЭМ.
Фронтэндщику нужно держать два набора инструментов и переключаться между ними
Фронтэндщику сложно использовать незнакомую технологию, всякие…
Фронтэндщик может «сломать» серверный код и не понять этого
Фронтэндщик не знает стандартов кодирования бэкэнд-команды
Фронтэндщику нужно разворачивать и конфигурировать все приложение в т.ч. БД и другие зависимости
Автор описал какого-то очень плохого фронтендщика. У нас никогда не было с этим проблем.
Фронтэндщику сложно использовать незнакомую технологию, всякие…
Фронтэндщик может «сломать» серверный код и не понять этого
Фронтэндщик не знает стандартов кодирования бэкэнд-команды
Фронтэндщику нужно разворачивать и конфигурировать все приложение в т.ч. БД и другие зависимости
Автор описал какого-то очень плохого фронтендщика. У нас никогда не было с этим проблем.
Почему? Ситуации вполне себе реалистичные.
Может быть это вопрос скиллов самого фронтендщика и тех договоренностей, которые есть внутри команды. Если фронтендщик работает с RoR или ASP.NET MVC, то он обязан знать какую-то минимальную информацию о них. Тот же Razor в шаблонах для ASP.NET MVC знать нужно обязательно, а он потянет за собой желание написать какой-нибудь html-хелпер, который сократит разметку. Так или иначе, но фронтэнд корнями стоит на бекенде (За исключением REST API и SPA). А принятые в компании гайдлайны по разработке не так сложно прочитать и применять, в этом я тоже не вижу сложности (разве что природная лень).
Конкретно моя боль в следующем:
Для скриптовых языков проблема стоит не так остро. Хочу проверить одну гипотезу: я на досуге отвязал Razor от ASP.NET MVC. Хочу попробовать сделать таск для gulp для полноценной сборки .cshtml на gulp watch, чтобы можно было сразу верстать в терминах блоков.
Вью модели компилировать на лету в фоновом режиме из указанных в конфиге сборок/папок, чтобы не нужно было постоянно жать на cntrl+shift+b: отредактировал модельку, пошел править шаблон, пока правил вью модельки скомпилировались.
Получится, что обе команды работают над одной кодовой базой, но точки входа у них разные: для backed — полноценное приложение, а для frontend — легковесный сборщик со stub'ами для инстанцирования вью-моделей. Смысл этого в сокращении накладных расходов.
Я не спорю с тем, что научиться редактировать серверный код — не рокет сайнс, я пытаюсь сократить накладные расходы на переключение контекстов.
- Visual Studio — не лучший инструмент для верстки
- Необходимость разворачивать БД и весь сложный стек на машине разработчика, которое это, все строго говоря, не нужно
- Необходимость многократно перекомпилировать приложение (на это уходит время)
Для скриптовых языков проблема стоит не так остро. Хочу проверить одну гипотезу: я на досуге отвязал Razor от ASP.NET MVC. Хочу попробовать сделать таск для gulp для полноценной сборки .cshtml на gulp watch, чтобы можно было сразу верстать в терминах блоков.
Вью модели компилировать на лету в фоновом режиме из указанных в конфиге сборок/папок, чтобы не нужно было постоянно жать на cntrl+shift+b: отредактировал модельку, пошел править шаблон, пока правил вью модельки скомпилировались.
Получится, что обе команды работают над одной кодовой базой, но точки входа у них разные: для backed — полноценное приложение, а для frontend — легковесный сборщик со stub'ами для инстанцирования вью-моделей. Смысл этого в сокращении накладных расходов.
Я не спорю с тем, что научиться редактировать серверный код — не рокет сайнс, я пытаюсь сократить накладные расходы на переключение контекстов.
Посмотрите еще на getbem.com, там есть ссылки на статьи по методологии и небольшое FAQ.
Спасибо! Статья была очень интересна для меня и разложила мысли по полочкам.
Вот ещё накину
source.futurecolors.ru/css-requirements/
source.futurecolors.ru/css-requirements/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
БЭМ с человеческим лицом и интеграция с backend