JavaScript как праздник

Второй минус, это производительность на стадии инициализации. Уже часто встречаются кривые сайты тормозящие при старте.

Я всегда думал что это разработчики должны контролировать – что 95% их кода при старте не нужно инициализировать.

Javascript-фреймворки: должен остаться только один

Поздравляю. Вы избавились от легаси :)

Опыт перехода с Sublime на Vim

С syntastic все хорошо, :) но его заменили обычные cli утилиты запускаемые в нужное мне время. Так уж устроен рабочий флоу. Отпал за ненадобностью

Опыт перехода с Sublime на Vim

Я тоже так думал, но оно как то само отмирает. Vim все чаще для меня — хорош и без плагинов.

На счет Ctrl+P плагина. Он хороший и по этому он все еще установлен у меня. Он даже расширен более быстрым поиском и доп. функциями. Но есть альтернатива в виде ack или grep, с ними бывает быстрее.

Есть печальная история с "улучшенными поддержками языка". Например vim-javascript тормозит работу Vim если работаешь с файлами в 150000 строк. А мне приходится такие, как минимум, просматривать.

Опыт перехода с Sublime на Vim

Да. Можно еще :Ex или :Sex. У NERDTree свои недостатки. Мне не удобно в нем работать в проектах с большим количеством вложенных папок и длинными названиями файлов, как бы я его не настраивал.

Опыт перехода с Sublime на Vim

У меня был подобный опыт перехода. Был похожий vim конфиг. Было время когда держал конфиг Sublime Text вместе в vim. Совсем недавно удалил все про саблайм. Но со временем и большим изучением vim, я начал избавляться плагинов, что никак не ухудшало работу с vim. Вот тут можно посмотреть иторию коммитов voischev/dotfiles Надеюсь кому то будет полезно

БЭМ-методология: с чего всё начиналось и зачем это всё нужно

Все правильно — разложив все по папочкам это еще не значит что все не взорвется. Особенно если руки из одного места

БЭМ — методология развешивания костылей

Как-то, сильно уж противоречиво написали. Никто никого не заставляет, скорее рекомендуем. Кстати ваше корпоративная wiki и то, что сложилось в голове, ничем не лучше и не хуже что вам предлагают.

30 лет С++

По такому поводу хочется включить, всем известную, песню группы «Сектор Газа» :)

БЭМ — методология развешивания костылей

Я привел пример решения поставленной задачи причем выглядит круто! А как бы вы решили эту задачу? :)

БЭМ — методология развешивания костылей

Да конечно — всё зависит от архитектуры вашего приложения.

Можно позвать на помощь препроцессоры в случаях с небольшими изменениями.
Но в БЭМ в частности в подходе разработки библиотек компонент — есть такое понятие как «темизация» 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>

И тогда все будет хорошо. Вы будете точно знать какая ссылка будет использоваться в каком месте и с какой темой. Кстати в таком случае место использования совсем не важно, так как вы завязаны на «класс» ссылки и легко подобные ссылки можно будет поменять сразу во всем приложении (так чаще всего происходит при обновлении дизайна).

Вариант два — подмешать (сделать микс) другой элемент там где это нужно.
Тот же самый присловутый пример с ссылкой и пунктом меню:

<nav class="menu">
    <a class="link menu__item"></a>
</nav>

и на menu__item уже навесить нужные стили, дополнив базовые стили ссылки.

Это прям крутота! Целых два варианта решения описанной проблемы! :) (на самом деле больше)

По моему опыту (а у меня его прям очень много) БЭМ никогда нигде не жмет, а делает только лучше. Значительно ускоряет разработку. Дает возможность легко передавать работу / обучать других сотрудников. Разрабатывать библиотеки. Максимально реиспользовать уже сделанное

БЭМ — методология развешивания костылей

А вот еще на что можно посмотреть. https://github.com/rajdee/posthtml-bem инструмент еще проще. И можно использовать с любым шаблонизатором

БЭМ — методология развешивания костылей

Недавно в ленте твиттера было сообщение о том что автор OOCSS или SMACSS писал что бы люди использовали БЭМ вместо того что он придумал

БЭМ — методология развешивания костылей

