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

Популярные 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 - UI library с сильным фокусом на component tree, state ownership и однонаправленный data flow; архитектуру вокруг routing, data fetching и forms команда часто собирает сама или через framework. Vue - progressive framework: можно начать с малого, но есть цельная экосистема и встроенная реактивность. Angular - opinionated application framework: DI, routing, forms, HTTP, templates и CLI задают больше правил из коробки.

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

Я сравниваю не синтаксис, а архитектурную модель. В React ключевой вопрос - где живёт state и как данные текут через компоненты; это гибко, но требует договорённостей команды. Vue даёт более цельную модель компонентов, reactivity и Single-File Components, поэтому часто снижает порог входа и разнобой решений. Angular сильнее стандартизирует приложение: dependency injection, services, routing и forms сразу формируют enterprise-style структуру, но требуют принять framework-правила.

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

Feature: product catalog filters

React: decide state owner + routing/data libraries.
Vue: use SFC + refs/computed + official ecosystem.
Angular: model feature through components, services and DI providers.

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

  1. React хорошо подходит, когда команда умеет проектировать boundaries сама: state ownership, hooks, server/client framework, data layer, forms.
  2. Vue полезен, когда важны быстрая продуктивность, понятная структура SFC и возможность инкрементально внедряться в существующий UI.
  3. Angular полезен там, где нужна стандартизация: DI, typed services, route boundaries, forms, testing и единый подход в большой команде.
  4. Главный trade-off: гибкость против предсказуемости. Чем меньше framework навязывает, тем больше архитектурной дисциплины нужно от команды.
  5. Выбор должен проверяться на реальном feature slice: форма, data fetching, routing, validation, тесты, performance и onboarding нового разработчика.

Практика​

Сделайте framework decision matrix для одной фичи: фильтруемый каталог, личный кабинет или админский CRUD. Столбцы: state ownership, routing, forms, data fetching, validation, testing, onboarding, bundle/performance, migration cost. Заполните для React, Vue и Angular.

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

  1. Сравнивать только JSX/templates, не разбирая state, DI, routing и data layer.
  2. Называть React "легче", не учитывая стоимость выбора дополнительных библиотек.
  3. Называть Angular "тяжёлым", не учитывая выигрыш от стандартизации в большой команде.
  4. Выбирать Vue только за простоту старта, не проверив долгосрочные требования к экосистеме.

Follow-up вопросы​

  1. Где в каждом стеке будет жить shared state и business logic?
  2. Что команда получит из коробки, а что ей придётся стандартизировать самой?
  3. Как изменится выбор для MVP, enterprise-dashboard и embedded widget?
  4. Как проверить решение на vertical slice до полной миграции?

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

  1. React component hierarchy, props/state, state ownership.
  2. Vue progressive model, SFC, reactivity.
  3. Angular DI, services, routing/forms как часть framework-архитектуры.

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

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

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

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

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

Vue может быть лучше React, когда команде важны быстрый старт, единообразная структура компонентов, official-friendly ecosystem и мягкое внедрение в существующий продукт. Это не значит "Vue всегда проще"; он выигрывает, если его conventions закрывают реальные командные проблемы: onboarding, consistency, legacy integration и скорость delivery.

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

Я бы выбрал Vue не "потому что он проще", а если у команды мало опыта в проектировании React-архитектуры, есть много UI без сложной platform-логики, нужна понятная SFC-структура и хочется меньше решений вокруг базового стека. Vue хорошо ложится на инкрементальное внедрение: можно начать с виджета или отдельного route. Но если продукт уже сильно завязан на React ecosystem, Next.js, hiring pool или существующие design-system компоненты, переход на Vue может быть дороже пользы.

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

Good Vue fit:
- legacy server-rendered pages need interactive widgets
- team wants one SFC file per component
- product needs fast CRUD/admin UI delivery
- no deep React ecosystem dependency yet

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

  1. Vue снижает количество ранних архитектурных выборов: template, SFC, reactivity и official ecosystem дают общий язык команде.
  2. Инкрементальность важна для legacy: можно усилить отдельные страницы без полной переписи приложения.
  3. Composition API позволяет масштабировать сложные компоненты, но без дисциплины можно получить "мешок composables".
  4. React может быть лучше при сильной существующей экспертизе, зрелом internal design system, Next.js/server rendering strategy или большем hiring pool под конкретный рынок.
  5. Решение надо проверять на 2-3 типичных flow: form-heavy page, data table, modal workflow, permissions и тестирование.

Практика​

Составьте Vue adoption fit review: текущая команда, legacy constraints, дизайн-система, SSR/SEO, forms, state management, testing, hiring, migration boundary. Отметьте, где Vue снижает риск, а где создаёт новый.

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

  1. Говорить "Vue проще", не уточняя для кого и в каком типе продукта.
  2. Игнорировать стоимость существующей React design system и накопленных hooks/components.
  3. Выбирать Vue для всей платформы, хотя достаточно embedded widgets.
  4. Недооценивать требования к архитектуре composables и shared state.

Follow-up вопросы​

  1. Когда Vue стоит внедрять инкрементально, а когда делать новый app?
  2. Какие признаки говорят, что React останется дешевле для команды?
  3. Как проверить Vue на feature slice за 1-2 недели?
  4. Что может пойти не так с composables в большой кодовой базе?

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

  1. Vue progressive model and SFC.
  2. Composition API, composables, reactivity basics.
  3. React ecosystem lock-in: design system, routing, SSR, data layer.

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

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

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

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

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

Composition API - стиль Vue, где состояние, computed values, watchers и lifecycle-логика группируются по фиче через setup()/<script setup> и composable functions. Он нужен, чтобы переиспользовать stateful logic, лучше типизировать зависимости и не размазывать одну фичу по data, methods, computed и lifecycle-секциям Options API.

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

Главная ценность Composition API - не "новый синтаксис", а организация сложной логики. В большом компоненте Options API часто группирует код по типу API: data отдельно, methods отдельно, watchers отдельно. Composition API позволяет собрать рядом всё, что относится к одной фиче: загрузка данных, состояние формы, computed validation, cleanup. Повторяемую часть можно вынести в composable вроде useSearchFilters(), сохранив реактивность и явные входы/выходы.

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

