Я не так давно делился мнением по поводу высказывания Тимура Шемсединова о том, что фронтенд фреймворки не нужны и это инерция. Я неоднократно видел, что подход разработки с использованием встроенных Web API вполне возможен.
Тимур поделился репозиторием с proof of concept своей мысли. Это приложение редактирования профиля: простой сервер с роутером на чистом Node.js и фронтенд в SPA-стиле на ES-модулях, веб-компонентах c Shadow DOM и шаблонами.
Приложение позволяет смотреть, искать, создавать, изменять и удалять профили экспертов с валидацией данных на клиенте и сервере, вычисляемыми полями и общей выделенной доменной логикой для клиента и сервера, не простой CRUD.
Особенность проекта в том, что он целиком построен на чистом Node.js и браузерных API и не использует рантайм-зависимости, фреймворки и сборщики. Это пример ровно того подхода, о котором говорил Тимур. Ограничения прописаны в репозитории:
- Запросы данных напрямую из компонентов запрещены;
- Только встроенные API;
- Никаких рантайм-зависимостей из npm, dev-зависимости допустимы, но опциональны (проект использует ESLint и Prettier);
- Чистый Node.js для серверной части;
- Стандартные ES-модули на клиенте;
- Веб-компоненты, Template API и Navigation API на клиенте;
-
<template> для фрагментов UI и веб-компонентов с Shadow DOM, где уместно.В репозитории проекта есть подробный README с описанием архитектуры сервера и клиента, выделенной доменной логики, валидации, роутинга, декларативного рендеринга, шаблонов, сборки страниц, API, хранилища, пользовательских сценариев.
Я изучил код. Мне всё понятно, код аккуратный и лаконичный, есть чёткая структура, понятно, где что находится и как это расширять. И нет никаких монструозных абстракций, которых все боятся, когда речь о разработке на чистом Web API.
Да, это не похоже на общепринятый «индустриальный стандарт». Тут нет декларативных шаблонов с реактивностью, сложного клиентского состояния, а само приложение ориентировано на сервер.
Зато ноль зависимостей, не нужно думать о tree shaking, смотреть bundle analyzer, искать дубликаты, регулярно обновляться, следить за релизами и уязвимостями, слать issue и ждать релиз с исправлением бага, бороться с ограничениями, конфигурировать сборку.
Весь код полностью доступен, его можно доработать под потребности, он решает только проектные задачи, лишнее можно удалить, чтобы не висело мёртвым грузом, недостающие абстракции можно дописать, с LLM это довольно быстро.
Многие команды застревают в поддержке. Проект работает на старых версиях, уходят месяцы на обновления и оптимизацию бандлов, выделяются отдельные специалисты или инфраструктурные команды (кто-то называет их FrontOps).
Я вижу тут компромисс и trade off: DX, некоторые удобства, синтаксический сахар и «индустриальный стандарт» меняется на простоту поддержки, устойчивость, долговечность и полное владение кодовой базой.
Снижается паразитная сложность, система становится менее громоздкой, упрощается деплой и поддержка. Сложность становится контролируемой. Но это требует опыта, дисциплины, хорошего знания стандартов и Web API.
В процессе возникает «фреймворк», хотя это набор специфичных для проекта решений, что лично я бы фреймворком не назвал. Пусть будет «свой велосипед». React тоже был «своим велосипедом» для решения проблем команды Facebook.
Возможно, я предвзят, потому что сам предпочитаю работать со стандартными API и не люблю лишние зависимости. В любом случае, советую посмотреть проект и заложенные там идеи. Без фреймворков писать можно и это не так страшно, сколько непривычно.
#js #web_api #architecture