Вам этот комент тоже не помешало бы прочитать :)
http://habrahabr.ru/post/270075/comments/#comment_8640899

БЭМ — методология развешивания костылей

Не говорю даже про плюсы в чуть более сложных проектах для верстки, чем «Landing Page» :)

БЭМ — методология развешивания костылей

Знали бы вы все, что за этим кроется и как эта строка изначально выглядела — так бы не говорили ;)

Этот HTML не написан руками разработчика так как вы его видите…

Кусок кода который ты привел сильно широко используется разными технологиям, т.е. это не просто HTML + CSS!

В данном случае тут смесь разных технологий, а именно:

2 разных шаблона разных компонент
js функциональность с разных уровней сборки
css c разных уровней сборки


В этом шаблоне используется такое понятие как mix (что это такое можешь сам почитать), то есть это никак нельзя равнозначно представить так как ты написал.

Если говорим только про HTML + CSS структуру, то давайте уберем все то что тут есть про JS (кстати это в системе сборки автоматом прилетает в код, как и многое другое), что бы хоть как то сравнивать.

Получим следующее:

<a class="link menu-list__link menu-list__link_type_simple menu-list__link_size_small"></a>

Разложим mix на два компонента, получим:

ссылку

<a class="link"></a>

и элемент пункта меню

<div class="menu-list__link menu-list__link_type_simple menu-list__link_size_small"></div>

…

с link все понятно.

Давай разберем menu__link

Явно что это элемент. Значит где то выше по дереву будет сам блок menu!

Посмотрим на модификаторы. Они явно не просто так!

menu-list__link_type_simple — явно что есть более сложные реализации пункта меню. Например на основе псевдо ссылки. (про декларативную шаблонизацию по модификаторам расписывать не буду) А возможно на других блоках например на основе кнопки.

menu-list__link_size_small — явно есть другие размеры меню. кстати это работает для для всех типов этого элемента

В итоге:

Оказывается — много всего можно понять из этого кода! А я никакого отношения к написанному коду не имею. За то понимаю БЭМ. ;)

А теперь попробуй рассказать хоть что-то не очевидное про твой пример

<a class="menu-link"></a>

Спасибо!

19 принципов разработки по БЭМ, или что должен знать каждый разработчик библиотек

Спасибо за БЭМ! Всегда следовал, не гласно, этим правилам. Хорошая практика.

Сайт с нуля на полном стеке БЭМ-технологий. Методология Яндекса

И я всегда, когда рассказываю про плюсы, забываю рассказать о том что идет очень много всего «из коробки» вместе со стеком БЭМ, очень нужные вещи в любом процессе — минификации css/js, автопрефиксер, фриз статики… В общем все это описано в небольшом конфиге. Этот конфиг, практически без изменений, у нас используетя во всех проектах — от лендингов до больших сервисов.

Сайт с нуля на полном стеке БЭМ-технологий. Методология Яндекса

Конечно окупятся. Как в любое другое про методологию, стандартизацию и тд. В любом случае в ваше коде есть компоненты которые хочется реиспользовать. Взять хотя бы bem-components, это же все нужно на любом сайте. Можно еще придумать что же общего в продуктах что вы делаете — меню, пагинатор, слайдеры, соц виджеты тоже можно представить как блок для этого есть даже либа, css сетка (причем она с js функциональностью), редактор текста можно завернуть блок и удобно подключать на проект, можно завернуть Яндекс карты в блок сделать тебе удобные методы для работы с ними, или есть у тебя в препроцессор css используется какие нибудь функции для easing’гов — можно написать и для этого блок. Причем если представить это все как библиотеку блоков которая будет подключаться к новому проекту — в сборку попадает только то что нужно. А на уровне нового проекта совсем не нужно писать код заново, ну может только стили css поправить.

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

Сайт с нуля на полном стеке БЭМ-технологий. Методология Яндекса

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

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

Ну про «декларативность, все написано в едином стиле, код легко передавать другим разработчикам и тд.» уже все наслышаны я думаю :).

Просто начни рассуждать как может изменяться/трансформироваться твой UI элемент если ты его захочешь реиспользовать на разных частях сайта или разных проектах.