import { computed, ref } from 'vue';

export function useSearchFilters(items) {
  const query = ref('');
  const filtered = computed(() =>
    items.value.filter((item) => item.name.includes(query.value))
  );

  return { query, filtered };
}

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

  1. Composition API улучшает logic reuse через composables без проблем mixins: скрытых конфликтов имён и неявных зависимостей.
  2. Он лучше раскрывает dependencies: composable получает входы и возвращает reactive state/functions явно.
  3. TypeScript обычно работает естественнее, потому что логика находится в обычных функциях.
  4. Риск: слишком абстрактные composables, которые тянут router/store/API и становятся вторым framework внутри приложения.
  5. Не каждую Options API-компоненту нужно переписывать: Composition API ценен там, где есть сложная stateful logic или повторение.

Практика​

Возьмите компонент с таблицей, фильтрами и загрузкой. Разделите его на composables: useTableQuery, usePagination, useSelection. Для каждого запишите входы, возвращаемые refs/computed, side effects и как это тестировать отдельно.

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

  1. Выносить в composable всё подряд, включая чистые функции без состояния.
  2. Возвращать из composable слишком много несвязанных refs и делать API нечитабельным.
  3. Прятать network side effects внутри composable без явного control flow.
  4. Смешивать Options API и Composition API так, что источник данных становится неясным.

Follow-up вопросы​

  1. Чем composable лучше mixin?
  2. Когда Composition API ухудшает читаемость?
  3. Как тестировать composable отдельно от компонента?
  4. Что должно быть входом и выходом хорошего composable?

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

  1. Vue Composition API FAQ.
  2. ref, computed, watch, lifecycle hooks inside composables.
  3. Composable API design: inputs, outputs, side effects.

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

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

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

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

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

Vue reactivity отслеживает чтение reactive state и повторно запускает зависимые эффекты при изменении. reactive() использует Proxy для объектов, ref() хранит значение в .value, computed() кэширует производное значение и инвалидируется при изменении зависимостей. Поэтому важно понимать, где происходит tracking и когда связь теряется.

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

Во Vue зависимость появляется при чтении reactive значения во время render/effect/computed. Если потом это значение меняется, Vue вызывает связанные обновления. Для объектов reactive перехватывает get/set через Proxy, а ref отслеживает доступ к .value. Типичный баг: destructuring или передача plain value наружу ломает связь, потому что дальше код работает уже не с reactive источником.

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

import { computed, reactive, toRefs } from 'vue';

const state = reactive({ count: 1 });
const { count } = toRefs(state);
const doubled = computed(() => count.value * 2);

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

  1. reactive хорош для объектов, но destructuring без toRefs может потерять reactivity.
  2. ref часто рекомендуют как основной API для state, потому что он явно показывает reactive access через .value.
  3. computed должен быть pure derivation; side effects лучше выносить в watch/watchEffect.
  4. Ref unwrapping имеет исключения: массивы, коллекции и вложенные объекты могут требовать явного .value.
  5. Performance-риск возникает не из-за "магии", а из-за слишком широких dependencies, тяжёлых computed и неочищенных watchers.

Практика​

Разберите Vue dependency-tracking trace: для state.user.name, const { user } = state, toRefs(state), computed, watchEffect отметьте, где dependency tracked, где связь теряется и какой mutation вызовет обновление UI.

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

  1. Деструктурировать reactive объект и удивляться, что UI не обновляется.
  2. Использовать computed для side effects.
  3. Забывать .value в JavaScript-коде и путать это с template unwrapping.
  4. Делать глубокий reactive объект для внешнего immutable/state-machine state без shallowRef.

Follow-up вопросы​

  1. Чем ref отличается от reactive?
  2. Почему destructuring может сломать reactivity?
  3. Когда нужен computed, а когда watch?
  4. Какие caveats есть у ref unwrapping?

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

  1. Vue reactivity fundamentals: ref, reactive, computed.
  2. Reactivity in depth: track, trigger, effects.
  3. toRef, toRefs, shallowRef, watcher cleanup.

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

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

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

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

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

DI в Angular - механизм, через который классы получают зависимости извне, а не создают их сами. Он важен для разделения ответственности, тестируемости, переиспользования services и контроля scope: root singleton, route-level provider, component-level provider или custom injection token.

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

В Angular DI - не просто удобный способ импортировать сервис. Это архитектурная граница: компонент зависит от абстракции/сервиса, а injector решает, какую реализацию и в каком scope выдать. providedIn: 'root' даёт singleton на приложение, provider на route/component может создать отдельный экземпляр для фичи или виджета. Поэтому DI влияет на state sharing, lazy loading, тесты, multi-tenant сценарии и случайные баги из-за неправильного provider scope.

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

@Injectable({ providedIn: 'root' })
export class AuditLogger {
  track(event: string) {}
}

@Component({ selector: 'app-card', template: '...' })
export class CardComponent {
  private logger = inject(AuditLogger);
}

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

  1. Dependency - это сервис, value, factory или token, который класс использует, но не создаёт сам.
  2. Injector hierarchy определяет scope: root EnvironmentInjector, route/lazy boundaries, component ElementInjector.
  3. providedIn: 'root' обычно tree-shakable и подходит для app-wide services, но не для состояния, которое должно быть изолировано per feature.
  4. Injection tokens нужны для config values, interfaces-like contracts и runtime-specific implementations.
  5. Хороший DI дизайн упрощает unit tests: можно заменить real service test double-ом без переписывания компонента.

Практика​

Сделайте Angular DI provider-scope drill: для AuthService, FeatureFlags, CartState, ModalRef, ApiBaseUrl выберите root/route/component/token/factory scope. Для каждого объясните, что сломается при слишком широком или слишком узком scope.

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

  1. Класть feature-local state в root singleton и получать утечки между routes/users.
  2. Создавать сервис через new внутри компонента, обходя DI и тестируемость.
  3. Не понимать, почему provider на component создаёт новый instance.
  4. Использовать plain string/config напрямую вместо injection token.

