Почему Mivra дальше должна расти через плагины

Вчера я снова работал над Mivra и поймал простую, но важную мысль. Настолько простую, что даже немного обидно: до неё надо было дойти раньше.

Mivra уже умеет главное. Это локальный редактор Markdown-файлов под Windows: визуальный режим, исходный Markdown, Mermaid-диаграммы, темы, базовое редактирование, сохранение файлов. Плюс я уже встроил загрузку картинок в S3-совместимое хранилище: вставил изображение, приложение отправило его в бакет и положило в документ нормальную ссылку. То есть файл уже можно передавать другому человеку без истории "а где лежит вот эта картинка с рабочего стола?".

И вот теперь я понимаю: S3 я тоже, скорее всего, встроил в ядро зря. Это полезная функция, но не базовая. Её место — рядом с PDF-экспортом, в системе расширений.

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

И вот тут я сначала пошёл привычным путём: ну, значит, надо встроить экспорт в само приложение. Добавить кнопку, протащить состояние, рендер, стили, настройки, обработку ошибок. Ещё одна фича в ядре. Потом ещё одна. Потом ещё.

А потом щёлкнуло: PDF не обязан быть частью ядра.

Ядро должно быть скучным

Это, кажется, главный вывод. Ядро приложения не должно разрастаться каждый раз, когда мне захотелось новую возможность. Оно должно делать базовые вещи надёжно: открыть файл, отредактировать, сохранить, показать Markdown, дать минимальный набор инструментов.

Всё остальное можно вынести наружу.

PDF-экспорт? Плагин.

S3-загрузка картинок? Тоже плагин.

Экспорт в DOCX? Плагин.

Своя панель для диаграмм, шаблоны, автогенерация оглавления, интеграция с каким-нибудь хранилищем — тоже плагины.

И это меняет не только код. Это меняет способ думать о продукте.

Почему это не просто "удобная архитектура"

Плагины — это не про красивую схему на доске. Это про дисциплину.

Когда ты вшиваешь каждую новую возможность в приложение, оно постепенно превращается в комбайн. Сначала это приятно: всё под рукой, всё родное, всё контролируешь. Но через какое-то время маленькая программа, которая должна была быстро открывать Markdown, начинает тащить за собой PDF-движок, облачные интеграции, настройки экспорта, дополнительные зависимости и кучу кода, который нужен не всем.

Плагинная модель решает эту проблему проще: кому нужен PDF, тот ставит PDF-плагин. Кому не нужен, у того приложение остаётся лёгким.

Это особенно важно для Mivra, потому что изначальная идея была именно в лёгком редакторе. Не в ещё одном тяжёлом редакторе всего на свете, а в нормальном инструменте для локальных Markdown-файлов.

Хорошие продукты давно так живут

Это не новая мысль в индустрии. Просто я сам до неё дошёл руками, через конкретную боль.

VS Code стал огромной платформой не потому, что Microsoft встроила в него все языки, все линтеры и все рабочие процессы мира. У него есть ядро и расширения.

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

В мире, на котором стоит Mivra, эта идея тоже уже рядом. Tauri сам живёт через плагины: файловая система, диалоги, opener, store — отдельные модули. Milkdown, на котором построен визуальный Markdown-редактор, тоже устроен вокруг плагинов: синтаксис, компоненты и поведение подключаются как расширения.

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

Что это меняет для Mivra

Для меня это означает простой разворот.

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

Не "добавить экспорт PDF в приложение".

А "сделать так, чтобы экспорт PDF стал первым нормальным плагином". И потом, возможно, вынести туда же S3-загрузку.

Разница большая. Во втором варианте я решаю не одну задачу, а создаю дорожку для следующих задач. Сегодня PDF. Завтра DOCX. Потом шаблоны документов. Потом интеграции. И всё это не обязано ломать основное приложение.

Плюс появляется нормальная точка входа для других разработчиков. Если кому-то нужна специфичная функция, ему не обязательно переписывать Mivra или ждать, пока я добавлю её в ядро. Он может написать расширение.

Минус тоже есть

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

Но это как раз честная сложность. Она появляется один раз на уровне архитектуры, а не размазывается по всему приложению через десятки полувстроенных возможностей.

И мне кажется, для Mivra это правильная сложность.

Итог

Я начинал с задачи "добавить экспорт в PDF". А пришёл к выводу, что Mivra нужно развивать не как набор всё более жирных встроенных функций, а как лёгкое ядро с расширениями.

Это маленький сдвиг в голове, но для приложения он может оказаться главным.

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

Для меня Mivra теперь именно про это: база остаётся простой, возможности растут снаружи.