Фронт развился в какую-то неправильную сторону, это правда
Вкатиться на фронт очень сложно, это тоже правда. Причём, необоснованно сложно.
Я бы выделил два пути, как можно въехать во всё это:
1. Создать приложение на Vue или React по туториалам, затем разобраться, как и зачем оно всё
2. Разобраться как и зачем оно всё (aka Vanilla JS), потом заняться реактами
Имхо, вариант №2 предпочтителен и более прост, потому что на варианте №1 есть огромный шанс застрять, никогда не разобравшись, как оно работает а при любых нешаблонных ошибках поднимать лапки.
Что здесь нужно понимать:
1. Есть разные версии ES (ecmascript), они все обратносовместимые. Программист может писать на любой версии, какая ему нравится. Обычно берут последнюю стабильную
2. Для проекта обычно есть две версии ES: та, на которой пишут программисты и та, которая исполняется в браузере или в ноде (об этом позже). Например, программист пишет на ES8, а код транслируется на ES5. Это позволяет использовать последние предсмертные хрипы писки моды JS при этом запуская всё на древнейшем говне вроде IE11. Перегонкой кода из JS/TS одной версии в JS другой версии занимается транспилятор: babel / esbuild / swc
3. Новые версии JS содержат расширения стандартной библиотеки, которых нет в старых браузерах (например Array.from, Object.entries и т.п.). Эти дырки затыкают полифиллы, они же shims. Самая популярная дырозатыкательная машинка — corejs
4. Весь код очевидно не пишется в одном файле и может быть написан на TypeScript (он же TS), JSX/TSX (реактовый синтаксис). Всё это нужно собрать в один или несколько файлов, то есть скомпоновать. Этим занимается bundler: часть webpack / esbuild / spark / etc.
5. Этот же парень отвечает за то, чтобы та тысяча библиотек, что лежит в node_modules, попала в итоговый условный main.js, но не целиком, а только то, что используется. Последнее называется tree shaking (типа навозную кучу node_modules потрясли как дерево, что упало — то не нужно)
6. (то самое "позже) Код может исполняться не только в браузере пользователя, но и на сервере без браузера вообще. Это нужно для SSR aka Server Side Rendering. SSR — это такой глобальный вонючий костыль для SEO. Дело в том, что стандартные SPA приложения содержат один DOM элемент, куда цепляется всё остальное приложение вроде реакта или вью, которое уже содержит всю вёрстку прямо в JS. Но не все поисковики согласны с таким подходом и некоторые (не будем показывать пальцем на яндекс) не умеют выполнять JS и индексируют только тот самый единственный DOM элемент, который существует на этапе отдачи страницы в браузер. Это уже потом к нему JS движком дорисовывается весь остальной сайт. Соответственно, сайт индексируется от слова "никак", а некоторым это важно. Например, когда SPA — это не админка. Для этого есть два выхода: страницы, важные для SEO, рендерить чем-то не-реактовым или сделать SSR — делать за яндекс работу на сервере (на ноде), представляя в уме, что у нас есть DOM и браузер (на самом деле нет), на выходе получать начальное состояние HTML, отдавать его клиенту (браузеру или поисковому роботу), а JS'ом её т.н. "гидрировать", иными словами — оживлять.
7. webpack отвечает за всё вот это сверху в том или ином виде. Это такой кухонный комбайн, в который вкидываешь кучу хлама в одном виде, а получаешь другую кучу хлама в другом виде.
Начать советую с parceljs, который сильно проще в освоении, чем webpack. И на написании кода максимально без библиотек.