Популярные frontend-фреймворки

Для чего модуль

Научиться выбирать стек по продуктовым ограничениям и рискам, а не по личным предпочтениям команды.

Результат после прохождения

1. Вы сравниваете React/Vue/Angular/Svelte по измеримым критериям.
2. Вы учитываете стоимость внедрения, найма, поддержки и миграции.
3. Вы умеете защищать выбор стека на архитектурном интервью.
4. Вы понимаете, когда смена фреймворка — решение, а когда дорогое отвлечение.

Термины и аббревиатуры

Термин	Коротко
DX	Developer Experience
NFR	Нефункциональные требования
Governance	Правила техрешений
Lock-in	Сильная зависимость от стека
Migration	План перехода

Фокус по грейдам

1. Junior: понимать базовые механики и объяснять их простыми примерами.
2. Middle: применять тему в продуктовых сценариях с учетом рисков и ограничений.
3. Senior: управлять архитектурными trade-offs, метриками и эволюцией решения.

Как работать с модулем

1. Берите один продуктовый кейс и прогоняйте его через decision matrix.
2. Для каждого критерия ставьте вес и объясняйте, почему он важен именно для вашего контекста.
3. Фиксируйте не только плюсы выбранного стека, но и «цену решения».

Программа модуля

Урок 1. Модели фреймворков

Цель: понимать концептуальные различия, которые влияют на архитектуру и DX.

Концептуальные оси сравнения

1. Rendering model и реактивность.
2. Архитектурные ограничения и conventions.
3. Экосистема и интеграция с tooling.

Простой ориентир

1. React — гибкость и большая экосистема, но больше архитектурных решений на команде.
2. Vue — мягкий порог входа и удобный DX, хороший баланс для небольших/средних команд.
3. Angular — строгая структура и enterprise-процессы, но выше входной порог.
4. Svelte — минимальный runtime overhead и простой синтаксис, но меньше зрелых enterprise-паттернов.

Где ломается в проде

1. Берут «самый популярный» стек без учета компетенций команды.
2. Игнорируют governance и lifecycle библиотек.
3. Сравнивают фреймворки по pet-проектам, а не по реальным NFR.

Мини-задача (обязательная)

Сравните 3 фреймворка для одного продукта по 7 критериям: team skill, скорость старта, долгосрочная поддержка, perf, hiring, ecosystem risk, migration cost.

Что спросит интервьюер: почему ваш текущий стек лучше альтернатив именно для вашего продукта.

Критерий готовности по уроку: вы можете сравнить фреймворки через модель критериев, а не через общие лозунги.

Урок 2. Экосистема и DX

Цель: оценивать не только сам фреймворк, но и «операционную систему» вокруг него.

Что входит в ecosystem cost

1. Router/state/forms/testing решения.
2. Quality tooling (lint, typecheck, test infra, docs).
3. Стабильность апгрейдов и backward compatibility.

DX и скорость команды

1. Время onboarding нового разработчика.
2. Количество «обязательных решений» на старте.
3. Прозрачность debugging и профилирования.

Где ломается в проде

1. Слишком «свободный» стек без внутренних стандартов.
2. Зависимость от niche библиотек без долгосрочной поддержки.
3. Частые breaking upgrades без плана миграции.

Мини-задача (обязательная)

Подготовьте ecosystem map выбранного стека: обязательные и optional инструменты, ownership, план обновлений.

Что спросит интервьюер: как экосистема выбранного фреймворка влияет на скорость и качество поставки.

Критерий готовности по уроку: вы можете показать, как tooling+ecosystem влияют на TTM и надежность релизов.

Урок 3. Выбор под продукт

Цель: принимать решение о стеке как продуктовый trade-off.

Decision framework

1. Контекст: stage продукта, домен, SLA/SLO, горизонт изменений.
2. Ограничения: команда, найм, бюджет, сроки.
3. Критерии: UX/perf, maintainability, delivery risk.
4. Альтернативы и почему они отклонены.

Когда migration имеет смысл

1. Текущий стек мешает ключевым бизнес-целям.
2. Есть ясный план по рискам и постепенному переходу.
3. Ожидаемая выгода измерима и достигается в реалистичный срок.

Где ломается в проде

1. Migration запускают без бизнес-кейса и ownership.
2. Нет стратегии coexistence старого и нового стека.
3. Миграция «съедает» delivery на кварталы.

Мини-задача (обязательная)

