Тут скорее ваши предпочтения не совпадают с теми, что у разработчиков Vue

Мне видится обратная ситуация

Документация не соотносится с тулингом от слова «совсем» и уж тем более, время ее перевода на русский (без английского в деве вообще тяжко, да)
Браузерный DevTools у Реакта — ничем не уступающий Вьюшному.
«найди на npm и собери сам» — скорее плюс, никто не прибивает разработчика гвоздями к той или иной библиотеке роутинга, или стейт менеджеру, как хочешь, так и варись
Не хочется собирать все по частям? Ставишь CRA, делаешь eject, бойлерплейт проект готов
Впрочем это уже тонкости, и к изначальному поинту не имеют никакого отношения

Не холивара ради, но Vue многие боятся не потому что он не мейнстрим, а потому что много магии и никакущий тулинг, как только нормальный DX завезут, глядишь можно и работать будет

Ставишь нормальный пресет, и ничего в var не транспайлится. Кто в 2018 году не умеет в const и let? По моему только легаси браузеры, нет?

ES6 это все конечно прекрасно, но неужели нельзя было найти адекватный источник?
(Неконсистентное форматирование, отсутствие пробелов там, где они нужны, что приводит код к виду «каши», автор форсит let повсеместно, ошибки в названиях переменных банально)
Ну правда, выглядит как «мы взяли первую статью попавшуюся под руку, шлепнули перевод, надо же корпоративный блог пиарить»
#nooffense
UPD: Берцовой костью чуял, оригинал индусский. Вот прям не подвела чуйка, когда глянул в оригинал. Ровно как и дата публикации

Алсо, есть мнение, что хипстеры без импортов нынче не живут (на самом деле, даже «деды» уже без них не живут), поэтому обозреваемый код можно одним движением ловко превратить в:

import {toString, chunksToLines, trim, print} from './mySupaHelperLib';

async function main() {
    const subproc = spawn('ls');

    await subproc.stdout
    |> toString
    |> chunksToLines
    |> trim
    |> print;

    console.log('DONE');
}

faiwer — уже упомянул об этом, однако я забыл к своим аргументам добавить этот пункт, соре за даблпост :D

Да я тут оставлю, думаю никто против не будет.
— Тестируемость
— Удобочитаемость с тайпингами (если будет jsDoc, то можно сразу сушить весла, с TS/Flow — будет просто каша словесная)
— Для того, чтобы понять что происходит, нужно посмотреть только в main(), а не шариться по всему циклу в поисках правды сути
— Повышенная модульность (я легко могу заменить один из элементов логики на любой другой в любой момент времени, без потерь нервов)
— Разделение ответственности (в принципе, это суммирует перечисленные до бенефиты)
— Возможность быстро перейти к телу метода (почти каждая IDE сейчас умеет это, сильно ускоряет работу, при этом не мозоля глаза лишним кодом, который не нужен в данный момент)

Да, второй код В КАКОМ ТО СМЫСЛЕ многословнее, однако нет необходимости спускаться на все уровни абстракций. Можно заглянуть в самый верхний метод и понять, что происходит, буквально за 10 строк. Мы сводим к минимуму словестность самого верхнего метода, его легко читать.

Разработчику не обязательно знать, что происходит внутри каждого из используемых методов(покуда он не хочет изменить его реализацию). Опять же, при желании что то поменять в цепочке методов, важно не задеть остальной функционал, в том, что Вы привели, связи становятся куда менее очевидными.

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

Можно и без функций, переменных, циклов, можно вообще в байткоде сразу писать, че уж там. Чай без сахара пьем, так еще и в JS этой гадости не хватало!
(жаль, только что «говнокод» читается на раз, а эту портянку «ИДЕАЛЬНЕЙШЕГО КОДА» еще парсить энное количество времени придется)
((еще бы let и const научиться юзать по назначению, вообще хорошо бы было))

Это уже настолько избитый вопрос, как требования к джуну, сколько времени нужно на то, чтобы стать сениором, или typescript vs flow. Каждый раз люди измеряют коней в вакууме, каждый раз приводят субъективные аргументы и так далее. У всех есть свои минусы и плюсы, раскрывающиеся как правило в специфичных случаях. На этапе вхождения тут всё ± однолико. От этих плюсов и минусов можно отталкиваться, при старте проекта, в зависимости от его специфики. И такие моменты было бы неплохо осветить.
На вероятность ошибки влияет не столько количество бойлерплейта, сколько возможность языка/фреймворка дать эту ошибку допустить. Сам «бойлерплейт» предполагает гибкость решения, это компромисс, за который мы расплачиваемся. На данный момент в сети тучи пакетов, уменьшающих этот бойлерплейт. Кто-то на опыте пишет свои велооптимизаторы, не все так плохо.