Follow-up вопросы​

  1. Чем root provider отличается от component provider?
  2. Когда нужен injection token?
  3. Как DI помогает тестировать компонент?
  4. Как lazy loading влияет на provider scope?

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

  1. Angular dependency injection overview.
  2. Providers, inject(), @Injectable({ providedIn: 'root' }).
  3. Hierarchical injectors and provider scopes.

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

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

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

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

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

Standalone components убирают обязательную привязку компонента к NgModule: зависимости компонента явно перечисляются в imports, а приложение можно bootstrap-ить через standalone root. Это снижает boilerplate и делает feature boundary ближе к самому компоненту, но не отменяет DI, routing, lazy loading и архитектурные решения.

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

Я бы объяснил standalone как смену единицы композиции. Раньше Angular-команда часто думала NgModule-ами: declarations, imports, exports. В standalone-подходе компонент сам объявляет, какие компоненты, directives и pipes нужны его template. Это упрощает локальное чтение, lazy routes и постепенную миграцию, но provider scope всё равно надо проектировать осознанно: сервис может быть root, route-level или component-level.

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

@Component({
  selector: 'app-user-card',
  imports: [DatePipe, RouterLink],
  template: `<a [routerLink]="['/users', id]">{{ createdAt | date }}</a>`,
})
export class UserCardComponent {
  id = 42;
  createdAt = new Date();
}

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

  1. Standalone делает component dependencies явными: если template использует directive/pipe/component, он появляется в imports.
  2. NgModule остаётся важным для legacy-кода и library compatibility, но для нового кода Angular рекомендует standalone-first.
  3. Главный выигрыш - меньше "магии declarations/exports" и проще lazy route boundary.
  4. Главный риск - размазать imports/providers без feature ownership и получить неуправляемую композицию.
  5. При миграции лучше идти route-by-route или feature-by-feature, сохраняя smoke tests и DI scope.

Практика​

Сделайте standalone boundary map для фичи UserProfile: root component, child components, shared pipes/directives, route providers, root services. Отметьте, какие зависимости входят в imports, а какие остаются providers.

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

  1. Думать, что standalone отменяет dependency injection или provider scope.
  2. Переносить всё в shared imports-массив и снова получать скрытые зависимости.
  3. Мигрировать NgModule механически, не проверяя lazy routes и providers.
  4. Не различать component imports и application-wide providers.

Follow-up вопросы​

  1. Чем standalone component отличается от component declared in NgModule?
  2. Что будет, если забыть import pipe/directive, который использует template?
  3. Как standalone влияет на lazy loading?
  4. Где хранить providers при standalone-migration?

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

  1. Angular standalone components and component imports.
  2. NgModule responsibilities in legacy code.
  3. Route-level providers, lazy routes, bootstrapApplication.

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

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

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

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

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

RxJS в Angular нужен для моделирования async streams: HTTP, forms, route params, user events, websockets, polling и отменяемые запросы. Он особенно силён там, где нужно комбинировать источники, отменять старые операции, дебаунсить ввод, разделять loading/error/data и управлять lifetime подписок.

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

Я не использую RxJS "везде вместо state". В Angular он естественен для потоков событий и данных: route.paramMap, HttpClient, forms и UI events. Типичный пример - поиск: debounceTime, distinctUntilChanged, switchMap, catchError, shareReplay. В template лучше использовать async pipe или интероп с signals через toSignal; ручной subscribe в компоненте нужен редко и должен иметь cleanup, например takeUntilDestroyed.

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

results$ = this.queryControl.valueChanges.pipe(
  debounceTime(300),
  distinctUntilChanged(),
  switchMap((query) => this.api.search(query)),
);

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

  1. switchMap важен для отмены устаревших запросов: результат старого поиска не должен перетереть новый.
  2. combineLatest полезен для derived query: фильтр + сортировка + pagination + route params.
  3. shareReplay может кэшировать stream, но без понимания lifetime можно получить stale data или memory retention.
  4. toSignal связывает Observable с signal, но создаёт subscription, поэтому результат надо переиспользовать, а не вызывать повторно.
  5. Ошибки нужно обрабатывать внутри stream, иначе один error может завершить весь поток UI.

Практика​

Сделайте RxJS stream-shape drill для страницы поиска: input text, selected filters, route category, HTTP request, loading, error, cancel stale request. Нарисуйте operators chain и объясните, где происходит cleanup.

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

  1. Делать вложенные subscribe вместо композиции operators.
  2. Использовать mergeMap там, где нужен switchMap и отмена старых запросов.
  3. Не закрывать manual subscriptions в компонентах.
  4. Прятать слишком сложный stream без именованных промежуточных шагов и тестов.

Follow-up вопросы​

  1. Чем switchMap отличается от mergeMap для поиска?
  2. Когда нужен async pipe, а когда toSignal?
  3. Как обработать error, чтобы UI stream не умер?
  4. Какие subscriptions Angular очистит автоматически, а какие нет?

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

  1. RxJS Observables, pipe, switchMap, combineLatest.
  2. Angular async pipe and @angular/core/rxjs-interop.
  3. takeUntilDestroyed, toSignal, error handling in streams.

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

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

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

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

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

Change detection - механизм, которым Angular проверяет, изменилась ли модель приложения, и нужно ли обновить DOM. Angular проходит по component tree, реагирует на async events, input changes, signals и manual marks. Performance-проблемы обычно возникают не от самого механизма, а от слишком частых triggers, тяжёлых template computations и mutable inputs.

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

Я объясняю change detection через вопрос "что заставит UI обновиться". Событие пользователя, HTTP/timer через Zone.js, новый input reference, signal update или manual markForCheck() могут привести к проверке. Для больших деревьев важно уметь пропускать поддеревья: OnPush/default strategy, immutable inputs, signals и вынос шумных сторонних callbacks за пределы Angular zone. При диагностике я смотрю не только на код, но и на Angular DevTools profiler.

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

