Перейти к основному содержимому

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

Экспресс-шпаргалка 20/20​

  1. React/Vue/Angular различаются архитектурной философией, экосистемой и требованиями к инженерной дисциплине.
  2. Vue часто выигрывает у React по простоте старта и целостности официального стека.
  3. Composition API во Vue дает переиспользование логики и явные зависимости.
  4. Реактивность Vue построена на dependency tracking через proxy/refs/computed.
  5. DI в Angular обеспечивает модульность и управляемость зависимостей.
  6. Standalone components снижают boilerplate и упрощают модульную структуру Angular.
  7. RxJS в Angular нужен для сложной композиции async-потоков.
  8. Change detection определяет, какие компоненты и когда обновлять.
  9. Svelte компилирует реактивность заранее, уменьшая runtime overhead.
  10. В отличие от runtime-подхода React/Vue, Svelte переносит часть логики в compile phase.
  11. Framework для enterprise выбирают по масштабируемости, найму, зрелости tooling и долгосрочной поддержке.
  12. Для MVP обычно важнее скорость разработки, onboarding и стоимость поддержки.
  13. Миграция между framework требует поэтапной стратегии и стабильных boundary-контрактов.
  14. Стоимость смены стека включает обучение, интеграции, потери темпа и риски регрессий.
  15. Vendor lock-in проявляется в tight coupling к API/экосистеме конкретного framework.
  16. DX сравнивают по tooling, debugging, документации, тестированию и скорости команды.
  17. Выбор framework влияет на performance budget через runtime стоимость и размер бандла.
  18. Выбор стека влияет на hiring, onboarding и риск bus factor.
  19. Перенос архитектурных практик возможен, если мыслить принципами, а не API конкретной библиотеки.
  20. На вопрос «почему не React» отвечают через требования продукта и контекст команды.

1. В чем ключевая разница React, Vue и Angular по архитектуре?​

Теги: frameworks, frontend, angular, vue Сложность: Middle/Senior

Короткий ответ​

React/Vue/Angular различаются архитектурной философией, экосистемой и требованиями к инженерной дисциплине.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично при выборе стека, архитектурной стратегии и планировании найма команды.
  2. Главный риск: Выбор стека без учета команды и продукта увеличивает стоимость разработки и риск миграции.
  3. Как проверяете решение: Сравниваю baseline по DX/perf и подтверждаю решение на мини-кейсе, близком к продуктовой задаче.

Мини-пример​

import { ref, computed } from 'vue';
const count = ref(0);
const doubled = computed(() => count.value * 2);

Углубление (2-3 минуты)​

  1. Свяжите тему "В чем ключевая разница React, Vue и Angular по архитектуре?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Сравните два фреймворка по критериям продукта: DX, perf, hiring, цена миграции.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Не считают стоимость миграции и обучения команды.
  2. Сравнивают фреймворки по синтаксису, игнорируя эксплуатационные риски.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как оцените цену миграции между решениями через 6-12 месяцев?
  2. Что важнее в этом контексте: DX команды или runtime-производительность?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Сравнение стеков по NFR и стоимости владения.
  2. Риски lock-in и план миграции.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Популярные frontend-фреймворки
  2. Обучение: React
  3. Карта подготовки: Популярные frontend-фреймворки

2. Когда Vue может быть лучше React для команды?​

Теги: frameworks, frontend, vue Сложность: Middle/Senior

Короткий ответ​

Vue часто выигрывает у React по простоте старта и целостности официального стека.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично при выборе стека, архитектурной стратегии и планировании найма команды.
  2. Главный риск: Выбор стека без учета команды и продукта увеличивает стоимость разработки и риск миграции.
  3. Как проверяете решение: Фиксирую критерии выбора стека и прогоняю их на двух альтернативах вместо интуитивного выбора.

Мини-пример​

import { ref, computed } from 'vue';
const count = ref(0);
const doubled = computed(() => count.value * 2);

