Скрытый налог на интеграцию

Каждый разработчик знает это чувство. Вы выбрали фреймворк, ORM, библиотеку валидации, фронтенд — всё выглядит отлично в документации. А потом начинаете писать реальный код, и выясняется, что ваша библиотека валидации не понимает структуру данных, которую возвращает ORM. Серверный рендеринг вашего фреймворка конфликтует с middleware сервера. Управление сессиями ломается на edge-деплое.

Каждый инструмент по отдельности прекрасен. Стыки между ними — кошмар.

Почему так произошло

JavaScript-экосистема всегда ставила композируемость выше связности. Это не обязательно плохо — философия UNIX десятилетиями работала для консольных утилит. Но веб-приложения — это не конвейеры изолированных преобразований данных. Это клубки общих допущений: форматы запросов, границы валидации, потоки аутентификации, контексты рендеринга.

Когда в 2005 году появился Django, он сделал ставку: разработчики готовы обменять часть гибкости на целостную систему. При необходимости можно было выйти за пределы стека, но внутри всё работало как единое целое. Меньше сюрпризов.

PHP-фреймворки подхватили эту идею. Laravel, Symfony, Yii — все давали ощущение «одной согласованной системы». Было понятно, что входит в «официальную территорию», а что требует вылазки в дикую природу.

Потом JavaScript захватил сервер, и мы это потеряли.

Ловушка мета-фреймворков

Современные мета-фреймворки кое-что улучшили. Next.js, Nuxt, SvelteKit — они снова дали связный стек. Но они сделали это за счёт сужения выбора, а не расширения.

Вот что я имею в виду: Next.js отлично работает с React. Но если вам вдруг приглянулась производительность Solid или простота Svelte, вы не можете просто подменить слой представления. Вы переходите на другой мета-фреймворк с другими соглашениями, другими паттернами роутинга, другими допущениями о бэкенде. И заново решаете те же проблемы, только с другим синтаксисом.

Парадоксальная ситуация: экосистема фронтенда постоянно развивается, но переключение между подходами требует почти полного перезапуска. React-разработчики и Svelte-разработчики независимо решают одни и те же бэкенд-задачи, немного по-разному, бесконечно.

Лотерея рантаймов

И потом — фрагментация рантаймов. Node.js, Deno, Bun — все способные платформы, но большинство фреймворков по факту привязаны к конкретному. Когда фреймворк заявляет поддержку Deno, это часто означает лишь «Deno может запустить наш Node-код». Это не то же самое, что фреймворк, изначально спроектированный под нативные API и модель выполнения Deno.

Это важнее, чем кажется. Рантайм влияет на производительность, цели деплоя и модель безопасности. Привязка к фреймворку, который по-настоящему работает только на одном рантайме, ограничивает возможности по мере развития экосистемы.

Что нам реально нужно

Веб-приложения имеют естественные слои, которые не обязаны быть связаны.

Фронтенд описывает браузерный UI. Бэкенд обрабатывает запросы, данные и логику приложения. Рантаймы — это цели выполнения. Эти concerns должны варьироваться независимо.

Представьте: один роут на React, потому что нужна его экосистема компонентов. Другой роут на Svelte, потому что там критичнее производительность. Сегодня запускаете Node.js-роуты, а завтра TypeScript-роуты на Bun, когда понадобится скорость. Всё в одном приложении, с одной моделью бэкенда, одной валидацией, одними сессиями.

Это не магическое мышление. Это разделение concerns, как и должно быть в хорошем софте.

Фреймворк должен отвечать за стыки

Я не призываю к единому фреймворку на все случаи жизни. Я говорю о том, что фреймворк должен брать на себя ответственность за согласованную работу своих компонентов. При необходимости можно выйти за пределы стека — никто не поставляет идеальные решения под все сценарии. Но когда вы остаётесь внутри фреймворка, стыки — это его проблема, а не ваша.

Фреймворк, который заставляет вас самостоятельно склеивать роутинг, валидацию, доступ к данным и рендеринг — это не фреймворк. Это намёк.

Лучшие фреймворки дают вам контроль над бизнес-логикой, забирая себе всё остальное.

В NameOcean мы видели, как сложность хостинга растёт вместе с фрагментацией стека. Выбор фреймворка, который уважает разделение concerns — который позволяет менять части без переписывания всего — делает деплой, масштабирование и поддержку заметно проще.

Вопрос не в том, использовать ли фреймворк. Вопрос в том, работает ли ваш фреймворк на вас или просто добавляет ещё один слой решений, без которых можно было обойтись.

Что значило бы создать следующее приложение с инструментом, который закрывает стыки за вас? Стоит задуматься об этом до того, как вы начнёте строить каркас нового проекта.