Разработчик год строил приложение на чистом JavaScript без фреймворков, и объясняет зачем
Разработчик, публикующийся под ником Guseyn, рассказал, как весь последний год строил веб-приложение instruxmusic.com для музыкальных школ и частных преподавателей: расписание уроков, автоматический биллинг и инвойсы, видеочат с метрономом и лупой для разбора техники игры, конструктор брендированных лендингов с системой бронирования пробных уроков, дашборд со статистикой и управлением школой. По его словам, это не гигантский, но вполне полноценный по функциональности продукт, и он сделал его целиком на чистом JavaScript с использованием Web Components (нативных пользовательских HTML-элементов), не тронув ни React, ни Angular, ни Vue, ни Svelte.
Автор перечисляет, что объединяет четырёх лидеров рынка фронтенд-фреймворков (по его ощущениям, React забирает свыше 95% вакансий на LinkedIn): все требуют этапа сборки (бандлинг, минификация, транспиляция), все подталкивают к TypeScript и все, по его мнению, привносят «искусственную сложность». Ключевая мишень критики, концепция реактивности: она пришла из ранних версий Angular.js (Guseyn ссылается на выступление Миско Хевери из Google, где тот объяснял идею смены представления через изменение состояния) и была подхвачена и растиражирована React из Facebook. Автор считает, что нативный веб-стек (HTML/CSS/JS) устроен ровно наоборот тому, что предлагают фреймворки: там, где нативные технологии, это прямые обработчики событий и ручные манипуляции с DOM и глобальным состоянием, фреймворки объявляют прямую работу с DOM анти-паттерном, заставляют оборачивать обработчики в конструкции вроде useEffect и изолируют состояние на уровне компонентов, требуя сторонних библиотек управления состоянием. Он сатирически резюмирует правила фреймворков в духе «нет, вы не можете трогать DOM напрямую, только мы внутри фреймворка», «нет, нельзя просто повесить обработчик на window, надо обернуть», «нет, нельзя использовать import map, нужен build-инструмент».
Главный тезис статьи: движок браузера сам по себе уже является достаточно мощной платформой, и вместо того чтобы развивать культуру хорошо структурированного кода на HTML/CSS/JS, индустрия придумала огромное количество надстроек, лишь бы не писать эти технологии напрямую. Автор приводит длинные списки: десятки шаблонизаторов для HTML (EJS, Pug, Handlebars, Mustache, Jinja2 и другие), препроцессоров для CSS (Sass, Less, Stylus, PostCSS и прочие) и языков/трансляторов поверх JavaScript (TypeScript, CoffeeScript, Babel, Elm, Dart, Flow и другие), и заключает, что если раньше часть этих технологий имела смысл, сейчас, по его мнению, это не так.
На стандартный контраргумент, «у ванильного JS нет структуры, он не масштабируется», автор отвечает, что структура пропала именно потому, что индустрия 20 лет уходила от решения реальных проблем через изобретение новых абстракций, языков и инструментов. Он признаёт, что сам решил эту задачу тем же способом, написал собственные инструменты: EHTML, превращающий обычный HTML в язык шаблонов без виртуального DOM и сборочного конвейера (активирует HTML один раз и затем реагирует только на реальные вставки в DOM, полностью совместим со стандартом Web Components), и e-ui, библиотеку готовых интерактивных компонентов (тосты, тултипы, диалоги, загрузчики файлов, чипы, типографика, доступность) поверх EHTML. По утверждению автора, эти инструменты решают конкретные нативные ограничения, отсутствие нормального шаблонизирования и API у HTML, отсутствие поддержки JSON и вложенных структур в формах, медленную навигацию многостраничных приложений (решена HTML-кэшированием, из-за чего multi-page-приложение ощущается как single-page), сложность организации JS-кода (решена через import maps), без введения новых языков, сборочных шагов и препроцессоров. По его словам, такой подход хорошо масштабируется на практике: большая часть кода, это HTML, плюс набор кастомных Web Components и несколько файлов утилит на JavaScript, и разработка при этом почти не требует ИИ-инструментов (и уж точно не требует больших объёмов токенов на генерацию кода).
Ключевые факты
- Разработчик Guseyn целый год строил многофункциональное веб-приложение instruxmusic.com для музыкальных школ (расписание, биллинг, видеочат с метрономом, конструктор лендингов, дашборд) целиком на чистом JavaScript и Web Components, без React/Angular/Vue/Svelte
- Главная претензия к фреймворкам, «искусственная сложность»: обязательный этап сборки, продвижение TypeScript и концепция реактивности, унаследованная от Angular.js и растиражированная React, которая запрещает прямую работу с DOM и глобальным состоянием
- Тезис автора: движок браузера сам по себе уже достаточно мощная платформа, а индустрия за 20 лет породила десятки лишних шаблонизаторов, CSS-препроцессоров и JS-трансляторов вместо развития культуры структурированного кода
- На аргумент «ванильный JS не масштабируется» автор ответил созданием собственных инструментов, EHTML (HTML как язык шаблонов без виртуального DOM) и библиотеки компонентов e-ui, решающих конкретные нативные ограничения без сборочного конвейера
- По словам автора, такой подход хорошо масштабируется на практике и почти не требует ИИ-инструментов и токенов для написания кода
Почему это важно
Материал, развёрнутый манифест против доминирующей модели фронтенд-разработки: автор на реальном годовом проекте (не игрушечном примере) показывает, что сложное веб-приложение с видео, биллингом и конструктором лендингов можно построить без React/Angular/Vue/Svelte, опираясь только на нативные Web Components. Это ставит под сомнение общепринятое допущение, что современный фронтенд обязан тянуть за собой build-пайплайн, TypeScript и реактивные фреймворки.
Кому это важно
Фронтенд-разработчикам и техлидам, которые выбирают стек для нового проекта или устали от сложности build-инструментов; независимым разработчикам и небольшим командам без выделенного DevOps-ресурса на настройку сборки; авторам и пользователям инструментов вроде Web Components, import maps, а также тем, кто следит за дискуссией о роли ИИ-кодогенерации, автор отдельно отмечает, что писать на нативных технологиях проще для ИИ-ассистентов и требует меньше токенов.
Как это применить
Ключевые практики из статьи: использовать нативные Web Components вместо компонентной модели фреймворка; import maps вместо сборщика для организации модулей; кэшировать HTML частями страницы, чтобы многостраничное приложение ощущалось как SPA; при нехватке возможностей нативного HTML (шаблонизация, работа форм с JSON, вложенные структуры), писать точечные утилиты под конкретную проблему, а не подключать готовый фреймворк целиком. Инструменты автора (EHTML, e-ui) выложены в открытом доступе как готовые к использованию решения этих проблем.
Можно ли доверять
Это личный опыт и мнение одного разработчика, а не независимое исследование или сравнительный бенчмарк, цифры (например, «React занимает свыше 95% вакансий») сам автор называет субъективным ощущением, а не статистикой. Проект instruxmusic.com реален и упомянут с демо-видео, что подтверждает практическую применимость подхода, но выводы о масштабируемости и продуктивности основаны на опыте одного человека на одном продукте, а не на данных команд с этим стеком.
Риски и подводные камни
Обсуждение на Hacker News указывает на слабое место: фреймворки решают не только техническую, но и организационную проблему, дают команде из нескольких разработчиков общий согласованный способ работы с состоянием и структурой, и именно это, а не техническое превосходство, оправдывает их использование в командах. Также отмечена ирония: сам автор, критикуя фреймворки, в итоге написал собственный фреймворк (EHTML) и библиотеку компонентов (e-ui), то есть решил проблему тем же способом, который критикует, просто под своим брендом. Подход рискован для проектов с большой командой, высокой текучкой или без строгой внутренней дисциплины по структуре кода.
«Браузерный движок, это огромный и сложный программный комплекс, который берёт на себя так много работы, что всё, что вам действительно нужно, это писать динамические файлы на HTML, CSS и JavaScript, а движок браузера сам всё склеит.»
— Guseyn, автор блога и создатель instruxmusic.com