Сделайте decision memo: выбор стека для нового продукта + план mitigations по 5 главным рискам.

Что спросит интервьюер: когда смена фреймворка оправдана, а когда это вредный «rewrite impulse».

Критерий готовности по уроку: вы можете защитить выбор стека перед CTO/архитектором через бизнес-метрики и риски.

Урок 4. Миграции и риски

Цель: проводить миграцию управляемо, без потери качества и темпа поставки.

Стратегии миграции

1. Strangler pattern (постепенная замена зон).
2. Coexistence layers (bridge adapters, design system shared layer).
3. Incremental rollout по доменам/маршрутам.

Риски и контроль

1. Технический риск: регрессии, perf, интеграции.
2. Командный риск: обучение, ревью, ownership.
3. Продуктовый риск: задержка фич, нестабильные релизы.

Что должно быть до старта

1. Migration roadmap на этапы.
2. Quality gates и rollback критерии.
3. Измеримые checkpoints (velocity, defect rate, CWV и т.д.).

Мини-задача (обязательная)

Подготовьте migration risk register: 10 рисков, вероятность/влияние, mitigation, owner, trigger for escalation.

Что спросит интервьюер: как вы будете мигрировать без остановки разработки продукта.

Критерий готовности по уроку: вы можете описать миграцию как программу изменений с контролем рисков и метрик успеха.

Практика

Работайте через 4 проверяемых decision-блока. Цель не в том, чтобы "выбрать любимый framework", а в том, чтобы доказать fit через контекст, риски и стоимость изменений.

Блок	Ответить	Practice action	Readiness
Architecture model	Frontend Frameworks q-1..q-5	Framework model map: React/Vue/Angular по rendering model, reactivity, DI/composition, conventions, ownership decisions	Вы сравниваете архитектурные модели без лозунгов и называете, где каждая модель ломается в production
Runtime and ecosystem trade-off	q-6..q-10, q-16	Ecosystem/DX scorecard: routing, state, forms, testing, upgrades, debugging, team standards, release risk	Вы объясняете, как tooling и ecosystem влияют на onboarding, delivery speed, quality gates и long-term support
Product decision	q-11..q-12, q-17..q-20	Decision memo для startup и enterprise: context, weighted criteria, alternatives, chosen stack, why-not options, success metric	Вы защищаете выбор через product constraints, performance budget, hiring/onboarding и "why not React" без вкусовщины
Migration and lock-in	q-13..q-15, q-19	Migration risk register + phased rollout: coexistence layer, owners, quality gates, rollback, escalation triggers	Вы описываете migration как программу изменений, а не rewrite impulse, и показываете lock-in mitigation

Если блок получает partial или not ready, не переходите к следующему learning-модулю: перепишите artifact до состояния context -> criteria -> alternatives -> decision -> risks -> validation.

Связь с треками и вопросами

1. Треки: Middle трек, Senior трек.
2. Вопросы: Frontend Frameworks q-1..q-20, Senior q-1, Senior q-2, Senior q-12.
3. Route practice: Middle день 13, Senior день 1-2, Мосты практики: Tooling and bundle quality для ecosystem/DX evidence, плюс строка React state and performance для framework trade-off discussion.
4. Повторение через 24 часа: один вопрос про architecture model, один про ecosystem/DX, один про product fit, один про migration risk.

Критерий готовности

Ready, если вы делаете выбор стека через критерии, риски и стоимость изменений:

1. decision matrix имеет weighted criteria и объясняет, почему веса важны именно для продукта;
2. у выбранного framework есть не только плюсы, но и explicit cost: hiring, onboarding, ecosystem, migration, performance budget;
3. alternatives отклонены по проверяемым причинам, а не по личному вкусу;
4. migration plan содержит coexistence strategy, quality gates, owners, rollout и rollback;
5. ответ "почему не React/Vue/Angular/Svelte" звучит как engineering decision, а не защита любимого инструмента.

Partial, если сравнение есть, но без weights, validation или owner/risk plan. Not ready, если ответ строится на популярности, личном опыте или "так быстрее", без product constraints и проверки.

Артефакты после модуля

1. Decision matrix по стеку.
2. Ecosystem/DX scorecard.
3. Product decision memo для startup и enterprise.
4. Migration risk register.
5. Phased migration roadmap.
6. Набор сильных формулировок для вопросов «почему этот framework» и «почему не React».

Куда дальше

1. Frontend-архитектура
2. Инженерные принципы
3. Популярные frontend-фреймворки