Углубление (2-3 минуты)​

  1. Свяжите тему "Когда Vue может быть лучше React для команды?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, как выбор стека влияет на архитектурные границы.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Выбирают стек по хайпу, а не по требованиям продукта.
  2. Сравнивают фреймворки по синтаксису, игнорируя эксплуатационные риски.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как оцените цену миграции между решениями через 6-12 месяцев?
  2. Какие NFR определяют выбор стека в этом сценарии?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Критерии, по которым команда примет решение.
  2. Сравнение стеков по NFR и стоимости владения.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Популярные frontend-фреймворки
  2. Обучение: React
  3. Карта подготовки: Популярные frontend-фреймворки

3. Что такое Composition API в Vue и зачем он нужен?​

Теги: frameworks, frontend, vue Сложность: Middle/Senior

Короткий ответ​

Composition API во Vue дает переиспользование логики и явные зависимости.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично при выборе стека, архитектурной стратегии и планировании найма команды.
  2. Главный риск: Выбор стека без учета команды и продукта увеличивает стоимость разработки и риск миграции.
  3. Как проверяете решение: Фиксирую критерии выбора стека и прогоняю их на двух альтернативах вместо интуитивного выбора.

Мини-пример​

import { ref, computed } from 'vue';
const count = ref(0);
const doubled = computed(() => count.value * 2);

Углубление (2-3 минуты)​

  1. Свяжите тему "Что такое Composition API в Vue и зачем он нужен?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Сравните два фреймворка по критериям продукта: DX, perf, hiring, цена миграции.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Выбирают стек по хайпу, а не по требованиям продукта.
  2. Сравнивают фреймворки по синтаксису, игнорируя эксплуатационные риски.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Что важнее в этом контексте: DX команды или runtime-производительность?
  2. Как оцените цену миграции между решениями через 6-12 месяцев?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Сравнение стеков по NFR и стоимости владения.
  2. Критерии, по которым команда примет решение.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Популярные frontend-фреймворки
  2. Обучение: React
  3. Карта подготовки: Популярные frontend-фреймворки

4. Как устроена реактивность во Vue?​

Теги: frameworks, frontend, vue Сложность: Middle/Senior

Короткий ответ​

Реактивность Vue построена на dependency tracking через proxy/refs/computed.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично при выборе стека, архитектурной стратегии и планировании найма команды.
  2. Главный риск: Выбор стека без учета команды и продукта увеличивает стоимость разработки и риск миграции.
  3. Как проверяете решение: Проверяю сценарий миграции с контрольными точками и метриками стоимости сопровождения.

Мини-пример​

import { ref, computed } from 'vue';
const count = ref(0);
const doubled = computed(() => count.value * 2);

Углубление (2-3 минуты)​

  1. Свяжите тему "Как устроена реактивность во Vue?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Сравните два фреймворка по критериям продукта: DX, perf, hiring, цена миграции.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Не считают стоимость миграции и обучения команды.
  2. Сравнивают фреймворки по синтаксису, игнорируя эксплуатационные риски.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Что важнее в этом контексте: DX команды или runtime-производительность?
  2. Как оцените цену миграции между решениями через 6-12 месяцев?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Сравнение стеков по NFR и стоимости владения.
  2. Критерии, по которым команда примет решение.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Популярные frontend-фреймворки
  2. Обучение: React
  3. Карта подготовки: Популярные frontend-фреймворки

5. Что такое DI в Angular и зачем он важен?​

Теги: frameworks, frontend, angular Сложность: Middle/Senior

Короткий ответ​

DI в Angular обеспечивает модульность и управляемость зависимостей.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично при выборе стека, архитектурной стратегии и планировании найма команды.
  2. Главный риск: Выбор стека без учета команды и продукта увеличивает стоимость разработки и риск миграции.
  3. Как проверяете решение: Проверяю сценарий миграции с контрольными точками и метриками стоимости сопровождения.

Мини-пример​

@Component({ standalone: true, selector: 'app-root', template: '{{title}}' })
export class AppComponent { title = 'hello'; }

Углубление (2-3 минуты)​

  1. Свяжите тему "Что такое DI в Angular и зачем он важен?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Сравните два фреймворка по критериям продукта: DX, perf, hiring, цена миграции.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Сравнивают фреймворки по синтаксису, игнорируя эксплуатационные риски.
  2. Выбирают стек по хайпу, а не по требованиям продукта.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как оцените цену миграции между решениями через 6-12 месяцев?
  2. Какие NFR определяют выбор стека в этом сценарии?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Критерии, по которым команда примет решение.
  2. Риски lock-in и план миграции.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Популярные frontend-фреймворки
  2. Обучение: React
  3. Карта подготовки: Популярные frontend-фреймворки