@Component({
  selector: 'app-row',
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `{{ user.name }}`,
})
export class RowComponent {
  @Input() user!: User;
}

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

  1. Если input object мутировали без смены reference, OnPush subtree может не обновиться ожидаемо.
  2. Event внутри OnPush subtree всё равно может запустить проверку нужной части дерева.
  3. Тяжёлые функции в template вызываются при проверках и могут стать performance bottleneck.
  4. Zone pollution появляется, когда timers/third-party listeners запускают change detection без реального изменения state.
  5. Signals помогают granular tracking, но не отменяют необходимость понимать boundaries и expensive computations.

Практика​

Сделайте change-detection trigger trace: для пяти событий отметьте, что обновится: новый @Input reference, mutation поля внутри object, click в child component, setInterval third-party chart, signal .set(). Для каждого укажите, нужен ли OnPush, markForCheck, runOutsideAngular или immutable update.

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

  1. Лечить всё detectChanges() вместо понимания trigger.
  2. Мутировать input object и ждать обновления OnPush child.
  3. Держать expensive function calls прямо в template.
  4. Игнорировать zone pollution от charts, maps, timers и third-party widgets.

Follow-up вопросы​

  1. Что запускает change detection в Angular?
  2. Как OnPush пропускает component subtrees?
  3. Почему mutable input может не обновить UI?
  4. Когда использовать runOutsideAngular?

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

  1. Angular runtime performance and change detection.
  2. OnPush/skipping component subtrees.
  3. Signals, Zone.js, Angular DevTools profiler.

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

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

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

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

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

Сила Svelte в том, что framework делает большую часть работы на compile step: анализирует компонент, reactive declarations/runes, template и генерирует targeted DOM update code. Поэтому в runtime меньше framework-инфраструктуры, а разработчик пишет ближе к HTML/CSS/JS, но платит зависимостью от compiler semantics.

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

Я бы сказал, что Svelte - это не просто "меньше кода". Его идея: compiler заранее понимает, от чего зависит UI, и генерирует код обновления вместо того, чтобы держать крупную runtime abstraction. В Svelte 5 это выражено через runes вроде $state, $derived, $effect; в legacy API - через $: statements. Выигрыш хорошо виден в небольших интерактивных компонентах и виджетах, но важно понимать ограничения compile-time dependency analysis и SSR/hydration поведение.

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

<script>
  let count = $state(0);
  let doubled = $derived(count * 2);
</script>

<button onclick={() => count += 1}>{doubled}</button>

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

  1. Compiler-first подход уменьшает runtime abstraction, но делает compile rules частью mental model.
  2. В legacy $: dependencies определяются статически: если dependency спрятана в функции, compiler может её не увидеть.
  3. Runes делают reactivity более явной и переносимой в .svelte.js/.svelte.ts.
  4. Svelte хорошо подходит для embedded widgets, UI-heavy surfaces и команд, которым нужна простая component syntax.
  5. Риск - ecosystem/hiring/tooling maturity и переносимость архитектурных паттернов из React/Vue.

Практика​

Сделайте Svelte compiled-output reasoning: для counter, derived value, conditional block и list update объясните, какие зависимости compiler видит, что должно обновиться в DOM и где появится баг, если dependency спрятана непрямо.

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

  1. Называть Svelte "без runtime" в абсолютном смысле, хотя runtime APIs и lifecycle всё равно есть.
  2. Не понимать, какие зависимости compiler видит статически.
  3. Писать side effects в reactive derivations.
  4. Переносить React mental model 1:1 и ожидать virtual DOM behavior.

Follow-up вопросы​

  1. Что значит compiler-first в Svelte?
  2. Чем $state/$derived отличаются от обычных функций?
  3. Где compile-time dependency analysis может ошибочно не увидеть зависимость?
  4. Какие продукты особенно выигрывают от Svelte?

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

  1. Svelte runes: $state, $derived, $effect.
  2. Legacy $: reactive statements and dependency rules.
  3. Svelte compiler/runtime boundaries.

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

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

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

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

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

React и Vue выполняют значимую часть работы в runtime: React reconciles component output, Vue tracks reactive dependencies while app runs. Svelte старается перенести больше решений в compiler: template, reactivity syntax и DOM update plan анализируются заранее. Это может уменьшить runtime overhead, но делает build step и compiler rules более критичными.

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

Я бы сравнил по тому, где принимается решение об обновлении UI. В React runtime заново вызывает components и reconciles результат. Во Vue runtime отслеживает reactive dependencies и обновляет связанные effects. В Svelte compiler заранее превращает компонент в imperative update code и делает reactivity частью языка/синтаксиса. Поэтому Svelte может быть очень эффективен для UI widgets, но React/Vue часто выигрывают ecosystem size, patterns, DevTools familiarity и переносимостью mental model для больших команд.

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

React: render -> compare/reconcile at runtime.
Vue: track reactive reads -> trigger effects at runtime.
Svelte: compile component -> generated targeted DOM updates.

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

  1. Runtime frameworks дают больше динамической гибкости: component trees, DevTools, ecosystem plugins, SSR frameworks.
  2. Compiler-first frameworks требуют понимать build output, compiler warnings, reactivity syntax and limitations.
  3. Performance нельзя решать по лозунгу: нужно мерить bundle, hydration, update cost, memory и developer workflow.
  4. Svelte может быть сильным выбором для isolated product surfaces, embedded widgets и performance-sensitive UI.
  5. Для enterprise важнее не только runtime cost, но и hiring, testing, design system, accessibility tooling и migration path.

Практика​

Сделайте compiler-vs-runtime decision matrix для трёх сценариев: embedded pricing widget, large CRM dashboard, public marketing site с интерактивными формами. Сравните React/Vue/Svelte по update model, ecosystem, SSR/hydration, tooling, hiring и migration risk.

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

  1. Считать, что compiler-first автоматически быстрее во всех приложениях.
  2. Игнорировать ecosystem и hiring, оценивая только bundle/runtime.
  3. Путать Vue reactivity runtime с React reconciliation model.
  4. Не учитывать SSR/hydration и build pipeline при выборе Svelte.

Follow-up вопросы​

  1. Где React принимает решение об обновлении UI, а где Svelte?
  2. Чем Vue runtime reactivity отличается от React render/reconcile?
  3. Какие метрики докажут преимущество Svelte в конкретном продукте?
  4. Когда runtime framework будет практичнее compiler-first?

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

  1. React rendering/reconciliation mental model.
  2. Vue runtime reactivity.
  3. Svelte compiler, runes, generated update code trade-offs.

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

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

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

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

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

