Когда не нужно использовать фреймворк?

Когда фреймворк может быть избыточным

Использование фреймворка — не самоцель, а инструментальное решение. Современная разработка иногда излишне фреймворкоцентрична, но есть ситуации, когда отказ от них обоснован и даже предпочтителен.

Ключевые сценарии отказа от фреймворков

1. Микро-задачи и изолированные виджеты

Когда нужно встроить небольшой интерактивный компонент в существующую (возможно, устаревшую) систему. Например, кастомный калькулятор на сайте, написанном на jQuery или даже чистом PHP. Добавление React или Vue ради одного компонента — огромный оверхед.

// Вместо фреймворка — нативный модуль
class LoanCalculator {
  constructor(container) {
    this.container = container;
    this.init();
  }
  init() { /* Логика исключительно для калькулятора */ }
}
// Инициализация только где нужно
new LoanCalculator(document.getElementById('calc'));

2. Высокие требования к производительности и размеру бандла

Фреймворки несут мета-стоимость: runtime, виртуальный DOM, система реактивности. Для критичных к времени загрузки проектов (маркетинговые лендинги, прогрессивные веб-приложения для медленных сетей) каждый килобайт на счету. Preact или Svelte могут быть компромиссом, но иногда оптимальны чистые Web Components или нативный JS.

3. Эксперименты, прототипы и учебные проекты

Для глубокого понимания основ (например, как работает Virtual DOM, состояние, роутинг) лучше реализовать механизмы самостоятельно. Фреймворк абстрагирует сложность, что в обучении иногда вредит.

// Учебная реализация реактивности
let currentEffect = null;
class Dep {
  constructor() {
    this.subscribers = new Set();
  }
  depend() {
    if (currentEffect) this.subscribers.add(currentEffect);
  }
  notify() {
    this.subscribers.forEach(effect => effect());
  }
}

4. Проекты с уникальными архитектурными требованиями

Если архитектура сильно отклоняется от MVC/MVVM (например, высоконагруженные интерактивные игры, сложные графические редакторы, приложения с нестандартным жизненным циклом). Фреймворк может стать препятствием, а не помощью.

5. Миграционные периоды и легаси-системы

При постепенной модернизации крупной монолитной системы добавление фреймворка «сбоку» создает технический долг и усложняет сборку. Иногда целесообразно писать на ванильном JavaScript с модулями до полной готовности к переезду.

6. Ограниченные среды и специфические платформы

Некоторые встроенные системы, SSG (Static Site Generators) без интерактива, или проекты, где DOM-манипуляции минимальны (например, генерация отчетов в Canvas). Фреймворк здесь бесполезен.

Критерии принятия решения

Перед выбором фреймворка ответьте на вопросы:

• Масштаб приложения: Это SPA с 50+ экранами или статичная страница с формой?
• Команда и сроки: Есть ли экспертиза по фреймворку? Жесткие дедлайны могут диктовать использование знакомого инструмента.
• Долгосрочная поддержка: Будете ли вы поддерживать проект 5 лет? Фреймворк может устареть, а нативный код более устойчив.
• Экосистема vs контроль: Нужны ли готовые решения (UI-киты, роутеры) или важен полный контроль над каждым байтом?

Прагматичный баланс

Полный отказ от фреймворков сегодня — крайность, как и их слепое использование. Стратегия «прогрессивного улучшения» часто оптимальна:

1. Начните с нативного JS и модулей.
2. При росте сложности подключите легкие библиотеки (например, htmx для AJAX, Preact для компонентов).
3. Переходите на полноценный фреймворк только когда боль от его отсутствия перевесит стоимость интеграции.

Итог: Фреймворк — это аренда абстракций. Вы платите размером бандла, производительностью и свободой архитектуры ради скорости разработки, стандартизации и экосистемы. Аренда оправдана для сложных, долгоживущих проектов с типовыми требованиями. Для всего остального иногда лучше купить (написать) именно то, что нужно.