6. Angular standalone components: что это меняет?​

Теги: frameworks, frontend, angular Сложность: Middle/Senior

Короткий ответ​

Standalone components снижают boilerplate и упрощают модульную структуру Angular.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично при выборе стека, архитектурной стратегии и планировании найма команды.
  2. Главный риск: Выбор стека без учета команды и продукта увеличивает стоимость разработки и риск миграции.
  3. Как проверяете решение: Фиксирую критерии выбора стека и прогоняю их на двух альтернативах вместо интуитивного выбора.

Мини-пример​

@Component({ standalone: true, selector: 'app-root', template: '{{title}}' })
export class AppComponent { title = 'hello'; }

Углубление (2-3 минуты)​

  1. Свяжите тему "Angular standalone components: что это меняет?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Отделите «что удобно сейчас» от «что масштабируется через 12 месяцев».
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Сравнивают фреймворки по синтаксису, игнорируя эксплуатационные риски.
  2. Не считают стоимость миграции и обучения команды.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Что важнее в этом контексте: DX команды или runtime-производительность?
  2. Как оцените цену миграции между решениями через 6-12 месяцев?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Сравнение стеков по NFR и стоимости владения.
  2. Критерии, по которым команда примет решение.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Популярные frontend-фреймворки
  2. Обучение: React
  3. Карта подготовки: Популярные frontend-фреймворки

7. Какая роль RxJS в Angular приложениях?​

Теги: frameworks, frontend, angular Сложность: Middle/Senior

Короткий ответ​

RxJS в Angular нужен для сложной композиции async-потоков.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично при выборе стека, архитектурной стратегии и планировании найма команды.
  2. Главный риск: Выбор стека без учета команды и продукта увеличивает стоимость разработки и риск миграции.
  3. Как проверяете решение: Проверяю сценарий миграции с контрольными точками и метриками стоимости сопровождения.

Мини-пример​

@Component({ standalone: true, selector: 'app-root', template: '{{title}}' })
export class AppComponent { title = 'hello'; }

Углубление (2-3 минуты)​

  1. Свяжите тему "Какая роль RxJS в Angular приложениях?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Сравните два фреймворка по критериям продукта: DX, perf, hiring, цена миграции.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Не считают стоимость миграции и обучения команды.
  2. Сравнивают фреймворки по синтаксису, игнорируя эксплуатационные риски.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как оцените цену миграции между решениями через 6-12 месяцев?
  2. Что важнее в этом контексте: DX команды или runtime-производительность?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Сравнение стеков по NFR и стоимости владения.
  2. Риски lock-in и план миграции.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Популярные frontend-фреймворки
  2. Обучение: React
  3. Карта подготовки: Популярные frontend-фреймворки

8. Что такое change detection в Angular?​

Теги: frameworks, frontend, angular Сложность: Middle/Senior

Короткий ответ​

Change detection определяет, какие компоненты и когда обновлять.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично при выборе стека, архитектурной стратегии и планировании найма команды.
  2. Главный риск: Выбор стека без учета команды и продукта увеличивает стоимость разработки и риск миграции.
  3. Как проверяете решение: Сравниваю baseline по DX/perf и подтверждаю решение на мини-кейсе, близком к продуктовой задаче.

Мини-пример​

@Component({ standalone: true, selector: 'app-root', template: '{{title}}' })
export class AppComponent { title = 'hello'; }

Углубление (2-3 минуты)​

  1. Свяжите тему "Что такое change detection в Angular?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Сравните два фреймворка по критериям продукта: DX, perf, hiring, цена миграции.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Не считают стоимость миграции и обучения команды.
  2. Сравнивают фреймворки по синтаксису, игнорируя эксплуатационные риски.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Какие NFR определяют выбор стека в этом сценарии?
  2. Как оцените цену миграции между решениями через 6-12 месяцев?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Критерии, по которым команда примет решение.
  2. Сравнение стеков по NFR и стоимости владения.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Популярные frontend-фреймворки
  2. Обучение: React
  3. Карта подготовки: Популярные frontend-фреймворки

