Выбор стека сужают не рейтинги, а четыре вопроса: что делает продукт, кто будет его поддерживать, где он будет работать и что уже есть у команды. Контентному сайту часто хватает статической генерации без фреймворка, веб-приложению — React с Next.js или Vue, backend пишут на Node.js, Java со Spring Boot или Python — по составу команды и задаче; данные по умолчанию — PostgreSQL, API — REST, архитектура — модульный монолит. Ниже — сводные таблицы «когда что» со ссылками на подробные разборы.
После материала вы сможете
- сузить выбор фронтенд-, backend- и мобильного стека и СУБД для своего типа проекта до 1–2 вариантов по таблицам «когда что»
- объяснить, когда сайту не нужен фреймворк и какие возможности Next.js теряет в режиме
output: 'export' - прочитать данные опроса о популярности технологий с учётом выборки и формулировки вопроса
Что знать заранее
Содержание
- Как пользоваться таблицами: критерии
- Сайт и веб-приложение: без фреймворка, React с Next.js или Vue
- Backend: Node.js, Java со Spring Boot или Python
- Мобильные: натив, React Native, Flutter или PWA
- Базы данных: PostgreSQL, MySQL, NoSQL и Redis
- API и архитектура: REST или GraphQL, монолит или микросервисы
- Хостинг и деплой
- Популярность: что говорят опросы и как их читать
Как пользоваться таблицами: критерии
Это справочник для инженерного решения: в каждой таблице — критерий и вывод «когда что». Подробные разборы с кодом и проверками вынесены в отдельные материалы, ссылки на них — в каждом разделе. Бизнес-сторону выбора — рынок специалистов, стоимость владения, свободу сменить подрядчика — разбирает статья «На чём делать продукт: выбор технологий глазами бизнеса» (vybor-tehnologij-dlya-produkta).
- Сценарий: что продукт делает — показывает контент, принимает заявки и деньги, работает офлайн, держит постоянные соединения.
- Команда: на каком языке она уже пишет и кто будет поддерживать код через два года.
- Эксплуатация: где приложение будет работать — статический хостинг, PaaS, свой сервер — и кто за это отвечает.
- Данные и интеграции: что уже есть — CMS, 1С, CRM, действующая база данных.
- Обратимость: сколько стоит передумать. Сменить СУБД или архитектуру дороже, чем библиотеку компонентов.
Сайт и веб-приложение: без фреймворка, React с Next.js или Vue
Первый вопрос — нужен ли фреймворк вообще. MDN в курсе по клиентским фреймворкам прямо предупреждает: для портфолио из нескольких страниц почти без интерактивности фреймворк и весь его JavaScript могут быть не нужны. Там же перечислены альтернативы: генераторы статических сайтов (Astro, Eleventy, Hugo), CMS вроде WordPress и серверный рендеринг.
Типичные задачи
- Без фреймворка или генератор статики
- Визитка, лендинг, документация, блог без личных кабинетов
- React + Next.js
- Веб-приложения, кабинеты, контентные сайты с серверной логикой
- Vue (+ Nuxt)
- Те же задачи: от виджета на готовой странице до SPA и SSR
Что получается на выходе
- Без фреймворка или генератор статики
- Готовые HTML-файлы, которые раздаёт любой веб-сервер или CDN
- React + Next.js
- Статический экспорт (
output: 'export') или Node.js-сервер с SSR, Server Actions и cookies - Vue (+ Nuxt)
- Скрипт на странице без сборки, SPA или SSR/SSG через Nuxt
HTML для поиска
- Без фреймворка или генератор статики
- Содержимое уже в HTML
- React + Next.js
- SSR и SSG отдают готовый HTML; чисто клиентское SPA — нет
- Vue (+ Nuxt)
- Так же: SSR или SSG дают HTML, клиентское SPA — нет
Код на сервере
- Без фреймворка или генератор статики
- Нет: меньше точек для атаки
- React + Next.js
- Зависит от режима: при SSR на сервере выполняется ваш код
- Vue (+ Nuxt)
- Зависит от режима, как у Next.js
Что нужно знать команде
- Без фреймворка или генератор статики
- HTML, CSS, немного JavaScript и инструмент сборки
- React + Next.js
- React, TypeScript, соглашения Next.js: маршруты-папки, серверные и клиентские компоненты
- Vue (+ Nuxt)
- Шаблоны Vue,
refиcomputed, для SSR — соглашения Nuxt
React сам рекомендует начинать новое приложение с фреймворка — Next.js, React Router или Expo для нативных приложений; сборка «с нуля» на Vite — для особых ограничений или чтобы изучить основы. Vue называет себя прогрессивным фреймворком: его можно подключить к готовой HTML-странице без сборки и дорастить до SPA или серверного рендеринга. Next.js тоже умеет быть статическим сайтом: в режиме output: 'export' он собирает HTML на этапе next build, но теряет всё, что требует сервера, — cookies, Server Actions, rewrites и redirects, ISR.
Визитка, лендинг, документация; контент правит разработчик
- Выбор
- Статический HTML или генератор статики
- Почему
- Нет серверного кода, хостинг на любом статическом сервере или CDN
Контент регулярно правят маркетологи
- Выбор
- CMS (WordPress) или headless CMS вместе с Next.js или Nuxt
- Почему
- По MDN, CMS удобна, когда контент пишут люди без навыков кода; цена — меньше контроля над результатом
Личный кабинет, админка, приложение с формами и ролями
- Выбор
- React + Next.js или Vue + Nuxt — тот, что знает команда
- Почему
- Компоненты, маршрутизация и серверная часть в одном проекте
Планируется мобильное приложение на React Native
- Выбор
- React + Next.js
- Почему
- Общие TypeScript и модель компонентов; сам код интерфейса всё равно разный
Нужно оживить часть готовой страницы: калькулятор, фильтр
- Выбор
- Vue без сборки или небольшой скрипт
- Почему
- Не нужно переписывать сайт ради одного виджета
Backend: Node.js, Java со Spring Boot или Python
Все три экосистемы закрывают типичные задачи backend: HTTP API, работу с базой, авторизацию, фоновые задачи. Различаются язык, объём «встроенного» и то, сколько структуры фреймворк задаёт сам.
Язык
- Node.js: Express / NestJS
- JavaScript или TypeScript — тот же, что на фронтенде
- Java: Spring Boot
- Java (или Kotlin), статическая типизация
- Python: FastAPI / Django
- Python; подсказки типов FastAPI использует для валидации
Сколько структуры задаёт фреймворк
- Node.js: Express / NestJS
- Express — минимальный и без навязанной структуры; NestJS — модули, контроллеры, сервисы и внедрение зависимостей
- Java: Spring Boot
- Много: стартеры, автоконфигурация, слои контроллер — сервис — репозиторий
- Python: FastAPI / Django
- FastAPI — маршруты, валидация и
Depends, остальное выбираете сами; Django — максимум в комплекте
Что в комплекте
- Node.js: Express / NestJS
- Express — маршруты и middleware; ORM, валидацию и документацию API подключают отдельно
- Java: Spring Boot
- Встроенный сервер, метрики и health checks, внешняя конфигурация; данные — через Spring Data
- Python: FastAPI / Django
- FastAPI — OpenAPI и документация на
/docs, без ORM и админки; Django — ORM, миграции, админка, аутентификация, защита от CSRF
Сильная сторона
- Node.js: Express / NestJS
- Один язык на всём стеке, общие типы с фронтендом
- Java: Spring Boot
- Предсказуемая структура для больших и долгоживущих систем, готовые инструменты эксплуатации
- Python: FastAPI / Django
- FastAPI — быстрый старт API с контрактом из типов; Django — сайты и внутренние системы с админкой
Цена
- Node.js: Express / NestJS
- В Express архитектуру держит команда; в NestJS нужно освоить декораторы и DI
- Java: Spring Boot
- Для маленького сервиса — больше понятий и конфигурации на старте, чем нужно
- Python: FastAPI / Django
- FastAPI требует собрать стек самому, Django — работать по его соглашениям
Команда пишет фронтенд на TypeScript, нужен API для своих веб- и мобильного клиентов
- Выбор
- Node.js: NestJS для структуры, Express для небольшого сервиса
- Почему
- Один язык и общие типы на всём стеке
Большая система с долгим сроком жизни, в компании есть Java-экспертиза
- Выбор
- Spring Boot
- Почему
- Строгая структура и production-ready возможности из коробки
Внутренняя система с множеством справочников и редакторов данных
- Выбор
- Django
- Почему
- Админка, ORM и миграции готовы сразу
API рядом с Python-кодом: анализ данных, ML, скрипты
- Выбор
- FastAPI
- Почему
- Один язык с остальным кодом, документация API из типов
Небольшой сервис, вебхук, интеграционный адаптер
- Выбор
- Express или FastAPI
- Почему
- Минимум кода и зависимостей
Уроки по каждому стеку: «Что такое backend» (chto-takoe-backend), «REST API на Express» (express-rest-api), «NestJS: модули, контроллеры, сервисы и DTO» (nestjs-vvedenie), «Spring Boot: REST API с нуля» (spring-boot-rest-api), «FastAPI: API на Python» (python-fastapi), «Django: модели, админка и представления» (django-vvedenie).
Мобильные: натив, React Native, Flutter или PWA
Подробное сравнение с примерами и деревом решений — в материале «Мобильная разработка: нативно, React Native или Flutter» (mobilnaya-razrabotka-osnovy). Здесь — выжимка для первого фильтра.
PWA
- Когда выбирать
- Сценарий укладывается в возможности браузера, публикация в сторе не обязательна
- Что учесть
- Один код с сайтом; доступ к API устройства и работа в фоне зависят от поддержки браузера на конкретной платформе
Нативно: Kotlin + Compose, Swift + SwiftUI
- Когда выбирать
- Нужны новые API системы сразу после выхода, интерфейс строго по правилам платформы
- Что учесть
- Два приложения и два языка: каждую функцию делают дважды
React Native + Expo
- Когда выбирать
- Команда знает React и TypeScript, нужен один код для Android и iOS
- Что учесть
- Нет DOM и CSS-каскада; нативные знания для сборки и подписи всё равно нужны
Flutter
- Когда выбирать
- Нужен одинаковый фирменный интерфейс на всех платформах, команда готова к Dart
- Что учесть
- Собственная отрисовка: системное поведение элементов приходится повторять
Базы данных: PostgreSQL, MySQL, NoSQL и Redis
PostgreSQL
- Когда что
- По умолчанию для нового продукта: строгие типы, транзакционные миграции,
jsonb, расширения PostGIS и pgvector - Подробно
postgresql-ili-mysql
MySQL
- Когда что
- Его требует платформа (например, WordPress) или он уже есть у команды и хостинга вместе с опытом и мониторингом
- Подробно
postgresql-ili-mysql
jsonb в PostgreSQL
- Когда что
- Почти всё реляционное, а гибкой должна быть только часть — например, характеристики товаров
- Подробно
nosql-kogda-nuzhen
Документная база (MongoDB)
- Когда что
- Объект читают и меняют целиком, связей мало: контент, анкеты, настройки
- Подробно
nosql-kogda-nuzhen
Redis
- Когда что
- Рядом с основной базой: кэш, сессии, счётчики, лимиты запросов
- Подробно
redis-keshirovanie
Широкие строки и графы (Cassandra, Neo4j)
- Когда что
- Очень большой поток записи на многих серверах или обход связей произвольной глубины
- Подробно
nosql-kogda-nuzhen
API и архитектура: REST или GraphQL, монолит или микросервисы
Публичный API, вебхуки, обмен с 1С и CRM, файлы
- Стиль API
- REST
- Почему
- Понятен любому HTTP-клиенту, кэшируется по адресам, ошибки видны по статусам
Несколько клиентов с разными экранами над связанными данными
- Стиль API
- GraphQL
- Почему
- Каждый клиент берёт свои поля за один запрос; цена — лимиты глубины и стоимости на сервере
Связь внутренних сервисов, потоки, низкие задержки
- Стиль API
- gRPC
- Почему
- Двоичный формат, генерация кода, потоковые вызовы
Full-stack TypeScript, одна команда, один репозиторий
- Стиль API
- tRPC
- Почему
- Типы клиента выводятся из сервера без схемы
Новый продукт, границы предметной области ещё сдвигаются
- Архитектура
- Модульный монолит
- Почему
- Одно развёртывание, транзакции между модулями, границы проверяются автоматически
Несколько команд мешают друг другу при релизах
- Архитектура
- Жёсткие границы модулей, затем выделение по одному сервису
- Почему
- Сначала убедиться, что мешает именно развёртывание, а не связность кода
Части системы нужны другая нагрузка, доступность или защита
- Архитектура
- Выделить эту часть в сервис
- Почему
- Разделение по характеристикам — технический довод за сервис
Нет автодеплоя, мониторинга и трассировки
- Архитектура
- Не начинать микросервисы
- Почему
- Цена распределённости превысит выгоду
Разбор стилей API с кэшированием, ошибками и безопасностью — «REST или GraphQL» (rest-ili-graphql), практика — «GraphQL: схема, запросы и мутации» (graphql-osnovy). Обоснование и пример модульного монолита в коде — «Модульный монолит или микросервисы» (modulnyj-monolit-ili-mikroservisy).
Хостинг и деплой
Статический хостинг или CDN
- Когда уместна
- Сайт без серверного кода: генератор статики или статический экспорт Next.js
- Что остаётся на команде
- Сборка, домен, правила кэширования
PaaS: Vercel, Render, Fly.io
- Когда уместна
- Небольшая команда, стандартный стек, нужны превью-окружения для веток
- Что остаётся на команде
- Код, переменные окружения, миграции, укладывание в рамки платформы
VPS
- Когда уместна
- Нужен полный контроль, нестандартный софт, долгие процессы или данные в конкретной стране
- Что остаётся на команде
- ОС и обновления, firewall, Nginx и HTTPS, бэкапы, мониторинг, сценарий выкатки
Контейнеры и Kubernetes
- Когда уместна
- Много сервисов и экземпляров, есть инженер, который отвечает за платформу
- Что остаётся на команде
- Кластер или управляемый сервис, манифесты, сеть, наблюдаемость
Популярность: что говорят опросы и как их читать
Распространённость технологии — довод про рынок специалистов, а не про качество. Единственный источник цифр в этом справочнике — Stack Overflow Developer Survey 2026: 30 903 ответа из 169 стран. Вопрос звучит как «в каких технологиях вы вели основательную разработку за последний год»; можно выбрать несколько вариантов, поэтому сумма долей больше 100%.
Node.js
- Доля ответивших
- 46,4%
- Раздел опроса
- Веб-фреймворки и технологии (n = 10 281)
React
- Доля ответивших
- 41,5%
- Раздел опроса
- Веб-фреймворки и технологии (n = 10 281)
Next.js
- Доля ответивших
- 20,6%
- Раздел опроса
- Веб-фреймворки и технологии (n = 10 281)
FastAPI
- Доля ответивших
- 18,5%
- Раздел опроса
- Веб-фреймворки и технологии (n = 10 281)
Vue.js
- Доля ответивших
- 17,2%
- Раздел опроса
- Веб-фреймворки и технологии (n = 10 281)
Express
- Доля ответивших
- 15,6%
- Раздел опроса
- Веб-фреймворки и технологии (n = 10 281)
Spring Boot
- Доля ответивших
- 12,8%
- Раздел опроса
- Веб-фреймворки и технологии (n = 10 281)
Django
- Доля ответивших
- 11,3%
- Раздел опроса
- Веб-фреймворки и технологии (n = 10 281)
NestJS
- Доля ответивших
- 5,8%
- Раздел опроса
- Веб-фреймворки и технологии (n = 10 281)
PostgreSQL
- Доля ответивших
- 57,9%
- Раздел опроса
- Базы данных (n = 12 061)
MySQL
- Доля ответивших
- 35,1%
- Раздел опроса
- Базы данных (n = 12 061)
Redis
- Доля ответивших
- 28,3%
- Раздел опроса
- Базы данных (n = 12 061)
MongoDB
- Доля ответивших
- 19,0%
- Раздел опроса
- Базы данных (n = 12 061)
- Выборка — аудитория Stack Overflow, которая прошла опрос, а не все разработчики и не рынок конкретного города.
- Опрос измеряет использование, а не пригодность: технология с меньшей долей может быть лучшим выбором для вашего сценария.
- React Native и Flutter в списке вариантов этих вопросов нет — для мобильных опирайтесь на критерии из раздела выше.
- Для найма смотрите вакансии и резюме в своём регионе — так советует и бизнес-статья о выборе технологий.
