К сожалению, многие фронт-энд разработчики начинают изучать JavaScript сразу с популярных фреймворков, таких как Reactjs, angular или на худой конец jquery.
С одной стороны это позволяет писать какие-то простые и узко специфичные вещи буквально сразу, без долгого изучения языка, понимания его специфики и прочих "скучных" вещей.
С другой стороны появляется проблема, разработчик на первый взгляд может иметь не плохой опыт в пользовании конкретным фреймворком, но может плохо понимать язык, который лежит в основе этого фреймворка и, как следствие, может допускать ошибки, которые приводят к проблемам в продакшене.
Сама суть фреймворка заключается в том, что он имеет некоторое поведение, логику, алгоритмы, скрытые от разработчика. Мы полагаемся на квалификацию разработчиков фреймвока и верим, что они плохого не сделают. В подавляющем большинстве случаев это так и есть, но чтобы эффективно работать с фреймворком нужно быть очень квалифицированным и четко понимать как фреймворк работает, какие у него сильные и слабые стороны, что делать можно, а что не стоит.
Неочевидная проблема тут вот в чем. Любой разработчик фреймворка позиционирует его как лучшую альтернативу для более "легкого", "быстрого" и "безопасного" написания кода, создания приложений и т.д. и т.п. Как правило никто не говорит, что все это требует еще и изучения фреймворка, затрат времени на получение опыта и набиваение шишек.
Выглядит все красиво - мне не надо ничего знать, за меня уже все придумали и обо всем позаботились.
На практике это отлично работает для стандартных случаев (именно для них и пишутся фреймворки), для простых и типовых приложений, у которых нет особой нагрузки.
В реальной жизни приложения никогда не упрощаются. Создав однажды прототип приложения и опубликовав его даже в локальной сети Вы можете быть уверены что дальше приложение будет только усложняться и утяжеляться. И очень часто наступает момент, когда "легкий" старт с определенным фреймворком оборачивается огромными проблемами.
Когда "вдруг" приложение, на написание которого потрачены тысячи человекочасов, начинает жутко тормозить под нагрузкой. Когда "вдруг" осознаешь, что переехать на другой, более подходящий фреймворк, сложнее чем переписать приложение с нуля. Когда "неожиданно" понимаешь, что прикрутить SEO оптимизацию, которую требуют маркетологи и аналитики, к существующему приложению невозможно.
Все это усугубляется тем, что внутренняя (core) логика работы фреймворка может конфликтовать с бизнес логикой.
В этот момент в ход идут костыли, которые работают по принципу "решаем одну проблему - добавляем две новых".
Тут мы с Вами будем рассматривать различные примеры, как можно пользоваться обычным JavaScript для решения типовых задач. Любой JS разработчик, должен уметь решать эти задачи на "фреймворке" VanillaJS и только после этого можно переходить к использованию для решения той же самой проблемы с помощью фреймворка.
Drag-n-Drop элементов DOM на VanillaJS
Сериал "SPA приложение на VanillaJS"
https://www.youtube.com/watch?v=eqAefmCqA6M&list=PLCh6bwt6jth_fkFrU15eyY6Hv18NuWcwa
Эффект падающего снега
https://youtu.be/3xk4ldXe4YI - часть 1 https://youtu.be/S4CagEvz4WE - часть 2
Библиотека Redux и простой JS:
Самый правильный способ установки node и npm, настоятельно рекомендую устанавливать только так, это спасет Вас от лишних проблем в будущем.
Как настроить сборку проекта с помощью webpack
Как настроить горячую перезагрузку (hot reloading) с помощью webpack