9. В чем сила Svelte как compiler-first фреймворка?​

Теги: frameworks, frontend, svelte Сложность: Middle/Senior

Короткий ответ​

Svelte компилирует реактивность заранее, уменьшая runtime overhead.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично при выборе стека, архитектурной стратегии и планировании найма команды.
  2. Главный риск: Выбор стека без учета команды и продукта увеличивает стоимость разработки и риск миграции.
  3. Как проверяете решение: Сравниваю baseline по DX/perf и подтверждаю решение на мини-кейсе, близком к продуктовой задаче.

Мини-пример​

let count = 0;
$: doubled = count * 2;

Углубление (2-3 минуты)​

  1. Свяжите тему "В чем сила Svelte как compiler-first фреймворка?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, как выбор стека влияет на архитектурные границы.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Сравнивают фреймворки по синтаксису, игнорируя эксплуатационные риски.
  2. Не считают стоимость миграции и обучения команды.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как оцените цену миграции между решениями через 6-12 месяцев?
  2. Какие NFR определяют выбор стека в этом сценарии?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Критерии, по которым команда примет решение.
  2. Риски lock-in и план миграции.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Популярные frontend-фреймворки
  2. Обучение: React
  3. Карта подготовки: Популярные frontend-фреймворки

10. Чем Svelte отличается от runtime-подхода React/Vue?​

Теги: frameworks, frontend, vue, svelte Сложность: Middle/Senior

Короткий ответ​

В отличие от runtime-подхода React/Vue, Svelte переносит часть логики в compile phase.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично при выборе стека, архитектурной стратегии и планировании найма команды.
  2. Главный риск: Выбор стека без учета команды и продукта увеличивает стоимость разработки и риск миграции.
  3. Как проверяете решение: Проверяю сценарий миграции с контрольными точками и метриками стоимости сопровождения.

Мини-пример​

import { ref, computed } from 'vue';
const count = ref(0);
const doubled = computed(() => count.value * 2);

Углубление (2-3 минуты)​

  1. Свяжите тему "Чем Svelte отличается от runtime-подхода React/Vue?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Сравните два фреймворка по критериям продукта: DX, perf, hiring, цена миграции.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Не считают стоимость миграции и обучения команды.
  2. Сравнивают фреймворки по синтаксису, игнорируя эксплуатационные риски.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как оцените цену миграции между решениями через 6-12 месяцев?
  2. Что важнее в этом контексте: DX команды или runtime-производительность?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Сравнение стеков по NFR и стоимости владения.
  2. Риски lock-in и план миграции.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Популярные frontend-фреймворки
  2. Обучение: React
  3. Карта подготовки: Популярные frontend-фреймворки

11. Как выбрать фреймворк под enterprise-проект?​

Теги: frameworks, frontend Сложность: Middle/Senior

Короткий ответ​

Framework для enterprise выбирают по масштабируемости, найму, зрелости tooling и долгосрочной поддержке.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично при выборе стека, архитектурной стратегии и планировании найма команды.
  2. Главный риск: Фреймворк-решение без контекста продукта и команды увеличивает стоимость сопровождения и найма.
  3. Как проверяете решение: Проверяю сценарий миграции с контрольными точками и метриками стоимости сопровождения.

Мини-пример​

const stackScore = {
  learningCurve: 3,
  hiringMarket: 4,
  perfBudget: 4,
  ecosystemMaturity: 5
};

Углубление (2-3 минуты)​

  1. Свяжите тему "Как выбрать фреймворк под enterprise-проект?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Отделите «что удобно сейчас» от «что масштабируется через 12 месяцев».
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Выбирают стек по хайпу, а не по требованиям продукта.
  2. Сравнивают фреймворки по синтаксису, игнорируя эксплуатационные риски.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как оцените цену миграции между решениями через 6-12 месяцев?
  2. Какие NFR определяют выбор стека в этом сценарии?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Критерии, по которым команда примет решение.
  2. Сравнение стеков по NFR и стоимости владения.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Популярные frontend-фреймворки
  2. Обучение: React
  3. Карта подготовки: Популярные frontend-фреймворки

12. Как выбрать фреймворк под MVP с ограниченной командой?​

