Благодаря этому блоки можно легко менять местами, вкладывать друг в друга и не бояться конфликтов или влияния.
Это надуманная проблема, в реальной разработке в такой гибкости нет необходимости. Те элементы, у которых позиция в разметке может измениться, должны верстаться с учетом возможных изменений и без всяких БЭМ. Среди остальных элементов в любом случае будут элементы, изменение позиции которых потребует изменения стилей, это уже вопрос дизайна и БЭМ здесь ничего не решает.
Чем лучше, пытаетесь меня просто прогнать? Если вам что-то не нравится в моей статье, можете зайти и покритиковать. Ваша статья от этого лучше не станет. Снос кармы лишь подтверждает ее посыл.
Проще говоря, это завуалированный пиар. Надо было тщательней маскировать свой фанатизм. Демонстрация недостатков не имеет отношения к реальной жизни. При этом захваливание носит откровенно религиозный характер. Может тогда и просмотров было бы больше. Следующую статью писать не надо.
Из статьи может показаться, что БЭМ появился в 2015 году, как следствие несовершенства всех остальных подходов, а не 10 лет назад, как попытка взять под контроль табличный говнокод в Яндексе. В целом, очередная раздача костылей под красивое описание годных практик, которым БЭМ противоречит.
Трюк с прибитым футером очень костыльный, кстати. Добавляя эту фишку вы создаете пространство для очень коварных багов, что в общем и случилось. Его очень легко вывести из строя совершенно несвязанным с футером кодом. Думаю, что удобство от прибитого футера не стоит создаваемых костылей. Но это не оправдывает того, что сделали в Яндексе, это вообще ни в какие ворота не лезет.
Если человек способен решать необходимые задачи, каким образом он приходит к решению интересовать не должно, это уже личное дело разработчика. Понятно, что работодателю интересно поковыряться везде, но должны быть рамки. Разработчик в итоге справился с задачей — он способен решать такие задачи, все просто.
Смотреть за процессом решения задачи — очень плохая практика. Это как удар ниже пояса. Понимание того, что тебя оценивают по заведомо не готовому коду, не дает сосредоточиться на поиске решения. В итоге унижение неизбежно, даже если с задачей справляешься.
Думаю, что не единственный. Отказ от каскадности это одно из следствий еще более серьезной проблемы — сопровождаемость верстки в HTML. Если смотреть на сапровождаемость верстки через HTML, CSS со своим разнообразием всегда будет проблемой для БЭМ.
Оказаться опытнее он может. Готов ли интервьюер доказывать свой опыт каждому кандидату,
решая их задачи по программированию, в этом суть. Я вполне допускаю, что существуют интервьюеры, которые в ответной задаче увидят шанс блеснуть своим мастерством. В моем представлении о собеседованиях такая реакция кажется маловероятной.
Такое может произойти, если вернуть интервьюеру его же задачу. В ветке имелась ввиду ситуация, когда кандидат проверяет уровень интервьюера своей задачей. Мол раз ты хочешь, чтобы я доказывал свой уровень, решая твои задачки, то и ты докажи свой уровень, решая мои задачки.
Ответная задачка интервьюеру — хорошая и совершенно справедливая идея, что-то вроде мести. Думаю, что все интервьюеры, которые отбирают кандидатов подобными задачками, получив такую же задачу в ответ от кандидата, сразу поймут насколько это плохой способ отбора. Вот только на практике такой поворот скорее всего будет воспринят как неимоверная наглость, что приведет к моментальному прощанию с кандидатом. Сложно представить себе интервьюера, который опустится до решения такой задачки.
Типа я ищу разработчиков, но не вы мне нужны, а я вам. У меня деньги — построились и пляшем. К таким работодателям опытные разработчики обычно даже не приходят, а работу получают те, кто лучше пляшет. Выбрать из 50 кандидатов с портфолио одного или несколько подходящих — совсем несложно.
Все верно, кандидатов надо отбирать по портфолио. Очень часто, устраивая всякого рода экзамены, работодатель ищет не знания, а пробелы в знаниях для сбивания цены. Типа ищем опытного сантехника и устраиваем ему экзамен по сопромату и атлетике. Чем больше кандидат рвет пупок и тратит времени, тем легче после этого будет сбить цену.
Другими словами, хотите заработать, создавайте бизнес, а через Open Source проект привлекайте клиентов. Вряд ли это можно назвать заработком на Open Source. Мне кажется, ценность свободных лицензий сегодня несколько преувеличена. Всему свое место, и в определенных случаях намного лучше идти в сторону проприетарных лицензий.
Вы думаете, что гугл все это раздает по доброте душевной? Подключение jQuery с чужих серверов хороший пример того, как поставить свой проект под чужое влияние и ничего не получить взамен.
решая их задачи по программированию, в этом суть. Я вполне допускаю, что существуют интервьюеры, которые в ответной задаче увидят шанс блеснуть своим мастерством. В моем представлении о собеседованиях такая реакция кажется маловероятной.