Я не OpenSource разработчик, но за пару десятков лет написал под сотню enterprise-level библиотек, которые остаются в рабочем контуре, дорабатываются под каждый проект и адаптируются к новым технологиям. Большого смысла выходить в OSS не было, кроме как для упрощения обучения коллег и единого места хранения документации.

Но и желание помогать другим и делиться выстраданными подходами, экспертизой и конкретным кодом мне не чуждо - сегодня поможешь ты, завтра - тебе. Через полгода подготовки и адаптации к OpenSource (сам использую и дорабатываю около 8 лет) в свет выходит одна из библиотек моего рабочего контура - Reactive Route.

Так как я работаю с проектами на разных стеках, стараюсь писать код максимально framework-agnostic - независимыми слоями, которые можно заменить или переписать, не трогая остальной код проекта. А к фреймворкам и библиотекам для работы с состоянием они подключаются с помощью легковесных адаптеров, сохраняя синтаксис работы. Конкретно для Reactive Route выложил набор готовых адаптеров в комбинациях, которые сейчас чаще всего использую:

• React + MobX / Observable

• Preact (no compat) + MobX / Observable

• Solid.js + нативная реактивность / MobX / Observable

• Vue + нативная реактивность

В одном npm-пакете - строгая TS-типизация, SSR / MPA / no-JS / Widget режимы и тщательно протестированная отказоустойчивость. В статье не буду пересказывать документацию на русском и английском, а поговорю скорее про общие принципы качества, использование ИИ в разработке и почему многие библиотеки раздуваются, не успев даже стабилизировать ядро.

Кому подойдет Reactive Route

Большинство разработчиков OpenSource ставят себе целью "угодить всем" и "сделать весь набор фич конкурентов", мне же достаточно стабильности в рабочих сценариях. Библиотека подойдет людям с похожим инженерным мнением:

• Важен размер приложения и не хочется подключать крупные библиотеки ради части их функционала

• Важна модульность и переносимость между стеками для долгосрочного развития проекта

• Среди реактивных систем наиболее близок Proxy-based без value.value, value(), value.get()

• При выборе OpenSource библиотек важна отказоустойчивость и плотное покрытие unit, e2e и typing тестами

И однозначно не стоит ее брать, если подходят иммутабельность и лишние ререндеры, разбросанная по файлам и UI компонентам структура роутов, типизация на уровне string | unknown, раздутый размер приложения и node_modules, жестко заданная роутером структура файлов и отсутствие обязательной валидации.

Пример использования

import { createConfigs, createRouter } from 'reactive-route';
import { adapters } from 'reactive-route/adapters/{reactive-system}';
import { Router } from 'reactive-route/{framework}';

const configs = createConfigs({
  home: {
    path: '/',
    loader: () => import('./pages/home'),
  },
  notFound: {
    path: '/not-found',
    props: { errorCode: 404 },
    loader: () => import('./pages/error'),
  },
  internalError: {
    path: '/internal-error',
    props: { errorCode: 500 },
    loader: () => import('./pages/error'),
  }
});

const router = createRouter({ configs, adapters });

await router.init(location.href);

render(() => <Router router={router} />);

// использование внутри приложения
await router.redirect({ name: 'home' });

Это минимальный пример единовременной настройки, по мере развития приложения просто добавляются новые конфигурации, динамические переменные и query, асинхронный жизненный цикл, модульные архитектуры, SSR - все парой строк. Я привык максимально сокращать бойлерплейт и в коде проекта оставлять только специфичную бизнес-логику.

Да, при росте проекта конфигурация раздувается, но проще "свернуть" объект в IDE, чем собирать в уме дерево роутов из UI-компонентов, динамических объявлений и switch-case условий рантайма.

На этом официальная презентация закончена, кому интересно - приглашаю в документацию, а я перейду к пространным рассуждениям...

Про фреймворки

Не замечали, что популярные UI-фреймворки сейчас очень похожи (Angular давно не использовал, про него не уверен)? Компоненты, жизненный цикл, сериализация в DOM и строку, встроенный DI в виде контекстов, постепенная миграция на реактивность...

Я уже давно применяю универсальный подход, который позволяет переключаться между "рендерилками" с помощью адаптеров, не изменяя код. Разумеется, если не использовать специфичный функционал и жестко привязанные библиотеки.

Паттерн UI = fn(state) был эффективен и до 2014 (начало React-эры), и в 2026. И при грамотной архитектуре можно легко выбирать стек под проект - нужна ли побольше экосистема, или важнее размер бандла и перфоманс, или может предпочтения команды и состояние рынка труда.

К сожалению, фреймворки стараются максимально привязать к своей экосистеме, захватывая доли рынка и постепенно подсаживая на собственные хостинги и схемы монетизации, ведь их большие команды нужно кормить, а маркетинг - окупать. Однако эта привязка стоит довольно дорого реальным потребителям - ИТ-компаниям и разработчикам, которым приходится переписывать системы целиком при изменении требований или устаревании определенных фреймворков (что во фронтенде происходит довольно часто).

Классический пример привязки - React hooks, "никогда ранее не виданный" паттерн вызова сайд-эффектов с замкнутым состоянием из функций шаблонов. Или файловый роутинг, заставляющий связывать SEO-понятие "семантичный URL, удобный для поисковиков" и структуру приложения. После начала использования подобные паттерны очень непросто заменить, а OSS-авторам приходится их тащить в свои библиотеки и намертво привязывать к UI-фреймворку, жертвуя качеством, типизацией и универсальностью.

К счастью, есть и позитивные примеры - Solid.js позволяет встраивать альтернативную реактивность, не теряя точечных апдейтов DOM. Tanstack хоть и выпускает максимально раздутые библиотеки "со всеми фичами конкурентов", старается делать agnostic-ядро. Vue хоть и нацелен на свой стек, выпускает библиотеки с возможностью использования вне экосистемы.

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

И про ИИ

Пока я не вижу явной пользы от ИИ в рабочих задачах, хотя как и многие прохожу этот тернистый путь - эксперименты с разными моделями, локальные схемы с дообучением, слои из агентов, специализированные rules. При этом не отрицаю полезность в локальных задачах - для Reactive Route инструмент перевел документацию на английский и написал несколько компонентов для Vitepress.

Агрессивный маркетинг диктует, что ИИ "очень полезен и скоро нас всех заменит", однако когда рынок поделен между фреймворками и их официальной / устоявшейся экосистемой, она становится основным обучающим материалом для моделей, ведь к более качественному закрытому коду доступа нет. И даже для простейших проектов берется React Router на 50кб со строковыми редиректами, а агент вынужден прочитать весь проект, построить карту рантайм-дерева маршрутов и предсказать многострадальный Link path. Дорого и крайне неэффективно, верно?

И это касается не только роутеров - сейчас OpenSource абсолютно не готов к стабильной предсказательной кодогенерации. Необходимы именно библиотеки с полной типизацией, ограниченной ответственностью и малым ядром - на них при всем желании "галлюцинировать" не получится, так как еще на этапе компиляции TS выдаст ошибку, которую можно точечно и с минимальным контекстом исправить. Проблема в том, что даже при передаче полного API и документации облачные модели скатываются в "среднестатистический код", а не ищут наиболее эффективное решение в рамках конкретной библиотеки.

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

Рекламы не будет - заводить канал некогда. Вот репозиторий, там довольно много архитектурно интересного, особенно в плане тестирования. Буду рад, если пригодится.