Теги: frameworks, frontend Сложность: Middle/Senior

Короткий ответ​

Для MVP обычно важнее скорость разработки, onboarding и стоимость поддержки.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично при выборе стека, архитектурной стратегии и планировании найма команды.
  2. Главный риск: Фреймворк-решение без контекста продукта и команды увеличивает стоимость сопровождения и найма.
  3. Как проверяете решение: Проверяю сценарий миграции с контрольными точками и метриками стоимости сопровождения.

Мини-пример​

const stackScore = {
  learningCurve: 3,
  hiringMarket: 4,
  perfBudget: 4,
  ecosystemMaturity: 5
};

Углубление (2-3 минуты)​

  1. Свяжите тему "Как выбрать фреймворк под MVP с ограниченной командой?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, как выбор стека влияет на архитектурные границы.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Не считают стоимость миграции и обучения команды.
  2. Выбирают стек по хайпу, а не по требованиям продукта.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Что важнее в этом контексте: DX команды или runtime-производительность?
  2. Какие NFR определяют выбор стека в этом сценарии?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Риски lock-in и план миграции.
  2. Критерии, по которым команда примет решение.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Популярные frontend-фреймворки
  2. Обучение: React
  3. Карта подготовки: Популярные frontend-фреймворки

13. Что учитывать при миграции с React на Vue/Angular?​

Теги: frameworks, frontend, angular, vue Сложность: Middle/Senior

Короткий ответ​

Миграция между framework требует поэтапной стратегии и стабильных boundary-контрактов.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично при выборе стека, архитектурной стратегии и планировании найма команды.
  2. Главный риск: Big-bang миграции без rollback-плана часто приводят к длительным инцидентам.
  3. Как проверяете решение: Проверяю сценарий миграции с контрольными точками и метриками стоимости сопровождения.

Мини-пример​

import { ref, computed } from 'vue';
const count = ref(0);
const doubled = computed(() => count.value * 2);

Углубление (2-3 минуты)​

  1. Свяжите тему "Что учитывать при миграции с React на Vue/Angular?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Сравните два фреймворка по критериям продукта: DX, perf, hiring, цена миграции.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Сравнивают фреймворки по синтаксису, игнорируя эксплуатационные риски.
  2. Не считают стоимость миграции и обучения команды.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Что важнее в этом контексте: DX команды или runtime-производительность?
  2. Какие NFR определяют выбор стека в этом сценарии?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Риски lock-in и план миграции.
  2. Критерии, по которым команда примет решение.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Популярные frontend-фреймворки
  2. Обучение: React
  3. Карта подготовки: Популярные frontend-фреймворки

14. Как оценивать стоимость смены стека в продукте?​

Теги: frameworks, frontend Сложность: Middle/Senior

Короткий ответ​

Стоимость смены стека включает обучение, интеграции, потери темпа и риски регрессий.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично при выборе стека, архитектурной стратегии и планировании найма команды.
  2. Главный риск: Фреймворк-решение без контекста продукта и команды увеличивает стоимость сопровождения и найма.
  3. Как проверяете решение: Сравниваю baseline по DX/perf и подтверждаю решение на мини-кейсе, близком к продуктовой задаче.

Мини-пример​

const stackScore = {
  learningCurve: 3,
  hiringMarket: 4,
  perfBudget: 4,
  ecosystemMaturity: 5
};

Углубление (2-3 минуты)​

  1. Свяжите тему "Как оценивать стоимость смены стека в продукте?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Отделите «что удобно сейчас» от «что масштабируется через 12 месяцев».
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Не считают стоимость миграции и обучения команды.
  2. Выбирают стек по хайпу, а не по требованиям продукта.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как оцените цену миграции между решениями через 6-12 месяцев?
  2. Что важнее в этом контексте: DX команды или runtime-производительность?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Сравнение стеков по NFR и стоимости владения.
  2. Критерии, по которым команда примет решение.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Популярные frontend-фреймворки
  2. Обучение: React
  3. Карта подготовки: Популярные frontend-фреймворки

15. Какие риски vendor lock-in в framework-экосистеме?​

Теги: frameworks, frontend Сложность: Middle/Senior

Короткий ответ​

