Просто потому что это популярное решение, вот и все. Большинство придерживается того же стиля, и им будет проще перейти: это плюс как для новых разработчиков, так и для опенсорс-сообщества, например.
— 4 пробела плохо, 2 хорошо
наиболее популярное решение, нужно для читаемости при передаче проектов просто: разработчики смущаются, видя разницу в отступах в два раза. Этим пользуются почти все, так что «придерживаемся большинства».
— «name» плохо, 'name' хорошо
Опять же «придерживаемся большинства». А единообразие в кавычках необходимо, т.к. очень важно для поиска. Я выше пример писал.
— self, that плохо, _this хорошо
this обычно подсвечивается в IDE как спецслово, что помогает его визуально отличать. префикс _ тоже помогает визуально отделять ее от обычных переменных. Self и that на первый взгляд кажутся тоже обычными переменными.
Ну, вы скорее подкрепили мои намерения сделать его, но как минимум мне очень сильно помогло упоминание browserify, о котором я до этого не слышал, до этого использовал такой костыль (подсмотренный у одного товарища):
if (typeof module !== 'undefined') {
module.exports = App;
} else if (typeof exports !== 'undefined') {
exports.App = App;
} else if (!('WeakMap' in global)) {
global.App = App;
}
Если интересно — для рутинга на клиенте использую очень похожий на роутер express page.js, шаблоны — jade с рендерингом в js-модуль. Но это я потом расскажу, в одном из следующих постов.
Первое.
Не знаю как у вас, а у меня в intelliJ любая строка интеллектуально(с учетом окружения) комментируется по ctrl+/
Второе.
Появляется возможность сразу же визуально отделить блок, где находятся переменные, и блок, где находится основной код. Соответственно — видно, куда можно добавить еще одну переменную. А мы помним, что их надо добавлять в начало окружения, так как все же неправильно доверяться компилятору в переносе в рамках окружения — есть риск самому запутаться, если объявить переменную где-либо в конце. Соответственно добавлять переменные нужно именно в начале. Да и сразу можно увидеть список всех переменных окружения.
Третье.
Я не помню на моей памяти ни одного случая, когда мне реально нужно было комментировать переменную. Куски кода — да, но переменную — ни разу, максимум изменять значение или переименовывать: переменные при инициализации начинают хранить данные, а не совершать действия, и эти данные либо могут понадобиться (так что оставляем переменную), либо точно не понадобятся (удаляем). Сценарий комментирования переменной мне с трудом представляется, единственное, что приходит в голову — это нужно для заигрываний с глобальным скопом.
тут скорее «14 стандартов? чуваки, а давайте посмотрим решения, которые использует большинство, и возьмем их, а заодно опишем почему так делать — хорошо».
Все банально — единообразие. Ordnung macht frei и все такое.
Совсем недавно начал понимать, зачем на самом деле в гайдах всегда прописывается точное количество пробелов, кавычки и так далее… Все оказалось просто, это нужно для быстрого поиска по огромным проектам. Одно дело, когда ты знаешь, что нужно найти что-то вроде $('#, а другое — что надо еще учесть варианты $( '#, $("# и так далее.
Тут то же самое — вполне может быть ситуация, что надо найти, например, indexOf(name) === 5, например, и в этой ситуации расписывать еще и ={2,3} регекспом каждый раз печально. Недавно пришлось разгребать один проект — так там из-за нестыковок в нотации у разработчиков несколько раз реально 10-15 минут искал определенное обращение. К счастью, с ним пришлось работать совсем недолго.
К подобной практике приучивают и препроцессоры, тот же самый coffeeScript, например, в принципе не умеет делать ==. Если написать if a==b, он превратит это в if (a===b). Когда начинаешь пользоваться точным равенством ===, какое-то время использование сравнение через == становится, гхм, непривычным. Просто попробуйте для сравнения.
но тут же не i-bem! не bemhtml! не bemjson! нет префиксов для инкапсуляции!
аргументы были примерно такие. И, к сожалению, многие БЭМеры именно такие, судя по комментариям — их не волнует то, что за них делается инкапсуляция, их не волнует, зачем, что и как, качество кода по-прежнему оставляет желать лучшего, но зато «все по гайдам». Серьезно, пройдитесь по ссылкам в последних постах по БЭМ и посмотрите на то, как аккуратно распределен по папочкам говнокод и говностили у некоторых (срач разводить не хочу, честно, поэтому ни в кого пальцем не тыкаю в постах).
Не расписывайтесь за всех БЭМеров, имел дело с одним. Ему не понравилось, что все статические страницы (до кодинга тогда еще дело не дошло) собирались из отдельных паршиалов примерно так:
Sass тоже собирался из инклудов и состоял из компасовского резета, отдельной папочки partials под каждый отдельный блок-паршиал с соответствием именования (и да, там были классы-неймспейсы), папочки elements под общие элементы ui kit-а — инпуты, кнопочки и так далее, плюс отдельная папочка под миксины.
До истерики почти не понравилось.
github.com/polymer/ShadowDOM
пожалуйста.
На всякий случай: я до сих пор до конца не понимаю, как он работает. Но он работает, во всяком случае судя по заигрываниям с ним.
Shadow DOM полностью реализован для
Chrome Android Chrome Canary Firefox IE 10+ Safari 6+ Mobile Safari
Итого нужно дождаться:
-отмирание ie9
-отмирание android 2.3 с его браузером
так что три года я даже с запасом беру скорее.
LI.ru говорит, что ie8 у 2.1% людей, ie9 у 1.6%, safari 5 у 1.5%. Для где-то 90% браузеров это все работает уже сегодня.
В нашей команде стандарт разработки обычно предусматривает degradation до ie9, обычно это означает, что в ie9 не будут работать короткие плавные переходы на transitions, превьюшки файлов из drag-n-drop и некоторые другие мелочи, а все остальное будет, поэтому мы уже немного пробуем shadow DOM, но только в экспериментах.
Мне вот прямо хочется взять и дать ссылку на мой cornerJS, который позволяет инкапсулировать вообще весь код в проекте по директиво-ориентированному принципу: на добавление, удаление тэга или класса, изменение значения атрибута отрабатывает код, в который передается элемент. По-моему это куда более честная реализация инкапсуляции кода, чем БЭМ.
Первый попавшийся пример из ссылки:
DOM.decl('my-block', {
onSetMod : {
'js' : {
'inited': function() {
this.bindTo('click', function(e) {
var domElem = $(e.currentTarget); // DOM-элемент, на котором слушается событие
// в данном случае то же, что this.domElem
this.setMod('size', 'big');
});
}
}
}
});
И это при очень простом коде поверх нативных событий с действительно хорошим быстродействием. Да, библиотека ie9+, но для некоторых ie8+ проектов для нее делалась ручная «дергалка» на проход по дом-дереву и выявление не обнаруженных еще элементов, которая тоже неплохо отрабатывала.
И еще — можно в любой момент просто добавить <div my-block/>, и колбэк выстрелит. Сам, без напоминаний или соблюдения структуры.
Мой выбор очевиден.
Если вам недостаточно моего личного мнения — существуют проекты mozilla x-tags(ie9+) и google polymer(ie10+), которые позволяют создавать отдельные веб-компоненты, обладающие полноценной (а не костыльной, как в БЭМе) инкапсуляцией скриптов, поддержкой кастомных событий, отслеживанием изменений атрибутов — а полимер реализаует еще и инкапсуляцию стилей.
у меня нет суждений и мнений в комментарии, я просто объективно взглянул на ситуацию :)
если интересует мое личное мнение (в чем я сомневаюсь) — бэм избыточен в своей сложности для 99% проектов. Почему? Да потому что нет необходимости синхронизации отдельных команд. Нет необходимости создания библиотеки общих элементов и проблем с их совместимостью.
БЭМ — это попытка прыгнуть на пять лет вперед, радостно размахивая оперенными трехметровыми костылями
Долетели ли они до цели? Да. Ржут ли над ними? Тоже да.
Потому что единственная и первоочередная задача БЭМа — это инкапсуляция классов. Вот товарищ ниже пишет, как это все появлялось: куча разных команд делала кучу разной хрени, и нужно было их совместить. Когда начали совмещать — ясен хрен что div.mega-link оказался в десяти проектах разом. Поэтому нужно было внедрить префиксы класса. Теоретически можно было бы обойтись .block-name .element-name, но возникала проблема с вложенными блоками: если в родительском блоке и дочернем блоке были .mega-link, понятное дело что к потомку применялись свойства родителя.
Таким образом единственным возможным вариантом было создание классов .block_name__element_name.
Через уже небольшое время народ задолбался от монотонности разумного в общем-то процесса до такой степени, что решил упростить себе жизнь и сделал те самые bem-tools, без которых верстать уже некоторые попросту не умеют.
Вся подстава в том, что в реальности инкапсуляция классов уже существует и работает в Chrome, а с полифиллом (я сам был в шоке, если честно) — и ie10+ и FF, safari etc. Называется решение shadow DOM. По сути — это изолированная часть документа, внутри которой есть собственная логика, скрипты и стили, при этом снаружи повлиять на них практически невозможно. Через пару лет большинство подобных блочных проектов будет разрабатываться именно на базе shadow DOM, а про БЭМ будут помнить только фанатики и на тот момент — старперы, так как объективно он перестанет быть нужен. Это не «дискасс ит», это вполне логичная цепочка заключений: БЭМ создан для того, чтобы решить проблему инкапсуляции стилей, он решает ее, при этом избыточен, имеет определенный порог вхождения, увеличивает размер выходных файлов, через ~3 года 95% браузеров как минимум с полифиллом будут поддерживать технологию, так же решающую эту проблему, но не создающую новых.
Возможно, БЭМ трансформируется во что-то еще, но в текущем состоянии он отомрет. Хотя как промежуточная технология идеологически он хорош.
наиболее популярное решение, нужно для читаемости при передаче проектов просто: разработчики смущаются, видя разницу в отступах в два раза. Этим пользуются почти все, так что «придерживаемся большинства».
— «name» плохо, 'name' хорошо
Опять же «придерживаемся большинства». А единообразие в кавычках необходимо, т.к. очень важно для поиска. Я выше пример писал.
— self, that плохо, _this хорошо
this обычно подсвечивается в IDE как спецслово, что помогает его визуально отличать. префикс _ тоже помогает визуально отделять ее от обычных переменных. Self и that на первый взгляд кажутся тоже обычными переменными.
Если интересно — для рутинга на клиенте использую очень похожий на роутер express page.js, шаблоны — jade с рендерингом в js-модуль. Но это я потом расскажу, в одном из следующих постов.
Не знаю как у вас, а у меня в intelliJ любая строка интеллектуально(с учетом окружения) комментируется по ctrl+/
Второе.
Появляется возможность сразу же визуально отделить блок, где находятся переменные, и блок, где находится основной код. Соответственно — видно, куда можно добавить еще одну переменную. А мы помним, что их надо добавлять в начало окружения, так как все же неправильно доверяться компилятору в переносе в рамках окружения — есть риск самому запутаться, если объявить переменную где-либо в конце. Соответственно добавлять переменные нужно именно в начале. Да и сразу можно увидеть список всех переменных окружения.
Третье.
Я не помню на моей памяти ни одного случая, когда мне реально нужно было комментировать переменную. Куски кода — да, но переменную — ни разу, максимум изменять значение или переименовывать: переменные при инициализации начинают хранить данные, а не совершать действия, и эти данные либо могут понадобиться (так что оставляем переменную), либо точно не понадобятся (удаляем). Сценарий комментирования переменной мне с трудом представляется, единственное, что приходит в голову — это нужно для заигрываний с глобальным скопом.
Совсем недавно начал понимать, зачем на самом деле в гайдах всегда прописывается точное количество пробелов, кавычки и так далее… Все оказалось просто, это нужно для быстрого поиска по огромным проектам. Одно дело, когда ты знаешь, что нужно найти что-то вроде $('#, а другое — что надо еще учесть варианты $( '#, $("# и так далее.
Тут то же самое — вполне может быть ситуация, что надо найти, например, indexOf(name) === 5, например, и в этой ситуации расписывать еще и ={2,3} регекспом каждый раз печально. Недавно пришлось разгребать один проект — так там из-за нестыковок в нотации у разработчиков несколько раз реально 10-15 минут искал определенное обращение. К счастью, с ним пришлось работать совсем недолго.
К подобной практике приучивают и препроцессоры, тот же самый coffeeScript, например, в принципе не умеет делать ==. Если написать if a==b, он превратит это в if (a===b). Когда начинаешь пользоваться точным равенством ===, какое-то время использование сравнение через == становится, гхм, непривычным. Просто попробуйте для сравнения.
аргументы были примерно такие. И, к сожалению, многие БЭМеры именно такие, судя по комментариям — их не волнует то, что за них делается инкапсуляция, их не волнует, зачем, что и как, качество кода по-прежнему оставляет желать лучшего, но зато «все по гайдам». Серьезно, пройдитесь по ссылкам в последних постах по БЭМ и посмотрите на то, как аккуратно распределен по папочкам говнокод и говностили у некоторых (срач разводить не хочу, честно, поэтому ни в кого пальцем не тыкаю в постах).
Sass тоже собирался из инклудов и состоял из компасовского резета, отдельной папочки partials под каждый отдельный блок-паршиал с соответствием именования (и да, там были классы-неймспейсы), папочки elements под общие элементы ui kit-а — инпуты, кнопочки и так далее, плюс отдельная папочка под миксины.
До истерики почти не понравилось.
Mac Pro, 2х 6-core Xeon, 64 gb RAM, Google Chrome 31.0.1650.57, OS X. Разницы в производительности нет.
Checked (параметр html-ноды, не атрибут) запускает событие change:
document.querySelector('input').checked = true
Корректно и правильно возможно отлавливать изменение любого атрибута, в том числе disabled, только так(возможно, где-то есть баг, я не проверял код):
С полифиллом будет ie9+. А
не вижу сути проблемы
пожалуйста.
На всякий случай: я до сих пор до конца не понимаю, как он работает. Но он работает, во всяком случае судя по заигрываниям с ним.
Shadow DOM полностью реализован для
Chrome Android Chrome Canary Firefox IE 10+ Safari 6+ Mobile Safari
Итого нужно дождаться:
-отмирание ie9
-отмирание android 2.3 с его браузером
так что три года я даже с запасом беру скорее.
LI.ru говорит, что ie8 у 2.1% людей, ie9 у 1.6%, safari 5 у 1.5%. Для где-то 90% браузеров это все работает уже сегодня.
В нашей команде стандарт разработки обычно предусматривает degradation до ie9, обычно это означает, что в ie9 не будут работать короткие плавные переходы на transitions, превьюшки файлов из drag-n-drop и некоторые другие мелочи, а все остальное будет, поэтому мы уже немного пробуем shadow DOM, но только в экспериментах.
Первый попавшийся пример из ссылки:
вариант на директиве:
И это при очень простом коде поверх нативных событий с действительно хорошим быстродействием. Да, библиотека ie9+, но для некоторых ie8+ проектов для нее делалась ручная «дергалка» на проход по дом-дереву и выявление не обнаруженных еще элементов, которая тоже неплохо отрабатывала.
И еще — можно в любой момент просто добавить <div my-block/>, и колбэк выстрелит. Сам, без напоминаний или соблюдения структуры.
Мой выбор очевиден.
Если вам недостаточно моего личного мнения — существуют проекты mozilla x-tags(ie9+) и google polymer(ie10+), которые позволяют создавать отдельные веб-компоненты, обладающие полноценной (а не костыльной, как в БЭМе) инкапсуляцией скриптов, поддержкой кастомных событий, отслеживанием изменений атрибутов — а полимер реализаует еще и инкапсуляцию стилей.
если интересует мое личное мнение (в чем я сомневаюсь) — бэм избыточен в своей сложности для 99% проектов. Почему? Да потому что нет необходимости синхронизации отдельных команд. Нет необходимости создания библиотеки общих элементов и проблем с их совместимостью.
БЭМ — это попытка прыгнуть на пять лет вперед, радостно размахивая оперенными трехметровыми костылями
Долетели ли они до цели? Да. Ржут ли над ними? Тоже да.
Потому что единственная и первоочередная задача БЭМа — это инкапсуляция классов. Вот товарищ ниже пишет, как это все появлялось: куча разных команд делала кучу разной хрени, и нужно было их совместить. Когда начали совмещать — ясен хрен что div.mega-link оказался в десяти проектах разом. Поэтому нужно было внедрить префиксы класса. Теоретически можно было бы обойтись .block-name .element-name, но возникала проблема с вложенными блоками: если в родительском блоке и дочернем блоке были .mega-link, понятное дело что к потомку применялись свойства родителя.
Таким образом единственным возможным вариантом было создание классов .block_name__element_name.
Через уже небольшое время народ задолбался от монотонности разумного в общем-то процесса до такой степени, что решил упростить себе жизнь и сделал те самые bem-tools, без которых верстать уже некоторые попросту не умеют.
Вся подстава в том, что в реальности инкапсуляция классов уже существует и работает в Chrome, а с полифиллом (я сам был в шоке, если честно) — и ie10+ и FF, safari etc. Называется решение shadow DOM. По сути — это изолированная часть документа, внутри которой есть собственная логика, скрипты и стили, при этом снаружи повлиять на них практически невозможно. Через пару лет большинство подобных блочных проектов будет разрабатываться именно на базе shadow DOM, а про БЭМ будут помнить только фанатики и на тот момент — старперы, так как объективно он перестанет быть нужен. Это не «дискасс ит», это вполне логичная цепочка заключений: БЭМ создан для того, чтобы решить проблему инкапсуляции стилей, он решает ее, при этом избыточен, имеет определенный порог вхождения, увеличивает размер выходных файлов, через ~3 года 95% браузеров как минимум с полифиллом будут поддерживать технологию, так же решающую эту проблему, но не создающую новых.
Возможно, БЭМ трансформируется во что-то еще, но в текущем состоянии он отомрет. Хотя как промежуточная технология идеологически он хорош.