Каково учить JavaScript в 2020

Есть отличная статья на хабре — Каково оно учить JavaScript в 2016. Там все актуально для 2016, но диалог можно продолжить так:

— За последние 3 года, стало немного получше!
— И чем же?
— TypeScript почти норма, все новые фичи в JS это зачастую концепты TS. И если ты пишешь на актуальном TS, то тебе не нужно париться. Скорее всего ты используешь все самое новое. Сборщики умеют все это упаковывать, так что тебе не стоит париться на счёт поддержки браузерами, скорее всего есть polyfill’ы. Но это не главное. За прошедшее время Angular, React и Vue, почти монополизировали рынок и сейчас все пишут на них.
— И что же это меняет? Раньше они были, а ты мне называл миллион технологий, чтобы все это собрать.
— Сейчас все делается с помощью webpack или любого другого решения (например bazel в Angular). Там и делается дифференциальная загрузка.
— Это еще зачем?
— Ну если браузер не поддерживает новые возможности языка, грузиться отдельный файл с polifill’ами, а в новых и последний браузерах polifill’ы загружаться не будут, а значит размер сборки будет меньше.
— Хорошо, возможно со сборкой стало проще, а как же Common и System js?
— Сейчас этого нет, почти нет?
— В смысле нет?
— Ну в es приняли правила по организации модулей, и проблема решена, и теперь не нужно заморачиваться с типами модулей. Осталась проблема с миграцией старого кода. И раньше в библиотеках использовались глобальные объекты — window, global, а сейчас их использовать напрямую нельзя.
— Почему нельзя? А как работать с DOM?!
— Вот именно, у тебя может не быть DOM, например в NodeJS. Тут больше проблема с мобильными устройствами.
— С какими мобильными устройствами?
— Сейчас большая часть трафика генерируют мобильные устройства. Поэтому сейчас стараются разрабатывать решения с помощью JS, но для мобильных устройств.
— Это electron что-ли?
— Да, но сейчас появился NativeScript, который позволяет переводить код из Angular/React/Vue компонентов в нативные элементы для телефона. Angular вообще нативно поддерживает NativeScript и ты можешь сразу разрабатывать приложение как для декстопа, так и мобильное приложение, которые в основе будут иметь одну кодовую базу, но после сборки ты получишь отдельно Web-версию и скомпилированное мобильное приложение, которое можно разместить в AppStore или GooglePlay.
— О господи. Но как контролировать кодовую базу. Ведь у тебя будут различия между веб и мобильной версией!
— Конечно, и для этого придумали моно репозитории. Ты можешь использовать либо lerna или nx. Lerna поддерживает все современные фреймворки, а Nx Angular и React.
— И что выбрать?
— Если используешь Angular, то выбирай Nx. Там ничего сложного. Сложнее только RxJS.
— RxJS? А это что?
— Помнишь, я рассказывал о Promise?
— Да, что-то про автоматизацию callback’ов и async/await.
— Да, но RxJS это ещё круче, если promise это один поток, то RxJS это множество потоков, с возможностью подписки, отписки и других прелестей. Фронтенд, особенно вёрстка преображается с ним. Это всё из-за того, что в коде, все данные реактивные и ты не можешь получить к ним доступ.
— Зачем мне использовать Rx, если при этом у меня появляются проблемы с вёрсткой?
— Так принято, но скорее всего это нужно для того, чтобы ты смог реализовать свой Store, и не мог изменять данные из вне.
— Что ещё за Store?
— Я тебе рассказывал про Flux и Redux. Так вот, Redux сейчас есть в каждом фреймворке и если ты хранишь данные не там, то это плохо. А так как у тебя все данные реактивные, то к ним особый доступ.
— Хорошо, и как его использовать. В Angular, Store использует rxjs, но там две реализации Ngrx и Ngxs, в Vue — vuex, в React все зависит от того, что ты используешь. Но тебе также не стоит забывать о SSR.
— SSR? Ты хотел сказать о СССР?
— Server Side Rendering — отрисовка твоих страниц на стороне сервера.
— Шта? Какой сервер, мы говорим о фронте.
— Ну почти… Раньше для того, чтобы твой сайт индексировался, поисковику нужно было посмотреть исходный код страницы, а так как сейчас всё работает с помощью JS, то код страницы будет пустой. Для СЕО нужно предкомпилированный шаблон заполнить данными. Для этого поднимается отдельный сервер, чаще всего на NodeJS.
— Отдельный сервер только для того, чтобы раздавать странички для СЕО?
— Нет, это раньше было так, но сейчас SSR это мощная техника для оптимизации и ускорения приложения. Ты можешь заранее подготовить список данных и вставить на сервере, вместо того, чтобы делать несколько запросов с клиента.
— А в чем это плохо?
— Не плохо, ты можешь просто делать 1 запрос вместо множества запросов. Это быстрее и меньше нагрузки на сервер. Видел яндекс музыку? Вот там это есть, в каком-то виде.
— Хорошо, посмотрю.
— Но там у них странное API. Если раньше использовался REST, то сейчас набирает популярность GraphQL.
— Чем REST плох?
— Он хорош, но GraphQL еще лучше. Ты можешь описывать формат данных на клиенте и получать их с сервера. Это очень гибко и функционально. Также сервер может кешировать запросы и оптимизировать их.
— Окей, и как использовать GraphQL?
— Тебе нужно использовать одну из реализаций GraphQL, Apollo например.
— И это все?
— Мы ещё не говорили о PWA.
— Про клей?
— Нет, Progressive Web Application. Например, доступ к твоему веб приложению, когда нет интернета. А также может кешировать запросы и прочее. Обычно это делается с помощью Service Worker. Он формально проксирует запросы, и если сети нет, то вернёт сохранненные данные.
— А зачем это нужно? Ведь если интернета нет, то и данные вряд ли актуальны.
— Это ты в России привык к хорошему, дешёвому, высокоскоростному интернету. А если у тебя плохой и медленный интернет, который постоянно отваливается, твое приложение постоянно будет грузиться. PWA решает эту проблему. Но Service это не единственный worker, есть просто web worker’ы.
— Web worker’ы?
— Да, они позволяют вынести все высоконагруженные запросы и обработки в отдельный поток, тем самым повысить производительность приложения. Но ты вряд ли с этим столкнешься.
— Это уж точно.
— Все будет зависеть какой фреймворк и какое cli ты будешь использовать.
— Cli? Консоль, я вновь не ослышался?
— Конечно, консоль, как без неё. Ведь тебе нужно запускать дев сервера, запускать SSR сервер, создавать новые шаблоны и компоненты. Написано много генераторов, где написав команду, ты получаешь сгенерированный набор файлов, которые уже интегрированы в твоё приложение. Уже не говоря о всяких вспомогательных утилитах, которые ищут зависимости между твоими компонентами, строят деревья зависимостей, а также анализируют размер и т.д.
— Генераторы это же такое себе решение, там нет гибкости.
— Ошибаешься, например в Angular все построено на schematics. Это формат описания шаблонов. Чисто идейно ты можешь написать такую команду, которая будет создавать все, что ты захочешь. Ты можешь использовать кастомные шаблоны, просматривать текущие файлы, добавлять конфигурацию в приложение.
— И это обязательно? Нет, но это очень упрощает жизнь. Это как различными линтерами. Вроде все просто, а они помогают держать код в едином стиле.
— Стоп, линтеры только проверяют код, но ты не обязан соблюдать его.
— Это так раньше было. Сейчас есть множество инструментов, которые позволяют не просто проверять правила, но и сразу менять код — авто форматирование кода с пользовательскими правилами. Например, сейчас очень популярен Prettier.
— И как он переписывает?
— Просто, сохраняешь код, а prettier сразу форматирует твой код. Если не хочешь живых правок, можешь написать команду, которая перед коммитом отформатирует код.
— Интересно.
— Ах да, ещё пара слов о тестировании.
— Ой, нет, нет. Опять эти mocha, karma и другие. Часами ждёшь запуск браузера и миллион тестов.
— Да успокойся, там все тоже поменялось. Ребята из facebook постарались и выпустили jest. Jest это фреймворк для unit тестирования. Очень шустрый и очень прикольный.
— И что крутого в нем?
— Абсолютно все. Прогнать более тысячи тестов за пару секунд? Легко. Запустить marble tests? Без проблем. Тебе однозначно стоит взглянуть на него. Хотя почти все современные фреймворки перешли на Jest. Даже в Angular есть адаптеры для Jest.
— Но это все unit тестирование. А как же комплексное тестирование?
— А там тоже все хорошо. Сейчас популярность набирает Cypress.
— Я правильно понимаю, что нет ничего, что осталось с нашего первого разговора и работает почти 3 года.
— Ну как же. Все современные фреймворки были и три года назад. Хотя они тоже внутри поменялись, и вообще можно сказать, что это новые решения на новых технологиях…

Спасибо за внимание! :)