Для enterprise-проекта framework выбирают не по личным предпочтениям, а по долгосрочной способности команды безопасно развивать продукт: архитектурные boundaries, hiring, tooling, testability, accessibility, performance budget, release process, governance, ecosystem stability и migration cost. Побеждает не самый "модный" стек, а стек с наименьшим совокупным риском владения.

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

Я начинаю с constraints: размер команды, срок жизни продукта, compliance, дизайн-система, SSR/SEO, internationalization, accessibility, support matrix, hiring market и уже существующие компоненты. Потом делаю weighted scorecard, но не как "таблицу вкусов", а как риск-модель: где у нас single point of failure, где tooling зрелый, где проще стандартизировать архитектуру и где дешевле нанимать. Для enterprise я особенно смотрю на predictability: code ownership, testing, observability, upgrade path и возможность обучать новых людей.

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

Enterprise scorecard:
- Architecture governance: React 3 / Vue 3 / Angular 5
- Hiring and onboarding: React 5 / Vue 3 / Angular 4
- Design system maturity: React 5 / Vue 3 / Angular 4
- Built-in conventions: React 2 / Vue 3 / Angular 5
- Migration risk from current codebase: context-dependent

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

  1. Enterprise usually optimizes for predictability: consistent patterns, upgrade path, testing strategy and ownership.
  2. React often wins where hiring, ecosystem and existing design-system investment dominate, but needs strong internal conventions.
  3. Angular can win where standardized architecture, DI, forms, routing and large-team governance matter more than flexibility.
  4. Vue can win where a team needs a gentler learning curve and cohesive component model without adopting a heavier framework.
  5. The answer should end with a validation plan: build one feature slice, measure onboarding, defects, performance and delivery speed.

Практика​

Сделайте enterprise decision scorecard для CRM на 5 лет: 30 frontend-разработчиков, role-based UI, design system, audit logs, analytics, i18n, accessibility. Задайте веса критериям и объясните, какой framework вы выбрали бы и какой риск приняли.

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

  1. Сравнивать только developer happiness, не учитывая governance и hiring.
  2. Делать scorecard без весов: все критерии не равны.
  3. Игнорировать текущие активы: design system, shared components, testing utilities.
  4. Не планировать upgrade path и ownership для framework-specific решений.

Follow-up вопросы​

  1. Какие критерии enterprise-выбора имеют самый большой вес?
  2. Когда Angular может быть рациональнее React?
  3. Как доказать выбор через feature slice?
  4. Какие риски останутся даже после хорошего выбора?

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

  1. Framework governance, testing, accessibility, design-system ownership.
  2. React ecosystem vs Angular conventions vs Vue progressive model.
  3. Weighted decision matrix and validation through vertical slice.

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

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

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

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

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

Для MVP с маленькой командой главный критерий - скорость проверки гипотез без дорогого технического долга. Обычно важнее existing expertise, готовые шаблоны, скорость доставки формы/таблицы/auth/payment, deployment simplicity и возможность позже масштабировать архитектуру. "Лучший framework" - тот, который команда уже умеет безопасно использовать в ближайшие недели.

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

Я бы не выбирал стек для MVP как для enterprise. Для MVP нужна минимальная неопределённость: команда знает framework, быстро собирает CRUD/forms, есть starter, deploy понятен, тесты и аналитика не требуют большой инфраструктуры. Если команда сильна в React/Next - это часто рациональный выбор. Если нужна простая интерактивная админка и команда знает Vue - Vue может дать меньше ceremony. Angular для MVP может быть оправдан, если команда уже Angular-heavy или продукт сразу требует enterprise-структуры.

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

MVP constraints:
- team: 2 frontend devs, 8 weeks
- flows: onboarding, billing, admin table
- risk: pivot likely
- decision: choose known stack, isolate domain logic, avoid deep framework coupling

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

  1. MVP optimizes for learning speed: time-to-first-user, change speed, observability, rollback, analytics.
  2. Existing team skill can outweigh theoretical framework advantages.
  3. Avoid overfitting early architecture: keep domain logic and API contracts portable.
  4. Don't ignore future migration completely; define seams around routing, API client, forms, design tokens and state.
  5. The answer should include a kill switch: when MVP grows, what signals trigger architecture hardening.

Практика​

Сделайте MVP constraint matrix: команда, сроки, тип UI, SSR/SEO, auth, payments, forms, analytics, expected pivot rate, hiring. Для каждого критерия укажите, какой framework снижает риск сейчас и какой долг создаёт через 6 месяцев.

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

  1. Выбирать "enterprise-ready" stack и терять скорость проверки гипотез.
  2. Гнаться за новым framework, который команда не знает.
  3. Не отделять domain logic от UI framework и усложнять future pivot.
  4. Игнорировать deployment/testing/analytics, потому что "это всего MVP".

Follow-up вопросы​

  1. Когда MVP-выбор должен отличаться от enterprise-выбора?
  2. Какие признаки говорят, что пора ужесточать архитектуру?
  3. Как оставить возможность миграции без преждевременного overengineering?
  4. Когда Angular всё же оправдан для MVP?

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

  1. MVP constraints, time-to-learning, pivot cost.
  2. Starter templates, deployment path, observability minimum.
  3. Portable domain boundaries and API client isolation.

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

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

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

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

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

Миграция с React на Vue/Angular должна идти через boundaries, а не через "переписать всё". Нужно описать причины миграции, текущие зависимости от React, route/feature boundaries, shared domain layer, design system, state/data fetching, tests, analytics, SSR/SEO, rollout и rollback. Самый опасный вариант - big-bang rewrite без параллельной доставки фич.

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

Я бы начал с вопроса "зачем мигрируем": performance, hiring, architecture, legacy, vendor constraint или business reason. Потом разбил бы приложение на migration units: routes, widgets, microfrontends или page islands. Важно заранее вынести общие contracts: API client, design tokens, validation schemas, analytics events, permission model. Первый deliverable - один vertical slice на новом framework с production smoke и rollback, а не большой branch на полгода.

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