Знакомая ситуация. Но тут мне опять же сложно ответить, ибо я не знаю, насколько инертен мир шарпистов, я там мимокрокодил, только примитивщину писал.
По миру JS могу сказать, что если в проекте есть легаси, это надо искоренять(сейчас активно занимаемся этим в нашей компании). Через полгода-год Вы уже не найдете банально адекватного разраба на такое, и будете либо доплачивать за легаси, либо работать с джунами, которым лишь бы опыт получить.
Проект и не должен быть написан на bleeding edge технологиях, но тянуть в него легаси просто потому что оно там уже было — неправильно, это только свалит проект в еще больший застой, и ни к чему хорошему не приведет.
Соответственно, писать/читать книги по таковым, для меня сомнительное занятие. Я не против такой информации, но опять, повторюсь же, в книжном печатном формате это бессмысленно. Цифровые дайджесты, серии статей на ресурсах — да, но книги — нет.

Методы работы с оперативкой, файловой системой как раз таки можно отнести к фундаментальщине же. Разбор фреймворков — нет. Да и стоит учитывать, что в 80-х годах особо не было вариантов для передачи и хранения информации в бытовом варианте, кроме книг то :D
Мне сложно сравнивать BASIC и JS, покуда с первым я знаком только понаслышке, но могу заявить, что сегодня дома отказался работать проект из-за разницы в версии ноды 9.6.1 -> 9.9.0, притом, что на работе таковая 9.8.*
(Обновлялся дома около месяца назад, и она уже(!) устарела и работает некорректно)

Это конечно так, но вот релизнутся в этом году декораторы и пайплайн операторы, приватные методы/поля классов, и станут новым стандартом, а в книге про них ничего. Однако они в пропосалах уже больше года висят, и ими свободно пользуются через полифилы/трайнспайлеры того же бабеля. И прочитает человек в середине 2018 такую книгу, увидит запись:

let string = 'hello' |> trim |> capitalize |> escape;

И даже если догадается, по каким кейвордам гуглить, пойдет гуглить, а не искать реиздание за этот год. То что мажорного релиза давно не было, не значит, что это не сломает зависимости с другими актуальными пакетами, то есть человеку так или иначе придется сесть на старый стек, просто потому что он купил такую книгу. Учитывая количество зависимостей в типовом JS проекте, мелкие изменения могут накопиться в немалую кучу. Такой вид информации это просто не книжный формат, вот что я пытаюсь донести.
Если на хабре выпустят статью по технологии 2хлетней давности, все закидают автора камнями, «як же так?!». Но почему то с книгой, за которую человек отдает деньги этот трюк не работает. Однако двойственность стандартов, не?

А что в бейсике нефундаментального? Там Алгоритмы, какие то общие паттерны программирования, и все. Как я и сказал, такие вещи можно и нужно паковать в книги. И они будут актуальны и через 10 и через 20 лет. Сказать такое про JS сложно, просто потому, что между теми же ES кучи обратнонесовместимых фич, и даже основы программирования на JS через пару лет будут выглядеть моветоном в глазах более продвинутых коллег.

Эволюцию никто не отменял, но преимущество ног перед плавниками, при ходьбе, очевидно и без книг. Если целью является рассмотрение процесса эволюции технологии, об этом и следует писать. Тут акцентируется внимание на стеке 2хлетней давности. Книга предполагается как источник знаний, не утрачивающий свою актуальность длительное время, иначе это просто пустой расход бумаги.
В книге версия ноды отличается уже на 3 релиза, и это на момент выхода. На дворе в спецификации уже стейджится es2018, в книге es2015. Плагины по бабелю и все что с этим связано меняются чуть ли не каждые полгода стабильно, перетекая от вендора к вендору. И это только по оглавлению и кускам текстов. Будет ли эта книга актуальна хотя бы к концу 2018? Я очень сомневаюсь.

Ееее, реконсил vDOM'a каждые 10 мс, а потом люди говорят, что реакт лагучий (можно было по requestAnimationFrame хотя бы сделать, а еще лучше по событию движения мыши с троттлингом до 60 раз в секунду). Перевод неплох, но сама статья ни о чем. Вообще непонятно, зачем для такой задачи было прикручивать реакт/редакс, это из серии «вот так, буханку хлеба можно превратить в троллейбус». Для новичков много непонятных моментов, для неновичков — ничего нового, да и в целом, код написан так себе (анонимные функции в рендере, не чистятся ресурсы после анмаунта, ...)

Кто то жалуется, что у ЯП нынче слишком низкий порог вхождения, кто то, что сложно поставить IDE по гайду из интернетов. Вот честно, #nooffense, но статья такой бред. Вот описан прям таки пользователь ПК возрастной планки 60+ начала 2000-х (ну, немного утрируя конечно). И программу то поставить в тягость, и принципы то понять — в тягость, и все сложно, пойду грядки окучу. Конкретно для питона — устанавливаешь компилятор + IDE (под Windows идут пакетно) — пишешь код. Надуманность проблемы — колоссальна, увы, жалею потраченное время :(