Вам не нужен React: создаём минималистичную UI-библиотеку на чистом JavaScript

React, Vue и Angular давно стали стандартом фронтенд-разработки. Кажется, что без них невозможно построить современный интерфейс. Но что если я скажу вам, что для большинства задач фреймворк — это избыточность? В свежей статье разработчика Pedro Th (опубликована на его личном сайте) рассматривается неожиданный подход: создание собственной минималистичной UI-библиотеки на чистом JavaScript, которая покрывает до 90% типовых сценариев без единой строчки кода из тяжёлых зависимостей.

Сегодня, в августе 2026, когда размеры бандлов разрослись до немыслимых масштабов, а производительность стала критическим фактором, такие эксперименты выглядят особенно актуально. Автор статьи не призывает отказаться от React вообще, но предлагает пересмотреть, действительно ли нам нужны все эти абстракции для простых интерфейсов. Разберёмся, что именно предлагает разработчик, какие проблемы решает такой подход и кому это может быть полезно.

Суть эксперимента: почему фреймворки — не всегда панацея

Разработчик Pedro Th в своей статье «NoNeedReact» описывает практический опыт создания UI-библиотеки, которая заменяет базовый функционал React для ряда задач. Согласно его наблюдениям, современные SPA-приложения часто перегружены, и значительная часть кода связана не с логикой, а с механизмами самого фреймворка: виртуальный DOM, система Reactivity, хук-менеджеры.

Основные проблемы, которые он выделяет:
- Размер бандла. React + ReactDOM занимают около 140 Kb gzipped. Для небольших страниц это существенно.
- Сложность рантайма. Виртуальный DOM на каждое изменение — это вычислительные затраты.
- Когнитивная нагрузка. Разработчикам приходится держать в голове жизненные циклы, правила хуков, мемоизацию.

Вместо этого автор предлагает взять на вооружение простые паттерны: функции-компоненты, событийную модель, прямой манипуляцией DOM. В его реализации нет виртуального DOM — изменения применяются целевым образом к конкретным узлам.

Как построена минималистичная библиотека

В основе библиотеки лежит классический паттерн «component function». Каждый компонент — это функция, которая возвращает HTML-элемент. Для реактивности используется простой Store на подобии Redux, но всего в 50 строк кода.

Ключевые элементы библиотеки:

Пример кода из статьи (адаптированный для наглядности):

const store = reactiveStore({ count: 0 });

function Counter() {
  const el = createElement('div');
  const btn = createElement('button', { onClick: () => store.count++ }, 'Click');
  store.subscribe(() => {
    btn.textContent = 'Count: ' + store.count;
  });
  el.append(btn);
  return el;
}

render(document.body, Counter);

Как видите, ничего магического. По сути это прямое управление DOM, но организованное через понятные примитивы.

Проблемы, с которыми столкнулся автор

Важно понимать, что не все аспекты React так просто заменить. Автор честно перечисляет сложности, которые возникли в процессе:

1. Управление списками. В React вы просто используете key и фреймворк оптимизирует перерисовку. Здесь пришлось вручную сравнивать ключи и выполнять операции insert, remove, reorder.
2. Производительность при большом количестве подписок. Если на одно и то же состояние подписаны сотни элементов, их обновление может быть медленнее, чем diffing виртуального DOM.
3. Отсутствие изоляции состояния. Приходится вручную следить, чтобы компонент не «протекал» в глобальный DOM.

Для оптимизации автор применил технику, которую назвал «batching» — объединение нескольких изменений состояния в один пасс обновления. Это напоминает, как React собирает результаты в queue до рендера.

Сравнение производительности: vanilla JS против React

В статье приводятся бенчмарки на синтетическом тесте «TODO-приложение» с 1000 задач. Автор измерял скорость первоначального рендеринга и время обновления при добавлении/удалении записи.

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

Как видно, vanilla-библиотека выигрывает с большим отрывом. Единственная ниша, где React показал себя лучше — список с миллионом элементов и частыми обновлениями. Но такие случаи редки.

Почему вы можете отказаться от React (и когда не стоит)

Статья даёт чёткие критерии, когда самодельная библиотека разумна:

• Простой интерфейс: несколько страниц, формы, таблицы — не требующие сложной синхронизации.
• Медийные сайты: где интерактивность вторична, а контент статичен.
• Экосистема без гигантов: нет необходимости подключать роутер, стейт-менеджеры или библиотеки компонентов.
• Эксперименты и обучение: создание такой библиотеки отлично прокачивает понимание DOM и архитектурных паттернов.

Но в следующих случаях React остаётся оправданным:
- Огромные командные проекты с десятками разработчиков.
- Потребность в популярных библиотеках (например, react-table, dnd-kit), которые построены под React.
- Если ваша команда уже глубоко знает фреймворк и перенос на vanilla снизит скорость разработки.

Выводы

Автор статьи «NoNeedReact» провёл смелый эксперимент и доказал, что для большинства реальных задач можно обойтись без тяжёлых фреймворков, получив выигрыш в производительности до 60% и сократив размер кода в 20 раз. Но важно подчеркнуть: это не противопоставление технологиям, а напоминание, что инструмент должен соответствовать задаче.

Рекомендуем прочитать источник самостоятельно и проверить бенчмарки собственноручно. Если вы разработчик, который хочет прокачать навыки в чистом JavaScript, попробуйте написать свою библиотеку — этот опыт бесценен. И помните: даже если вы решите остаться на React, понимание внутренних механик DOM только углубит вашу экспертизу.

В современном мире, где каждая миллисекунда на счету, иногда лучшее решение — это минимализм.