Я не 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 и документации облачные модели скатываются в "среднестатистический код", а не ищут наиболее эффективное решение в рамках конкретной библиотеки.
Предполагаю, что чем больше будет выкладываться и использоваться таких библиотек, тем сильнее это закрепится в весах моделей. Но равновероятна и ситуация, когда это не поможет, а модели займут нишу локальных помощников, пока не изменится подход к их обучению и кодогенерации. В любом случае, свой вклад в позитивный сценарий я сделал, дальше покажет только время.
Рекламы не будет - заводить канал некогда. Вот репозиторий, там довольно много архитектурно интересного, особенно в плане тестирования. Буду рад, если пригодится.
Комментарии (23)
cmyser
14.03.2026 20:22опять одна библиотека с одним маленьким решением
Это путь в никуда, нужна полноценная система где у разработчика не будет возможности сделать "плохой" или "неправильный" выбор
Желательно вообще не делать выбор, что бы в фреймворки это было уже настолько продумано, что бы внешнее решение не требовалось
clerik_r
14.03.2026 20:22Это путь в никуда
Нет. Это может быть путь в никуда именно для вас, а для настоящих разработчиков это путь вперед и вверх!
нужна полноценная система где у разработчика не будет возможности сделать "плохой" или "неправильный" выбор
Получается вы не можете(и не хотите) сделать шаг влево шаг вправо без указки начальника/хозяина/и т.п. Ну как бы к такой жизненной философии не надо людей привлекать, человечество не так давно от нее освободилось) Кто-то предпочитает свободу, а кто-то рабство. Я например отношусь к тем, кто принципиально предпочитает свободу.
Желательно вообще не делать выбор, что бы в фреймворки это было уже настолько продумано, что бы внешнее решение не требовалось
Мда, это конечно очень удручающе) Боюсь вы не ту профессию выбрали)
опять одна библиотека с одним маленьким решением
Так это прекрасно, одно маленькое, но качественное решение, чем большой уродливый монстр.
cmyser
14.03.2026 20:22Все берут эти "хорошие маленькие решёния" а получают глючное приложение на реакте
clerik_r
14.03.2026 20:22Все берут эти "хорошие маленькие решёния" а получают глючное приложение на реакте
Кто всё? 100% разработчиков? Или под "все" вы имеете ввиду только плохих разработчиков? Почему то у меня все прекрасно получается когда я беру хорошие маленькие решения и много у кого все прекрасно получается.
cmyser
14.03.2026 20:22Большинство
На самом деле конечно чаще берут то что уже знают, это самая верная эвристика
Здорово что у вас получается, правда
Я аппелирую только не совсем к этому. Да из маленьких либ можно собрать хорошее приложение, но это сложнее как при постройке так и в поддержке, лучше когда флоу продуманы, cookbookи написаны
Но ещё лучше когда остаётся написать только бизнес логику, а всё остальное берёт на себя фрейморк, при этом никак не ограничивая закопаться вглубь
cmyser
14.03.2026 20:22Чем "настоящий" разработчик отличается от "ненастоящего" ? Я вот код пишу, даже зачастую руками, я разработчик , по вашему ?
Незнаю что вы там навыдумывали про свободу какие то бредни
Хз реально чем вы кичетесь, не понимаю. Лучше конечно инструмент решает много задач, а не приходится под каждую задачу подбирать отдельный инструмент, особенно во фронтенде, так как это полностью формализованная область знаний
clerik_r
14.03.2026 20:22Чем "настоящий" разработчик отличается от "ненастоящего" ? Я вот код пишу, даже зачастую руками, я разработчик , по вашему ?
Настоящий - не тот, кто пишет код руками, а тот кто любит это делать, любит разбираться досконально всё устроено, как всё работает и т.п. И т.к. априори настоящий разработчик уже знает что и как устроено и что и как работает, то понятное дело он хочет делать все максимально удобно для себя, без ограничений и т.п. Потому что он знает, как сделать лучше. И если его не устраивает монструозный фреймворк all-in-one, то это не потому что разработчик плохой, а потому что фреймворк плохой.
Незнаю что вы там навыдумывали про свободу какие то бредни
Это не выдумки, вы прямо говорите что свобода плохо, надо зажимать в тиски разработчика что нельзя было ступить шаг влево шаг вправо.
под каждую задачу подбирать отдельный инструмент
У меня основа Typescript + React + MobX, все остальные задачи я решаю сам, и не подбираю под каждую задачу библиотеку, более того за много лет у меня давно есть решения почти на все случаи жизни) У меня и свой роутер которому уже лет 8 и инструменты для работы с формами/валидации, всякие хэлперы для асинхронного кода, плагины для Vite и т.д. и т.п.
cmyser
14.03.2026 20:22если его не устраивает монструозный фреймворк all-in-one, то это не потому что разработчик плохой, а потому что фреймворк плохой.
Логически неверный аргумент
Про свободу. Где свободнее, в строго типизированных языках или динамических ? Где свободнее, в языках с прямым доступом к памяти или в языках где есть GC ?
Вся история программирования - про искусственные ограничения. Но при этом должна оставаться гибкость в использовании, как раз для решений разработчика.
За mobx like, хороший инструмент
Для себя я выбрал $mol, по скорости как mobx, только не нужно следить за состояниями, реактивностью, он сам под капотом всё делает хорошо
clerik_r
14.03.2026 20:22Для себя я выбрал $mol
Это всё объясняет))))
Вся история программирования - про искусственные ограничения. Но при этом должна оставаться гибкость в использовании, как раз для решений разработчика.
Да?)) Понятно) Нужно чтобы машина не разгонялась больше 20км/ч, но при этом нужно чтобы она разгонялась до 300км/ч)
cmyser
14.03.2026 20:22вы считаете что языки с динамической типизацией лучше чем со статической ? врядли, вы используете typescript
но по вашему типы - это же ограничение, почему не избавитесь от него ?
давайте по существу, без пространных аналогий ( которые не работают )clerik_r
14.03.2026 20:22вы считаете что языки с динамической типизацией лучше чем со статической ?
Всё хорошо в меру, TS меня более чем устраивает)
но по вашему типы - это же ограничение, почему не избавитесь от него ?
В Typescript это опциональное ограничение и это ключевой фактор. И мне в 95% случаев типизация ничем не мешает и не ограничивает. А для всего остального есть any)
cmyser
14.03.2026 20:22опциональное ограничение
ура, мы пришли к общему знаменателю, я говорю ровно о том же самом
ограничения + гибкостьclerik_r
14.03.2026 20:22ура, мы пришли к общему знаменателю, я говорю ровно о том же самомограничения + гибкость
Однако вот ваши слова:
Это путь в никуда, нужна полноценная система где у разработчика не будет возможности сделать "плохой" или "неправильный" выбор
Желательно вообще не делать выбор, что бы в фреймворки это было уже настолько продумано, что бы внешнее решение не требовалось
Т.е. гибкости не должно быть согласно им)
Вот есть в фреймворке Х дерьмовый стейт менеджмет - пользуйся, он же уже есть, да он работает, но он просто дерьмовый, но это никого не волнует, он же уже есть и выбирать не надо и даже думать об этом не надо. И т.д. и т.п.
А это уже не похоже на ограничения + гибкость, это исключительно ограничения)cmyser
14.03.2026 20:22Выбор из хороших решений же есть...
В этом случае нужно фрейморк менять. Фронтенд полностью формализованная область, можно взять лучшее в своём классе и не задумывать о внутренностях
clerik_r
14.03.2026 20:22Выбор из хороших решений же есть...
Не существует ни одного фреймворка в мире в котором есть решения на все случаи жизни и при этом все они классные, работают быстро, код писать приятно и т.п.
В этом случае нужно фрейморк менять
Или лучше собрать свой из кирпичиков, которые тебя устраивают, а те что не устраивают реализовать самому)
LukinBoris
14.03.2026 20:22Это, конечно, решает частную боль автора этой либы, но их всегда будут писать, как минимум по той причине, что что-то большое иногда происходить от чего-то маленького, так что в этом нет ничего плохого
nadge
14.03.2026 20:22"ведь к более качественному закрытому коду доступа нет"
Объясните пожалуйста, а чего это он более качественный?
DmitryKazakov8 Автор
14.03.2026 20:22Статистики именно по "качеству" нигде нет, исхожу только из личного опыта и открытой статистики. Например, в прошлом году на Гитхабе 81% коммитов были именно в приватных рабочих репо, и процессы там как правило строже - с ревью, тестами, постоянной production-доработкой и адаптацией к новым технологиям.
А в публичных репо большая часть - пет-проекты или библиотеки даже без базовых тестов / эксперименты, которые в проде никто и не использовал. Да и из оставшихся репо многие устарели или заброшены с много лет висящими issues, потому что OSS очень непросто монетизировать, а на энтузиазме далеко не уедешь. Поэтому мысль "ИИ в основном обучается на менее качественном коде, не готовом к продакшену и стабильной предсказательной генерации", думаю, валидна.
Конечно, есть OSS авторы с шикарными библиотеками, но как правило они их писали как раз для продакшена и после нескольких лет доработок и обкатки выложили в публичные репо. Есть и компании, у которых бизнес-модель построена на OSS и они могут нанимать большие команды, чтобы делать качественно. Но это капля в море
francyfox
14.03.2026 20:22я только ближайший аналог знаю Nano Stores Router (да знаю подход другой, но там проще). В теории это намного лучше чем vue-router. Но поддерживать это будет больно из-за обилия адаптеров. Тут ведь не только на чистом vite делают, тут есть метафреймворки вроде nuxt/next/remix/astro. И под каждого нужен свой адаптер. Хорошо если подхватит комьюнити, но я не думаю. Кстати я не нашел как использовать metadata и локализацию
DmitryKazakov8 Автор
14.03.2026 20:22Метафреймворки на то и есть, чтобы под них не писали адаптеры, а вся экосистема была "из коробки" - туда независимым разработчикам очень сложно интегрироваться, да и не нужно.
По поводу metadata (title, description, social теги) - это хотя и можно сделать через роутер (внутри beforeEnter), лучше все-таки использовать компоненты страниц. То есть проставлять их при рендере на onMount или другими способами конкретной UI-библиотеки, так сохранится поддержка SSR и MPA.
Под локализацией не понял, что имеется в виду, так как есть разные схемы. Например, заводят поддомены вида lang.mydomain , тогда в конфигурации роутера никаких изменений делать не нужно. Либо если через params - можно к каждому path добавлять параметр
/:lang/home, либо черезquery: { lang: (v) => ['en', 'ru'].includes(v) }. Я бы рекомендовал вариант с поддоменами - поисковики с этим лучше работают, да и код не нужно подстраивать.francyfox
14.03.2026 20:22да согласен меня не в ту степь занесло про метафреймворки.
metadata тоже не нужно, можно через ssrContext пробросить. (или provide/inject). Просто привык к meta, layouts, file routing, префиксам и тд.
Здесь просто этого нету, ладно надо просто поиграться.
Triton5
Спасибо, что делитесь своими разработками:)