Migration boundary plan:
1. freeze shared contracts: API, analytics, design tokens
2. migrate one low-risk route
3. run React and target framework side by side
4. compare UX, perf, errors, delivery speed
5. expand only after rollback works

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

  1. React-specific coupling lives in hooks, context, component library, routing, forms and state management.
  2. Vue migration often changes reactivity and component structure; Angular migration changes architecture more deeply through DI, services and templates.
  3. Shared design system is usually the hardest dependency; it may need wrappers or a parallel component set.
  4. Tests must move from implementation details to user flows and contracts, or migration will rewrite tests without proving behavior.
  5. Success metrics: delivery continuity, bug rate, route parity, performance, onboarding speed and ability to stop safely.

Практика​

Составьте migration boundary plan для React dashboard: 20 routes, shared design system, auth, analytics, charts, forms. Выберите первый route, опишите contracts, rollback, dual-run strategy и критерии "можно мигрировать следующий route".

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

  1. Мигрировать framework, не сформулировав business reason.
  2. Переписывать UI вместе с domain/API contracts и терять контроль над регрессиями.
  3. Недооценивать design system and forms.
  4. Держать migration branch отдельно от main слишком долго.

Follow-up вопросы​

  1. Как выбрать первый route для migration slice?
  2. Что должно быть framework-agnostic до миграции?
  3. Как мигрировать design system?
  4. Какие метрики покажут, что миграцию надо остановить?

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

  1. Strangler migration, route-by-route rollout, rollback.
  2. Framework-agnostic API client, analytics, design tokens.
  3. React hooks/context coupling vs Vue/Angular architecture.

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

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

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

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

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

Стоимость смены стека - это не только часы переписывания компонентов. Нужно считать discovery, обучение, параллельную поддержку двух стеков, design system, routing, forms, state/data layer, tests, accessibility, analytics, monitoring, CI/CD, performance regression, hiring и opportunity cost: какие product features команда не сделает из-за миграции.

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

Я оцениваю stack change как investment case. Сначала считаю one-time cost: audit, POC, migration tooling, переписывание routes, тесты, design system wrappers. Потом ongoing cost: поддержка двух стеков, onboarding, framework upgrades, hiring, code review knowledge. Отдельно считаю risk cost: регрессии, performance, SEO, accessibility, support incidents. Решение оправдано только если ожидаемый выигрыш больше этих затрат и есть waypoints, где проект можно остановить.

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

Stack-change cost ledger:
- 8 weeks migration effort
- 4 weeks design-system parity
- 2 months slower feature delivery
- doubled testing matrix during transition
- expected gain: faster hiring + lower defect rate + simpler architecture

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

  1. Cost should include people cost: training, review bottlenecks, loss of senior focus and onboarding materials.
  2. Technical cost includes hidden integrations: analytics, feature flags, A/B tests, accessibility checks, error tracking, SSR and build pipeline.
  3. Product cost is often larger than engineering estimate: postponed roadmap, delayed experiments, support noise.
  4. Measure before/after: lead time, defects, build time, onboarding time, component reuse, performance.
  5. Good migration has stop points: after POC, first route, design-system parity, first release.

Практика​

Сделайте stack-change cost ledger для продукта с 80 routes и 12 разработчиками. Разделите затраты на one-time, transition, ongoing и risk. Для каждой строки укажите owner, estimate confidence и evidence, который подтвердит или опровергнет оценку.

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

  1. Считать только rewrite hours и забывать тесты, tooling, onboarding.
  2. Не учитывать opportunity cost для product roadmap.
  3. Не закладывать период двух стеков.
  4. Не иметь stop points и продолжать миграцию из-за sunk cost.

Follow-up вопросы​

  1. Что входит в hidden cost смены framework?
  2. Как оценить opportunity cost?
  3. Какие метрики докажут, что миграция окупается?
  4. Когда дешевле улучшить текущий стек, чем менять его?

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

  1. One-time vs transition vs ongoing cost.
  2. Opportunity cost, risk cost, migration waypoints.
  3. Lead time, defect rate, onboarding time, performance regression.

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

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

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

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

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

Vendor lock-in в framework-экосистеме - это ситуация, когда бизнес-логика, UI, tooling, deployment и team knowledge настолько завязаны на конкретный framework/platform, что смена направления становится дорогой или рискованной. Lock-in не всегда плох: иногда это цена скорости и зрелой экосистемы. Опасен не сам lock-in, а неосознанный lock-in без exit strategy.

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

Я бы разделил lock-in на уровни: framework API, routing/data layer, design system, state management, build/deployment, hosting platform, tests и team skills. Например, React hooks в доменной логике, Angular services как единственный слой business logic или Vue-specific stores в core-правилах усложняют перенос. Контроль - не абстрагировать всё заранее, а держать переносимыми ключевые boundaries: domain rules, API contracts, validation schemas, design tokens, analytics events.

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

Lock-in risk register:
- Domain logic inside React hooks: high risk, extract to pure module
- Design tokens in CSS variables: low risk
- Router-specific analytics events: medium risk, wrap tracking API
- Platform-only deployment features: medium/high, document fallback

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

  1. Good lock-in is deliberate: team gains speed, tooling and ecosystem support.
  2. Bad lock-in hides business rules inside framework lifecycle, hooks, stores, templates or route loaders.
  3. Over-abstraction is also a risk: building a fake framework-agnostic layer can slow the team without real exit value.
  4. Lock-in controls should target high-value seams: API client, domain services, validation, analytics, design tokens.
  5. Review lock-in during architecture decisions, not only when migration becomes urgent.

Практика​

Составьте lock-in risk register для вашего frontend: routing, state, forms, design system, analytics, auth, deployment, testing. Для каждого пункта укажите risk level, mitigation, owner и "не абстрагировать сейчас" reason, если lock-in осознанно принят.

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

  1. Считать любой framework lock-in плохим и строить лишние абстракции.
  2. Прятать domain logic в hooks/composables/services без framework-agnostic слоя.
  3. Не документировать platform-specific deployment assumptions.
  4. Понимать lock-in только как "сложно переписать UI", забывая tooling и people.

