Популярные frontend-фреймворки
Для чего модуль
Научиться выбирать стек по продуктовым ограничениям и рискам, а не по личным предпочтениям команды.
Результат после прохождения
- Вы сравниваете React/Vue/Angular/Svelte по измеримым критериям.
- Вы учитываете стоимость внедрения, найма, поддержки и миграции.
- Вы умеете защищать выбор стека на архитектурном интервью.
- Вы понимаете, когда смена фреймворка — решение, а когда дорогое отвлечение.
Термины и аббревиатуры
| Термин | Коротко |
|---|---|
DX | Developer Experience |
NFR | Нефункциональные требования |
Governance | Правила техрешений |
Lock-in | Сильная зависимость от стека |
Migration | План перехода |
Фокус по грейдам
Junior: понимать базовые механики и объяснять их простыми примерами.Middle: применять тему в продуктовых сценариях с учетом рисков и ограничений.Senior: управлять архитектурными trade-offs, метриками и эволюцией решения.
Как работать с модулем
- Берите один продуктовый кейс и прогоняйте его через decision matrix.
- Для каждого критерия ставьте вес и объясняйте, почему он важен именно для вашего контекста.
- Фиксируйте не только плюсы выбранного стека, но и «цену решения».
Программа модуля
Урок 1. Модели фреймворков
Цель: понимать концептуальные различия, которые влияют на архитектуру и DX.
Концептуальные оси сравнения
- Rendering model и реактивность.
- Архитектурные ограничения и conventions.
- Экосистема и интеграция с tooling.
Простой ориентир
- React — гибкость и большая экосистема, но больше архитектурных решений на команде.
- Vue — мягкий порог входа и удобный DX, хороший баланс для небольших/средних команд.
- Angular — строгая структура и enterprise-процессы, но выше входной порог.
- Svelte — минимальный runtime overhead и простой синтаксис, но меньше зрелых enterprise-паттернов.
Где ломается в проде
- Берут «самый популярный» стек без учета компетенций команды.
- Игнорируют governance и lifecycle библиотек.
- Сравнивают фреймворки по pet-проектам, а не по реальным NFR.
Мини-задача (обязательная)
Сравните 3 фреймворка для одного продукта по 7 критериям: team skill, скорость старта, долгосрочная поддержка, perf, hiring, ecosystem risk, migration cost.
Что спросит интервьюер: почему ваш текущий стек лучше альтернатив именно для вашего продукта.
Критерий готовности по уроку: вы можете сравнить фреймворки через модель критериев, а не через общие лозунги.
Урок 2. Экосистема и DX
Цель: оценивать не только сам фреймворк, но и «операционную систему» вокруг него.
Что входит в ecosystem cost
- Router/state/forms/testing решения.
- Quality tooling (lint, typecheck, test infra, docs).
- Стабильность апгрейдов и backward compatibility.
DX и скорость команды
- Время onboarding нового разработчика.
- Количество «обязательных решений» на старте.
- Прозрачность debugging и профилирования.
Где ломается в проде
- Слишком «свободный» стек без внутренних стандартов.
- Зависимость от niche библиотек без долгосрочной поддержки.
- Частые breaking upgrades без плана миграции.
Мини-задача (обязательная)
Подготовьте ecosystem map выбранного стека: обязательные и optional инструменты, ownership, план обновлений.
Что спросит интервьюер: как экосистема выбранного фреймворка влияет на скорость и качество поставки.
Критерий готовности по уроку: вы можете показать, как tooling+ecosystem влияют на TTM и надежность релизов.
Урок 3. Выбор под продукт
Цель: принимать решение о стеке как продуктовый trade-off.
Decision framework
- Контекст: stage продукта, домен, SLA/SLO, горизонт изменений.
- Ограничения: команда, найм, бюджет, сроки.
- Критерии: UX/perf, maintainability, delivery risk.
- Альтернативы и почему они отклонены.
Когда migration имеет смысл
- Текущий стек мешает ключевым бизнес-целям.
- Есть ясный план по рискам и постепенному переходу.
- Ожидаемая выгода измерима и достигается в реалистичный срок.
Где ломается в проде
- Migration запускают без бизнес-кейса и ownership.
- Нет стратегии coexistence старого и нового стека.
- Миграция «съедает» delivery на кварталы.
Мини-задача (обязательная)
Сделайте decision memo: выбор стека для нового продукта + план mitigations по 5 главным рискам.
Что спросит интервьюер: когда смена фреймворка оправдана, а когда это вредный «rewrite impulse».
Критерий готовности по уроку: вы можете защитить выбор стека перед CTO/архитектором через бизнес-метрики и риски.
Урок 4. Миграции и риски
Цель: проводить миграцию управляемо, без потери качества и темпа поставки.
Стратегии миграции
- Strangler pattern (постепенная замена зон).
- Coexistence layers (bridge adapters, design system shared layer).
- Incremental rollout по доменам/маршрутам.
Риски и контроль
- Технический риск: регрессии, perf, интеграции.
- Командный риск: обучение, ревью, ownership.
- Продуктовый риск: задержка фич, нестабильные релизы.
Что должно быть до старта
- Migration roadmap на этапы.
- Quality gates и rollback критерии.
- Измеримые checkpoints (velocity, defect rate, CWV и т.д.).
Мини-задача (обязательная)
Подготовьте migration risk register: 10 рисков, вероятность/влияние, mitigation, owner, trigger for escalation.
Что спросит интервьюер: как вы будете мигрировать без остановки разработки продукта.
Критерий готовности по уроку: вы можете описать миграцию как программу изменений с контролем рисков и метрик успеха.
Практика
- Подготовьте decision matrix для 2 продуктовых сценариев (startup и enterprise).
- Сделайте короткую defense-презентацию выбора стека (5-7 минут).
- Составьте migration risk register и phased rollout plan.
- Пройдите Популярные frontend-фреймворки вопросы.
- Проверьте гипотезы и прототипы в Песочнице.
Связь с треками и вопросами
- Треки: Middle трек, Senior трек.
- Вопросы: Популярные frontend-фреймворки, Senior Frontend.
- Повторение: 3-5 вопросов без подсказок -> сверка с модулем -> повтор через 24 часа.
Критерий готовности
Вы делаете выбор стека через критерии, риски и стоимость изменений, а не через личные предпочтения.
Артефакты после модуля
- Decision matrix по стеку.
- Migration risk register.
- Phased migration roadmap.
- Набор сильных формулировок для вопросов «почему этот framework».