webdisigner

В двух словах - это секта

БЭМ - это такая методология вёрстки от Яндекса. Она подразумевает разбиение страниц на отдельные смысловые блоки (комментарий, пост, заголовок, футер, форма, инпут и т.п.). Каждый блок может состоять из других блоков. Основная идея - как можно больше повысить возможность повторного использования уже написанных блоков, для чего используются модификаторы. Плюс, БЭМ подразумевает отказ от каскадных стилей, потому что они препятствуют повторному использованию.
Например, на странице есть два разных заголовка (например, отдельно в статье, и отдельно во врезке). Как все привыкли делать это? есть код заголовка:
<h1 class="header">Заголовок</h1>
И мы ставим эти заголовки в текст статьи и во врезки:

<article class="article">
    <h1 class="header">Заголовок</h1>
    <p>Текст текст текст</p>
</article>
<aside class="incut">
    <h1 class="header">Заголовок</h1>
    <p>Текст текст текст</p>
</aside>

Тогда обычно мы используем каскад, чтобы стилизовать заголовок во врезке:

.header {font-size: 2em; padding-bottom: 1.5em;}
.incut .header {text-decoration: italic;}

Всё хорошо, но теперь мы не можем просто перенести эти стили заголовка во врезке в другое место, потому что эти стили привязаны именно ко врезке (классу incut). Плюс, что ещё хуже, если к элементу привязано несколько различных стилей, образующихся подобными каскадными правилами, то перенести такой внешний вид в другое место становится очень трудоёмко. А также, из-за большей специфичности каскадных стилей, их сложнее "перебить" новым стилем.
БЭМ предлагает отказаться от каскадных стилей и создавать отдельные стили-модификаторы:

<article class="b-article">
    <h1 class="b-article__header">Заголовок</h1>
    <p>Текст текст текст</p>
</article>
<aside class="b-article b-article__incut">
    <h1 class="b-article__header b-article__header_incut">Заголовок</h1>
    <p>Текст текст текст</p>
</aside>

.b-article__header {font-size: 2em; padding-bottom: 1.5em;}
.b-article__header_incut {text-decoration: italic;}

Чем больше проект, тем выгоднее использование подобной методологии. На маленьких и средних проектах БЭМ может быть избыточен. Хотя вот была статья habrahabr.ru/company/yandex/blog/234905 про использование в маленьких проектах.

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

Ну вот. Получилось не в двух словах, но менее подробно качественно описать БЭМ не получится, имхо.

Junior developer должен уметь пользоваться поиском.

через var ты объявляешь переменную, а через равно уже присваиваешь значение, например
var a = ["a", 1, true], var a = [a],
или через
var a = new Array("a", 1, true) , только здесь объявление с одним значением не работает
var a = new Array(3) - создаст пустой массив с 3 ячейками undefined

Ajax(xmlHttpRequest), Web Sockets, Web Workers, Drag&Drop API, Shadow DOM, Web Components, Canvas, SVG
это тоже должен знать/уметь frond-end-разработчик.

Все то что запускается в браузере - ваша зона ответственности. Ajax (ajax это просто возможность делать http запросы из js), все эти фреймворки и библиотеки, все все все. От бэкэнда вас целиком и полностью отделяет весьма жирная сетевая прослойка. Причем эту прослойку вы так же должны знать как слой интеграции между фронтэндом и бэкэндом (на поверхносном уровне хотя бы).

По сути сегодня фронтэнд и бэкэнд - отдельные приложения. SPA например - полностью независимое приложение, далее могут быть различные оптимизации и т.д. с сервер сайд пререндрингом где связанность повышается и четко границу ответственности уже не определить (хотя опять же можно). Ну и классический web как ярный пример каши.

Если фронтэнд - это отдельное приложение, то и знать вы должны все что нужно для его построения. Это и архитектурные штуки (MVC/MVA/MVVM/MVP/Flux/паттерны всякие/функциональное программирование) и тесты писать уметь должны и т.д. Все как у бэкэндщиков по объемам знаний. Просто у бэкэндщиков геморой обычно в конкурентных запросах, локах, базах данных и другими веселыми штуками. а у фронтэндщиков - зоопарк браузеров, различия в окружениях и т.д.

nodejs - это уже опционально. В любом случае если вы хорошо знаете JS то посмотреть как там чего в API ноды проблемы не составит (например что бы быстренько поднять expressjs сервачек для разработки с мидлвэрами, часто нужно для всяких webpack-ов и browsersync). Ну и опять же билд стэк у фронтэндщиков в принципе весь на ноде написан. Но это не бэкэнд.

Вот тут можешь попрактиковаться sql-ex.ru

Единственный эффективный инструмент систематизации знаний — ваша цель.

Когда вы понимаете и помните ЗАЧЕМ вы что-то учите, вам не нужно думать о сохранении знаний. Достаточно их просто применять для ваших задач.

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

Не нужно думать об этом, как об отдельной задаче, не эффективно.

Для того к примеру, что можно писать вот такой таск в gulp, и это круто

gulp.task('postcss', function () {
  var processors = [
    colorShort,
    focus,
    precss,
    short,
    size,
    responsiveImages,
    clearFix,
    px2Rem,
    cssNext,
    cssMqpacker,
    byeBye,
    discardComments,
    cssNano
  ];
  return gulp.src('src/css/*.css')
    .pipe(postcss(processors))
    .pipe(gulp.dest('dist/css/'))
    .pipe(browserSync.stream());
});

Ну что за бред. Бутстрап живее всех живых и вообще готовится к выходу новая его версия.
Кроме того, главная фича сегодняшнего бутстрапа в модульности. При сборке проекта через Grunt/Gulp и т.п. вы можете выбрать, какие элементы подключить. Многие используют из него только Grid, так как он очень удобен.

И вообще, удобнейшая вещь для программистов. Когда нужно запустить приложение, но нет ни фронтендера, ни дизайнера.

Я сейчас смотрю DevTips, кому-то нравится бородач кому-то нет. Тем не менее его серия про создание собственного сайта мне нравится. Это конечно не лендинг, но близко плюс дизайн с извращениями.

Использует он всё это: Jade, Sass, Jquery, Gulp, Jekyll, Atom.

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