Follow-up вопросы​

  1. Как отличить полезный lock-in от опасного?
  2. Какие части frontend стоит держать framework-agnostic?
  3. Когда абстракция от framework вреднее lock-in?
  4. Как снижать lock-in без полной миграции?

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

  1. Framework-specific APIs vs domain logic boundaries.
  2. Design tokens, API contracts, analytics wrappers.
  3. Lock-in risk register and exit strategy.

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

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

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

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

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

Tooling и DX сравнивают через реальные рабочие сценарии: создать feature, найти ошибку, написать тест, refactor-нуть компонент, обновить dependency, собрать production build, отладить performance и принять нового разработчика. Хороший DX - это не "приятный синтаксис", а меньше friction на повторяемых командных операциях.

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

Я бы сравнивал экосистемы через lab, а не через впечатления. Беру одинаковый feature slice и смотрю: scaffold, routing, forms, data fetching, test setup, type errors, DevTools, build diagnostics, docs, lint/format, IDE support, storybook/design-system path. Потом измеряю время до working feature, число неочевидных решений, качество ошибок и насколько легко новый человек поймёт структуру.

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

DX lab:
1. create feature route
2. add form + validation + API call
3. write unit and e2e smoke
4. debug failed request
5. inspect bundle/perf warning
6. onboard another dev through the diff

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

  1. DX для solo developer и DX для команды могут отличаться: команде важнее conventions, reviewability and repeatability.
  2. Tooling надо проверять на failure cases: broken import, failed typecheck, hydration mismatch, template error, stale generated code.
  3. Docs maturity важна не количеством страниц, а скоростью ответа на типовые production-вопросы.
  4. IDE/type support может снизить дефекты, но только если команда держит строгие conventions.
  5. DX score должен учитывать CI и upgrades, а не только local dev server.

Практика​

Проведите tooling/DX evaluation lab для React, Vue и Angular на одной фиче. Зафиксируйте время, список decisions, errors quality, test setup friction, DevTools usefulness и onboarding notes. Итогом должен быть не победитель вообще, а победитель для конкретной команды.

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

  1. Сравнивать DX по первому впечатлению от tutorial.
  2. Игнорировать failure modes: debugging часто важнее happy path.
  3. Не учитывать CI/build/update workflow.
  4. Приравнивать "меньше boilerplate" к "лучше для команды".

Follow-up вопросы​

  1. Какие DX-сценарии надо проверить перед выбором framework?
  2. Почему хороший local DX может провалиться в CI?
  3. Как измерить onboarding friction?
  4. Что важнее: меньше кода или более предсказуемые conventions?

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

  1. Framework tooling: CLI, DevTools, test runners, templates.
  2. Feature-slice evaluation and failure-case debugging.
  3. Team DX metrics: onboarding, reviewability, upgrade friction.

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

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

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

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

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

Framework choice влияет на performance budget через bundle/runtime cost, rendering model, hydration strategy, update frequency, ecosystem packages, code splitting, SSR/SSG support и tooling for profiling. Но framework сам по себе редко объясняет всё: архитектура, data fetching, assets, third-party scripts и design system часто важнее.

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

Я не говорю "Svelte быстрее React" или "Angular медленный" без сценария. Для performance budget я сначала задаю target: LCP, INP, JS bytes, hydration time, route transition, memory. Затем проверяю, как framework помогает или мешает: SSR/streaming, lazy loading, fine-grained updates, change detection, virtual DOM/reconciliation, compiler output, DevTools. Решение принимаю по prototype на реальном route и budget guard в CI.

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

Performance budget map:
- initial JS: 180 KB gzip
- LCP: < 2.5s on target device
- INP: < 200ms
- hydration: measurable and bounded
- third-party scripts: explicit budget owner

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

  1. Runtime model matters, but data fetching waterfalls and third-party scripts can dominate user metrics.
  2. SSR can improve first content, but hydration cost can still hurt interactivity.
  3. Angular performance depends on change detection boundaries, signals, lazy loading and template cost.
  4. React performance depends on render boundaries, memoization discipline, server/client split and data strategy.
  5. Svelte can reduce runtime overhead, but app-level choices still determine bundle and network behavior.

Практика​

Сделайте framework performance budget map для public catalog page: target device, route JS budget, LCP element, hydration work, data waterfall, third-party scripts. Для React/Vue/Angular/Svelte укажите, что нужно прототипировать, а что нельзя утверждать без измерения.

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

  1. Делать вывод о performance по framework reputation.
  2. Мерить только bundle size и не смотреть INP/hydration/update cost.
  3. Игнорировать third-party scripts и images.
  4. Не ставить budget guard в CI после выбора.

Follow-up вопросы​

  1. Какие performance metrics зависят от framework сильнее всего?
  2. Почему SSR не решает весь performance budget?
  3. Как доказать performance-гипотезу до миграции?
  4. Что может сделать React/Vue/Angular/Svelte медленным независимо от framework?

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

  1. LCP, INP, hydration, JS budget, route splitting.
  2. React render model, Angular change detection, Vue reactivity, Svelte compiler output.
  3. Performance prototype and CI budget guard.

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

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

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

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

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

Framework choice влияет на hiring через размер рынка, seniority mix, зарплатные ожидания и доступность менторов; на onboarding - через количество framework-specific concepts, conventions, docs, starter templates, internal examples и review rules. Чем менее распространён или более opinionated стек, тем важнее onboarding plan.

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

Я бы оценивал не только "сколько кандидатов знает React/Vue/Angular", а сколько людей смогут стать productive в нашей кодовой базе. React может дать широкий hiring pool, но onboarding зависит от наших внутренних conventions. Angular может требовать больше framework knowledge, зато стандартизация уменьшает разнобой. Vue может быть быстрее для входа в UI, но hiring pool и senior mentorship надо проверять по рынку. Для любого выбора нужен onboarding path: starter task, architecture guide, code review checklist and pairing.

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

