Я тоже так думал, но оно как то само отмирает. Vim все чаще для меня — хорош и без плагинов.
На счет Ctrl+P плагина. Он хороший и по этому он все еще установлен у меня. Он даже расширен более быстрым поиском и доп. функциями. Но есть альтернатива в виде ack или grep, с ними бывает быстрее.
Есть печальная история с "улучшенными поддержками языка". Например vim-javascript тормозит работу Vim если работаешь с файлами в 150000 строк. А мне приходится такие, как минимум, просматривать.
Да. Можно еще :Ex или :Sex. У NERDTree свои недостатки. Мне не удобно в нем работать в проектах с большим количеством вложенных папок и длинными названиями файлов, как бы я его не настраивал.
У меня был подобный опыт перехода. Был похожий vim конфиг. Было время когда держал конфиг Sublime Text вместе в vim. Совсем недавно удалил все про саблайм. Но со временем и большим изучением vim, я начал избавляться плагинов, что никак не ухудшало работу с vim. Вот тут можно посмотреть иторию коммитов voischev/dotfiles Надеюсь кому то будет полезно
Как-то, сильно уж противоречиво написали. Никто никого не заставляет, скорее рекомендуем. Кстати ваше корпоративная wiki и то, что сложилось в голове, ничем не лучше и не хуже что вам предлагают.
Да конечно — всё зависит от архитектуры вашего приложения.
Можно позвать на помощь препроцессоры в случаях с небольшими изменениями.
Но в БЭМ в частности в подходе разработки библиотек компонент — есть такое понятие как «темизация» https://github.com/bem/bem-components/tree/v2/design/common.blocks/link/_theme
То есть нужно понять где у вас границы темы и разложить темы в классы модификаторы. Только и всего
Будет следующее:
<a class="link link_theme_one"></a>
<a class="link link_theme_two"></a>
И тогда все будет хорошо. Вы будете точно знать какая ссылка будет использоваться в каком месте и с какой темой. Кстати в таком случае место использования совсем не важно, так как вы завязаны на «класс» ссылки и легко подобные ссылки можно будет поменять сразу во всем приложении (так чаще всего происходит при обновлении дизайна).
Вариант два — подмешать (сделать микс) другой элемент там где это нужно.
Тот же самый присловутый пример с ссылкой и пунктом меню:
и на menu__item уже навесить нужные стили, дополнив базовые стили ссылки.
Это прям крутота! Целых два варианта решения описанной проблемы! :) (на самом деле больше)
По моему опыту (а у меня его прям очень много) БЭМ никогда нигде не жмет, а делает только лучше. Значительно ускоряет разработку. Дает возможность легко передавать работу / обучать других сотрудников. Разрабатывать библиотеки. Максимально реиспользовать уже сделанное
Знали бы вы все, что за этим кроется и как эта строка изначально выглядела — так бы не говорили ;)
Этот HTML не написан руками разработчика так как вы его видите…
Кусок кода который ты привел сильно широко используется разными технологиям, т.е. это не просто HTML + CSS!
В данном случае тут смесь разных технологий, а именно:
2 разных шаблона разных компонент
js функциональность с разных уровней сборки
css c разных уровней сборки
В этом шаблоне используется такое понятие как mix (что это такое можешь сам почитать), то есть это никак нельзя равнозначно представить так как ты написал.
Если говорим только про HTML + CSS структуру, то давайте уберем все то что тут есть про JS (кстати это в системе сборки автоматом прилетает в код, как и многое другое), что бы хоть как то сравнивать.
Явно что это элемент. Значит где то выше по дереву будет сам блок menu!
Посмотрим на модификаторы. Они явно не просто так!
menu-list__link_type_simple — явно что есть более сложные реализации пункта меню. Например на основе псевдо ссылки. (про декларативную шаблонизацию по модификаторам расписывать не буду) А возможно на других блоках например на основе кнопки.
menu-list__link_size_small — явно есть другие размеры меню. кстати это работает для для всех типов этого элемента
В итоге:
Оказывается — много всего можно понять из этого кода! А я никакого отношения к написанному коду не имею. За то понимаю БЭМ. ;)
А теперь попробуй рассказать хоть что-то не очевидное про твой пример
И я всегда, когда рассказываю про плюсы, забываю рассказать о том что идет очень много всего «из коробки» вместе со стеком БЭМ, очень нужные вещи в любом процессе — минификации css/js, автопрефиксер, фриз статики… В общем все это описано в небольшом конфиге. Этот конфиг, практически без изменений, у нас используетя во всех проектах — от лендингов до больших сервисов.
Конечно окупятся. Как в любое другое про методологию, стандартизацию и тд. В любом случае в ваше коде есть компоненты которые хочется реиспользовать. Взять хотя бы bem-components, это же все нужно на любом сайте. Можно еще придумать что же общего в продуктах что вы делаете — меню, пагинатор, слайдеры, соц виджеты тоже можно представить как блок для этого есть даже либа, css сетка (причем она с js функциональностью), редактор текста можно завернуть блок и удобно подключать на проект, можно завернуть Яндекс карты в блок сделать тебе удобные методы для работы с ними, или есть у тебя в препроцессор css используется какие нибудь функции для easing’гов — можно написать и для этого блок. Причем если представить это все как библиотеку блоков которая будет подключаться к новому проекту — в сборку попадает только то что нужно. А на уровне нового проекта совсем не нужно писать код заново, ну может только стили css поправить.
Ну и даже в команде из 5 сотрудников есть тянучка кадров, я думаю команде и начальству понравится что старый код с приходом нового сотрудника будет не забыт. Методология проста и сейчас всем понятно зачем это все нужно.
В то время как все это начиналось у нас, кажется у всех небольших компаний была такая же ситуация — с отсутствием всего хорошего в разработке. В докладе я старался упоминать года, что бы был какой то тайм лайн.
Сейчас конечно все по другому. Модульный подход сегодня прослеживается во всем и уже считается нормой. Но, по моему опыту и судя по проблемам которые мне описывают люди желающие перейти на БЭМ стек, его отличает от всего, как минимум, очень гибкий и крутой шаблонизатор, который реально позволяет максимально реиспользовать код блока, на множестве проектов. Как максимум — на самом деле в БЭМ стеке целый набор всего с помощью чего кажется можно сделать все. Я не могу подобрать слова что бы оправдать «максимально реиспользовать», но в докладе был описан опыт использования другого шаблонизатора и те проблемы с которыми мы столкнулись. Я уверен что у большинства небольших компаний/веб студий у которых есть хоть какой то поток производства схожих продуктов, есть эти проблемы. Может быть аналогией крутости будет, что-то типа «блок написаный в БЭМ стеке — это как Bower пакет, только включающий в себя все технологии нужные в реализации этого блока. Причем блок можно легко переопределять/дописать не меняя базовый код». %) (Надеюсь мою аналогию ребята из яндекса поправлять или дополнят). Вот в наших процессах так же легко реиспользовать код другими подходами не получалось.
Ну про «декларативность, все написано в едином стиле, код легко передавать другим разработчикам и тд.» уже все наслышаны я думаю :).
Просто начни рассуждать как может изменяться/трансформироваться твой UI элемент если ты его захочешь реиспользовать на разных частях сайта или разных проектах.
Я всегда думал что это разработчики должны контролировать – что 95% их кода при старте не нужно инициализировать.
Поздравляю. Вы избавились от легаси :)
С
syntastic
все хорошо, :) но его заменили обычные cli утилиты запускаемые в нужное мне время. Так уж устроен рабочий флоу. Отпал за ненадобностьюЯ тоже так думал, но оно как то само отмирает. Vim все чаще для меня — хорош и без плагинов.
На счет
Ctrl+P
плагина. Он хороший и по этому он все еще установлен у меня. Он даже расширен более быстрым поиском и доп. функциями. Но есть альтернатива в видеack
илиgrep
, с ними бывает быстрее.Есть печальная история с "улучшенными поддержками языка". Например
vim-javascript
тормозит работу Vim если работаешь с файлами в 150000 строк. А мне приходится такие, как минимум, просматривать.Да. Можно еще
:Ex
или:Sex
. У NERDTree свои недостатки. Мне не удобно в нем работать в проектах с большим количеством вложенных папок и длинными названиями файлов, как бы я его не настраивал.Можно позвать на помощь препроцессоры в случаях с небольшими изменениями.
Но в БЭМ в частности в подходе разработки библиотек компонент — есть такое понятие как «темизация» https://github.com/bem/bem-components/tree/v2/design/common.blocks/link/_theme
То есть нужно понять где у вас границы темы и разложить темы в классы модификаторы. Только и всего
Будет следующее:
И тогда все будет хорошо. Вы будете точно знать какая ссылка будет использоваться в каком месте и с какой темой. Кстати в таком случае место использования совсем не важно, так как вы завязаны на «класс» ссылки и легко подобные ссылки можно будет поменять сразу во всем приложении (так чаще всего происходит при обновлении дизайна).
Вариант два — подмешать (сделать микс) другой элемент там где это нужно.
Тот же самый присловутый пример с ссылкой и пунктом меню:
и на menu__item уже навесить нужные стили, дополнив базовые стили ссылки.
Это прям крутота! Целых два варианта решения описанной проблемы! :) (на самом деле больше)
По моему опыту (а у меня его прям очень много) БЭМ никогда нигде не жмет, а делает только лучше. Значительно ускоряет разработку. Дает возможность легко передавать работу / обучать других сотрудников. Разрабатывать библиотеки. Максимально реиспользовать уже сделанное
http://habrahabr.ru/post/270075/comments/#comment_8640899
Этот HTML не написан руками разработчика так как вы его видите…
Кусок кода который ты привел сильно широко используется разными технологиям, т.е. это не просто HTML + CSS!
В данном случае тут смесь разных технологий, а именно:
2 разных шаблона разных компонент
js функциональность с разных уровней сборки
css c разных уровней сборки
В этом шаблоне используется такое понятие как mix (что это такое можешь сам почитать), то есть это никак нельзя равнозначно представить так как ты написал.
Если говорим только про HTML + CSS структуру, то давайте уберем все то что тут есть про JS (кстати это в системе сборки автоматом прилетает в код, как и многое другое), что бы хоть как то сравнивать.
Получим следующее:
Разложим mix на два компонента, получим:
ссылку
и элемент пункта меню
…
с link все понятно.
Давай разберем menu__link
Явно что это элемент. Значит где то выше по дереву будет сам блок menu!
Посмотрим на модификаторы. Они явно не просто так!
menu-list__link_type_simple — явно что есть более сложные реализации пункта меню. Например на основе псевдо ссылки. (про декларативную шаблонизацию по модификаторам расписывать не буду) А возможно на других блоках например на основе кнопки.
menu-list__link_size_small — явно есть другие размеры меню. кстати это работает для для всех типов этого элемента
В итоге:
Оказывается — много всего можно понять из этого кода! А я никакого отношения к написанному коду не имею. За то понимаю БЭМ. ;)
А теперь попробуй рассказать хоть что-то не очевидное про твой пример
Спасибо!
Ну и даже в команде из 5 сотрудников есть тянучка кадров, я думаю команде и начальству понравится что старый код с приходом нового сотрудника будет не забыт. Методология проста и сейчас всем понятно зачем это все нужно.
Сейчас конечно все по другому. Модульный подход сегодня прослеживается во всем и уже считается нормой. Но, по моему опыту и судя по проблемам которые мне описывают люди желающие перейти на БЭМ стек, его отличает от всего, как минимум, очень гибкий и крутой шаблонизатор, который реально позволяет максимально реиспользовать код блока, на множестве проектов. Как максимум — на самом деле в БЭМ стеке целый набор всего с помощью чего кажется можно сделать все. Я не могу подобрать слова что бы оправдать «максимально реиспользовать», но в докладе был описан опыт использования другого шаблонизатора и те проблемы с которыми мы столкнулись. Я уверен что у большинства небольших компаний/веб студий у которых есть хоть какой то поток производства схожих продуктов, есть эти проблемы. Может быть аналогией крутости будет, что-то типа «блок написаный в БЭМ стеке — это как Bower пакет, только включающий в себя все технологии нужные в реализации этого блока. Причем блок можно легко переопределять/дописать не меняя базовый код». %) (Надеюсь мою аналогию ребята из яндекса поправлять или дополнят). Вот в наших процессах так же легко реиспользовать код другими подходами не получалось.
Ну про «декларативность, все написано в едином стиле, код легко передавать другим разработчикам и тд.» уже все наслышаны я думаю :).
Просто начни рассуждать как может изменяться/трансформироваться твой UI элемент если ты его захочешь реиспользовать на разных частях сайта или разных проектах.