Vendor lock-in проявляется в tight coupling к API/экосистеме конкретного framework.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично при выборе стека, архитектурной стратегии и планировании найма команды.
  2. Главный риск: Выбор стека без учета команды и продукта увеличивает стоимость разработки и риск миграции.
  3. Как проверяете решение: Проверяю сценарий миграции с контрольными точками и метриками стоимости сопровождения.

Мини-пример​

const stackScore = {
  learningCurve: 3,
  hiringMarket: 4,
  perfBudget: 4,
  ecosystemMaturity: 5
};

Углубление (2-3 минуты)​

  1. Свяжите тему "Какие риски vendor lock-in в framework-экосистеме?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Сравните два фреймворка по критериям продукта: DX, perf, hiring, цена миграции.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Выбирают стек по хайпу, а не по требованиям продукта.
  2. Не считают стоимость миграции и обучения команды.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Какие NFR определяют выбор стека в этом сценарии?
  2. Что важнее в этом контексте: DX команды или runtime-производительность?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Сравнение стеков по NFR и стоимости владения.
  2. Риски lock-in и план миграции.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Популярные frontend-фреймворки
  2. Обучение: React
  3. Карта подготовки: Популярные frontend-фреймворки

16. Как сравнивать экосистемы по tooling и DX?​

Теги: frameworks, frontend Сложность: Middle/Senior

Короткий ответ​

DX сравнивают по tooling, debugging, документации, тестированию и скорости команды.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично при выборе стека, архитектурной стратегии и планировании найма команды.
  2. Главный риск: Фреймворк-решение без контекста продукта и команды увеличивает стоимость сопровождения и найма.
  3. Как проверяете решение: Сравниваю baseline по DX/perf и подтверждаю решение на мини-кейсе, близком к продуктовой задаче.

Мини-пример​

const stackScore = {
  learningCurve: 3,
  hiringMarket: 4,
  perfBudget: 4,
  ecosystemMaturity: 5
};

Углубление (2-3 минуты)​

  1. Свяжите тему "Как сравнивать экосистемы по tooling и DX?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Отделите «что удобно сейчас» от «что масштабируется через 12 месяцев».
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Не считают стоимость миграции и обучения команды.
  2. Сравнивают фреймворки по синтаксису, игнорируя эксплуатационные риски.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Какие NFR определяют выбор стека в этом сценарии?
  2. Что важнее в этом контексте: DX команды или runtime-производительность?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Риски lock-in и план миграции.
  2. Сравнение стеков по NFR и стоимости владения.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Популярные frontend-фреймворки
  2. Обучение: React
  3. Карта подготовки: Популярные frontend-фреймворки

17. Как влияет framework choice на performance-budget?​

Теги: frameworks, frontend Сложность: Middle/Senior

Короткий ответ​

Выбор framework влияет на performance budget через runtime стоимость и размер бандла.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично при выборе стека, архитектурной стратегии и планировании найма команды.
  2. Главный риск: Выбор стека без учета команды и продукта увеличивает стоимость разработки и риск миграции.
  3. Как проверяете решение: Фиксирую критерии выбора стека и прогоняю их на двух альтернативах вместо интуитивного выбора.

Мини-пример​

const stackScore = {
  learningCurve: 3,
  hiringMarket: 4,
  perfBudget: 4,
  ecosystemMaturity: 5
};

Углубление (2-3 минуты)​

  1. Свяжите тему "Как влияет framework choice на performance-budget?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Сравните два фреймворка по критериям продукта: DX, perf, hiring, цена миграции.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Выбирают стек по хайпу, а не по требованиям продукта.
  2. Сравнивают фреймворки по синтаксису, игнорируя эксплуатационные риски.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Какие NFR определяют выбор стека в этом сценарии?
  2. Как оцените цену миграции между решениями через 6-12 месяцев?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Риски lock-in и план миграции.
  2. Сравнение стеков по NFR и стоимости владения.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Популярные frontend-фреймворки
  2. Обучение: React
  3. Карта подготовки: Популярные frontend-фреймворки

18. Как влияет framework choice на hiring и onboarding?​

Теги: frameworks, frontend Сложность: Middle/Senior

Короткий ответ​