Onboarding risk plan:
- week 1: feature walkthrough + design-system task
- week 2: route/data/form task under review
- week 3: production bugfix with observability
- risk: only one senior knows framework internals

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

  1. Hiring pool is local and role-specific: generic popularity is not enough.
  2. Onboarding friction comes from local architecture more than framework docs.
  3. Bus factor grows when core patterns exist only in senior heads, not in docs/examples.
  4. Framework-specific concepts need explicit training: hooks/rendering, Vue reactivity, Angular DI/RxJS/change detection.
  5. Hiring strategy can influence architecture: choose patterns easier to teach and review.

Практика​

Сделайте hiring/onboarding risk plan для команды из 6 человек, где два senior знают React, один знает Angular, а Vue/Svelte никто не использовал в production. Опишите hiring pool, training cost, mentoring bottlenecks, starter tasks и критерий "new hire productive".

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

  1. Принимать global popularity за локальную доступность кандидатов.
  2. Игнорировать internal architecture, из-за которой даже знакомый framework сложен.
  3. Не документировать review rules и feature patterns.
  4. Выбирать редкий стек без plan на mentoring и replacement.

Follow-up вопросы​

  1. Как оценить hiring pool до выбора framework?
  2. Почему React-знание не гарантирует быстрый onboarding?
  3. Какие framework concepts надо явно обучать?
  4. Как снизить bus factor после выбора стека?

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

  1. Hiring market vs internal productivity.
  2. Onboarding path, starter tasks, review checklists.
  3. Bus factor and framework-specific mentoring.

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

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

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

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

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

Архитектурные практики переносимы, если отделять principle от framework API. Можно переносить идеи: separation of concerns, state ownership, boundary contracts, feature slicing, design tokens, accessibility, testing pyramid, error handling. Нельзя механически переносить hooks, services, stores, lifecycle и component patterns без адаптации к reactive/rendering model нового framework.

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

Я бы отвечал через mapping. Например, "feature boundary" в React может быть folder + route + hooks; в Angular - route + standalone components + services/providers; во Vue - SFC + composables + store; в Svelte - components + stores/runes/module boundaries. Принцип один: локализовать state, API calls, validation and UI. Но реализация должна уважать framework: Angular DI, Vue reactivity, React render model, Svelte compiler semantics.

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

Practice transfer:
React hook useFilters -> Vue composable useFilters
Angular service -> framework-owned injectable boundary
Design tokens -> CSS variables shared across ecosystems
Domain validation -> pure TypeScript module

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

  1. переносите domain rules as pure modules, not framework lifecycle code.
  2. Design tokens, API contracts and validation schemas are good cross-ecosystem assets.
  3. State management patterns must adapt: React context/hooks, Vue composables, Angular services/signals, Svelte stores/runes are not identical.
  4. Tests should verify behavior, not framework internals, so they survive migration.
  5. A good candidate explains both reusable principle and framework-specific adaptation.

Практика​

Сделайте practice-transfer mapping: возьмите React feature с hooks, form validation, API client, route state и design tokens. Разложите, что переносится как pure logic, что становится Vue composable, Angular service/provider или Svelte store/rune, а что нужно перепроектировать.

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

  1. Переносить React hooks mental model в Angular services без учета DI lifecycle.
  2. Делать framework-agnostic abstraction там, где проще принять native pattern.
  3. Тестировать implementation details и терять tests при переносе.
  4. Считать CSS/design tokens "мелочью", хотя это один из самых переносимых assets.

Follow-up вопросы​

  1. Какие frontend-слои лучше всего переносятся между framework?
  2. Что нельзя переносить механически?
  3. Как адаптировать state ownership между React, Vue, Angular and Svelte?
  4. Какие tests помогают при смене ecosystem?

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

  1. Boundary contracts, feature slicing, pure domain modules.
  2. React hooks, Vue composables, Angular services/providers, Svelte stores/runes.
  3. Behavior tests vs implementation-detail tests.

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

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

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

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

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

На вопрос "почему не React" нельзя отвечать антирекламой React. Сильный ответ признаёт сильные стороны React и показывает, почему в конкретном контексте другой framework лучше удовлетворяет ограничениям продукта, команды или архитектуры: стандартизация, инкрементальное внедрение, compiler-first performance, existing expertise, governance или меньшая стоимость владения.

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

Я бы начал с того, что React - сильный default: hiring, ecosystem, design systems, SSR frameworks. Поэтому "не React" требует доказательства. Например, Angular рационален, если нужна строгая структура, DI, forms, routing и большая enterprise-команда. Vue рационален, если нужен быстрый вход, progressive adoption и cohesive component model. Svelte рационален для performance-sensitive widgets or UI-heavy surfaces, если команда принимает compiler-first trade-offs. Финально я бы сказал, как проверял решение: feature slice, performance budget, onboarding, maintenance cost.

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

"Not React" answer structure:
1. acknowledge React strengths
2. name product constraints
3. explain chosen framework advantage
4. state accepted trade-offs
5. show validation plan and rollback

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

  1. React is often the safe default, so alternative choice needs context and evidence.
  2. Good answer compares constraints, not taste: team skill, governance, UI type, performance, integration, hiring.
  3. You should name trade-offs honestly: ecosystem size, hiring, tooling, learning curve, migration path.
  4. Avoid absolutism: the answer can be "React would also work, but this constraint makes Vue/Angular/Svelte better".
  5. A senior answer includes validation and stop criteria, not only preference.

Практика​

Подготовьте "why not React" decision answer для трёх ситуаций: enterprise CRM, embedded calculator widget, legacy server-rendered product with interactive islands. Для каждой дайте выбранный framework, аргументы, trade-offs, validation plan and rollback.

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

  1. Отвечать "React плохой" вместо контекстного сравнения.
  2. Не признавать сильные стороны React ecosystem.
  3. Выбирать альтернативу без validation plan.
  4. Игнорировать hiring and maintenance costs.

Follow-up вопросы​

  1. Когда React остаётся лучшим default?
  2. Как доказать, что Angular/Vue/Svelte лучше именно здесь?
  3. Какие trade-offs альтернативного framework вы принимаете?
  4. Какой experiment подтвердит ваш ответ?

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

  1. React strengths and limits.
  2. Context-based framework decision.
  3. Validation plan, trade-offs, rollback criteria.

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

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

Куда дальше​

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