На днях, я опубликовал новость о выходе новой версии UI-библиотеки Symbiote.js, с обзором ее функций и необычной концепции. Я давно пишу на Хабре (и не только) о веб-компонентах и решениях на их основе, и знаю полный набор стандартных сомнений и возражений аудитории.

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

Для затравки

Symbiote.js - это библиотека для создания виджетов, переиспользуемых компонентов-агностиков и полноценных клиент-серверных приложений (c SSR), основанная на современных веб-стандартах. Развивается и используется в бою этот проект уже несколько лет, он давно не эксперимент и не поделка на коленке. Либа - доказала свою гибкость и эффективность, но, все-же, она не может быть идеальной, верно? Идеала не существует.

Производительность

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

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

Дело - в жизненном цикле Custom Elements и подходе, где слабосвязанная архитектура ставится во главу угла. Symbiote-компоненту необходимо "осмотреться" при инициализации. Он не знает заранее, с каким окружением ему предстоит работать, поэтому, он завязан на цикл браузерного парсинга HTML и построения DOM. Это - осознанное решение. Симбиот начинает все операции по привязке к данным ПОСЛЕ регистрации в DOM, и, к сожалению, это видно в цифрах.

Какие я вижу стратегии в связи с вышесказанным? Есть мысли по разделению локального контекста данных и работы с внешними источниками (через такой этап я уже проходил ранее), но это решение скорее косметическое, имеющее мало практического смысла, если задуматься.

Скорее всего, пока все останется как есть. Тем более, что как пользователь, проблем, скорее всего, вы наблюдать не будете. А если и будете, в пограничных случаях (например, огромные списки) - то есть хорошие обходные пути, основанные на самом обычном DOM API (об этом - в отдельном материале). В любом случае, мы тут говорим о абстрактных попугаях, никаких подвисаний вы точно не увидите.

Ну и SSR, частично, но проблему производительности и первичной отрисовки нивелирует: пользователь увидит вашу страницу, прилетевшую с сервера - максимально быстро и TTI будет самым минимальным.

ИИ-помощники - тупят и глючат

Не думаю, что современный подход к продвижению Open Source может игнорировать тот факт, что ИИ-помощники - теперь наши главные DevRel-союзники. Однако, если ваша библиотека еще не завирусилась - LLM будет "включать дурака" - путать ваши API c чужими, выдумывать про вашу либу всякую чушь.

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

Еще, прочистке мозгов нейросетей отлично способствует прямой анализ исходников. А у Symbiote.js - они простые и компактные и, обычно, хорошо помещаются в контекстном окне агента. Часто, это работает даже лучше, чем документация.

Не работает статический анализ в шаблонах

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

Абстрактно, эту проблему можно проиллюстрировать тем, как работает TypeScript с выборкой элементов из DOM по селекторам. Вы, наверняка, с таким встречались, когда тип элемента в TS не соответствует реальному типу, потому, что TypeScript использует примитивный маппинг для методов DOM API, а в реальности, селекторы могут указывать на что угодно, включая экземпляры Custom Elements.

Такое поведение характерно для базовых веб-технологий в целом (HTML, CSS, различные API), это не какой-то специфичный недостаток Симбиота. Это следствие свободы и гибкости. Просто, это может быть непривычным, по сравнению с библиотеками-конкурентами, где существуют прямые жесткие связи.

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

Требует квалификации

Кривая обучения и порог входа в Symbiote.js - довольно бархатные и дружелюбные. Базовый компонент - выглядит очень просто и понятно, и не требует никакого лишнего бойлерплейта или каких-то особых знаний, поверх стандартов. Вот только если вы начнете решать более сложные задачи - вам пригодятся хорошие знания современных веб-технологий и принципов построения приложений. Для людей, замкнутых в экосистеме мета-фреймворков, таких как React или Next.js - это часто бывает проблемой.

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

Каково наше решение? Мы видим два главных направления: ИИ-помощники, что очевидно, и развитие инфраструктуры референсов.

Нет комьюнити

У Symbiote.js нет, практически, никакого сообщества за пределами узкой группы разработчиков. Сейчас мы начали активно работать над этим, но, к сожалению, не можем выделить на это какие-то значительные ресурсы, ввиду занятости проектами, которые нас кормят. Даже не знаю, насколько это важно теперь, в эпоху пресловутого ИИ, но это то, что необходимо признать.

Нет поддержки от крупного вендора

Гораздо легче делать такие вещи, как Symbiote.js, под крылом крупной компании и под сенью ее бренда. Если вы, условно, Гугл - вашими либами будут пользоваться, даже если они не представляют из себя ничего выдающегося (я не хочу сказать ничего плохого про Open Source от Google, это просто пример). Если вы какой-то рандомный Алекс с Хабра - то, сами понимаете, участь ваша печальна.

Поэтому, мы очень заинтересованы во всяческом сотрудничестве, как с компаниями, так и с энтузиастами. И если вы видите в этой истории какие-то перспективы для себя - давайте общаться.

Спасибо за внимание.