Выбор стека влияет на hiring, onboarding и риск bus factor.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично при выборе стека, архитектурной стратегии и планировании найма команды.
  2. Главный риск: Выбор стека без учета команды и продукта увеличивает стоимость разработки и риск миграции.
  3. Как проверяете решение: Фиксирую критерии выбора стека и прогоняю их на двух альтернативах вместо интуитивного выбора.

Мини-пример​

const stackScore = {
  learningCurve: 3,
  hiringMarket: 4,
  perfBudget: 4,
  ecosystemMaturity: 5
};

Углубление (2-3 минуты)​

  1. Свяжите тему "Как влияет framework choice на hiring и onboarding?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Отделите «что удобно сейчас» от «что масштабируется через 12 месяцев».
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Выбирают стек по хайпу, а не по требованиям продукта.
  2. Не считают стоимость миграции и обучения команды.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как оцените цену миграции между решениями через 6-12 месяцев?
  2. Какие NFR определяют выбор стека в этом сценарии?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Критерии, по которым команда примет решение.
  2. Сравнение стеков по NFR и стоимости владения.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Популярные frontend-фреймворки
  2. Обучение: React
  3. Карта подготовки: Популярные frontend-фреймворки

19. Как переносить архитектурные практики между экосистемами?​

Теги: frameworks, frontend Сложность: Middle/Senior

Короткий ответ​

Перенос архитектурных практик возможен, если мыслить принципами, а не API конкретной библиотеки.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично при выборе стека, архитектурной стратегии и планировании найма команды.
  2. Главный риск: Фреймворк-решение без контекста продукта и команды увеличивает стоимость сопровождения и найма.
  3. Как проверяете решение: Сравниваю baseline по DX/perf и подтверждаю решение на мини-кейсе, близком к продуктовой задаче.

Мини-пример​

const stackScore = {
  learningCurve: 3,
  hiringMarket: 4,
  perfBudget: 4,
  ecosystemMaturity: 5
};

Углубление (2-3 минуты)​

  1. Свяжите тему "Как переносить архитектурные практики между экосистемами?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, как выбор стека влияет на архитектурные границы.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Сравнивают фреймворки по синтаксису, игнорируя эксплуатационные риски.
  2. Не считают стоимость миграции и обучения команды.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как оцените цену миграции между решениями через 6-12 месяцев?
  2. Какие NFR определяют выбор стека в этом сценарии?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Критерии, по которым команда примет решение.
  2. Риски lock-in и план миграции.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Популярные frontend-фреймворки
  2. Обучение: React
  3. Карта подготовки: Популярные frontend-фреймворки

20. Как аргументированно отвечать на вопрос Почему не React?​

Теги: frameworks, frontend Сложность: Middle/Senior

Короткий ответ​

На вопрос «почему не React» отвечают через требования продукта и контекст команды.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично при выборе стека, архитектурной стратегии и планировании найма команды.
  2. Главный риск: Выбор стека без учета команды и продукта увеличивает стоимость разработки и риск миграции.
  3. Как проверяете решение: Проверяю сценарий миграции с контрольными точками и метриками стоимости сопровождения.

Мини-пример​

const stackScore = {
  learningCurve: 3,
  hiringMarket: 4,
  perfBudget: 4,
  ecosystemMaturity: 5
};

Куда дальше​

  1. Вернитесь в модуль: Популярные frontend-фреймворки.
  2. Сверьтесь с картой темы: Frontend-фреймворки.
  3. Продолжайте по маршруту: Middle трек.
  4. Закрепите один ответ на практике в Песочнице.

Углубление (2-3 минуты)​

  1. Свяжите тему "Как аргументированно отвечать на вопрос Почему не React?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Отделите «что удобно сейчас» от «что масштабируется через 12 месяцев».
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Сравнивают фреймворки по синтаксису, игнорируя эксплуатационные риски.
  2. Не считают стоимость миграции и обучения команды.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Какие NFR определяют выбор стека в этом сценарии?
  2. Как оцените цену миграции между решениями через 6-12 месяцев?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Риски lock-in и план миграции.
  2. Сравнение стеков по NFR и стоимости владения.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Популярные frontend-фреймворки
  2. Обучение: React
  3. Карта подготовки: Популярные frontend-фреймворки