Круто! Я использую подобный сетап для работы во время стоянок в мотопутешествиях. Только у меня очки Viture Pro (хочу новые Xreal 1S), вместо компа - Galaxy 25 Ultra с удаленным доступом к основному компу, и Starlink Mini для связи в дебрях. А вот с клавиатурой у меня полная беда, использую китайскую складную, которой, естественно очень далеко до вашей. Я называю всю эту движуху - Outdoor Programming.
Чувак, я вообще не знаю кто ты, и кто тебя обидел. Я никаких минусов тебе не ставил. Если людям нет дела - они спокойно проходят мимо, но тебе, почему-то, есть дело, ты решил отметиться и нахамить. Может ты меня с кем-то перепутал?
так же не нужно руками что то дергать что бы интерфейс обновился, мол сам узнаёт через автоматический граф зависисмостей, перевычесляется при этом только то что изменилось
В Symbiote тоже не нужно ничего руками дергать для обновления, причем контексты данных также просто и свободно создаются на уровне всего приложения (как на клиенте так и на сервере), а не только локально, как в других мейнстримных либах. И тоже нет Virtual DOM. Но я говорил немного о другом - о том, что от вас зависит то, насколько эффективно вы взаимодействуете с DOM, но вы в любом случае, неизбежно взаимодействуете. Нельзя заявлять что вы это исключили из формулы, даже если вынесли всю основную кухню по подготовке к обновлениям в отдельную абстракцию.
Про ограничения веб-компонентов - это все сплошные мифы и заблуждения.
Хостовый объект не обязательно должен быть приаттачен к документу. Вы можете создавать экземпляры полностью в памяти, если вам это нужно (как и любой DOM-элемент). Если работа с данными организоване на этапе конструктора - вы не получите никаких дополнительных затрат, связанных с DOM. Такими объектами легко манипулировать в рамках Document Fragment, и это работает очень быстро.
Значениями атрибутов могут быть строки, потому, что они именно HTML-атрибуты, т. е. по определению - это часть HTML. Но никто не мешает вам работать со свойствами и методами экземпляров, которые могут иметь любой тип. В значения атрибутов можно писать любые сериализуемые данные (объекты или массивы), причем, десериализованы они будут быстрее, чем если бы вы определяли их в js-коде. Да, при таком подходе вы не можете передать прямые ссылки, но их, повторю, вы можете свободно передавать напрямую в объект компонента через геттеры, сеттеры, собственные поля и методы. Тут ВООБЩЕ нет никакой проблемы.
Жизненный цикл компонента начинается на этапе конструктора а не аттача.
Перенос хостового элемента приводит к реакции на disconnectedCAllback и connectedCallback, и вам никто не запрещает НЕ выполнять никакой лишней логики в этот момент. Просто установите флаг. Зато есть куча случаев, когда такая реакция, наоборот, необходима и у вас есть замечательная возможность это использовать.
Конфликт имен между либами обычно решается примитивными префиксами. Его словить совсем НЕ легко, мне лично, пока не удавалось. Но да, скоуп имен - общий. В Symbiote.js эта проблема решена в двух основных местах: автоматическое резервирование имен при коллизиях (браузер выдает ошибку, вы можете ее обработать как вам нужно) и при автоматической генерации элементов списков. Ну и вы можете разрешить коллизии тупо наследованием в своем контролируемом рантайме и задать нужные префиксы вручную.
Удалить компонент нельзя, но зачем это делать? Браузер просто хранит ссылку на конструктор, она особо кушать не просит.
В теневом DOM стили не "отваливаются", а изолируются. У такого поведения есть конкретное прямое назначение: избавить поставщиков решений от тех-же коллизий и глюков со стилями, оставив возможность безопасной конфигурации через дизайн-апи-токены. И тут важны два нюанса: стили вовсе не нужно никуда копировать, давно есть такая штука как adopted StyleSheets (поддерживается из коробки в Symbiote.js), и, что более важно, вас ВООБЩЕ никто не заставляет использовать Shadow DOM. Веб-компоненты могут быть БЕЗ Shadow DOM и стилизоваться самыми консервативными методами.
Веб-компоненты кое что знают о реактивности через `attributeChangedCallback`. Но, конечно, это не полноценная реактивность. И веб-компоненты - это не UI-библиотека чтобы это знать, а часть DOM API. Но на их основе вы можете сделать свои полноценные реактивные компоненты. Symbiote.js именно это и делает.
К сожалению, я не в Питере. Я живу в Аргентине. Но пришел бы с удовольствием.
Я бы вообще большинство задач, которые требуют браузера отправлял в puppeteer, через тот-же MCP. На мой взгляд, это гораздо более надежный способ, очень уж много глюков с расширениями и собственными тулзами агентов.
На мой взгляд, нельзя сказать, что какая-либо абстракция над DOM (как ваша компонентная модель) может решить какие-то фундаментальные проблемы, связанные с DOM. Это такая же манипуляция как и у разработчиков React, которые утверждали, что Virtual DOM - быстрее реального. Это вранье в принципе, так как этап синхронизации с реальным DOM - неизбежен. Они замели проблему под ковер и долго строили свой маркетинг на этом, но "проблема" никуда не делась. Это просто обман. Как и их функциональные компоненты с хуками, которые тянут сайд-эффекты, но продаются под брендом "чистая функция". А еще обман то, что такие проблемы, которые они решают таким образом - вообще существует.
В вашем случае - похожая ситуация. Вы рассказываете про то, что ваша компонентная модель лучше чем нативная, но эффективно строить веб UI без обращения к DOM API - невозможно. А Custom Elements - это часть современного DOM API (они не прибиты к DOM, они и есть DOM). И они - единственный способ организовать независимый и гранулярный жизненный цикл компонентов в браузере. Во всех остальных случаях - вы управляете жизненным циклом снаружи (как у вас), и это серьезный недостаток для целого ряда реальных задач (те-же виджеты) и возможных архитектур (гибридные изоморфные приложения). Главный минус веб-компонентов, это то, что в 2026-м году большинство разработчиков все еще не понимает что это такое.
Про гипер-базу - повторю, это частная задача, для которой существует стандартное платформенное решение - сервис воркеры. Да, в нашу экосистему не входит готовое решение, которое позволило бы включить оффлайн-режим простым флагом, но если оно действительно понадобится - не проблема добавить, это вообще не сложно.
В сухом остатке, у нас есть два противоположных друг-другу подхода.
Слабосвязанная архитектура, с опорой на стандарты, которая про максимальную гибкость (инверсия зависимостей через декларативные контракты и всякое такое) и устойчивость к изменениям
Cильно-связанная архитектура, которая про героическую борьбу с вашей мета-платформой при попытке сделать шаг вправо или в влево, но зато хорошо типы резолвятся в TypeScript и куча "магии" под капотом
Просто я - адепт именно первого варианта. Мне тесно в рамках, заданных кем-то, по непрозрачным для меня причинам. Второй подход тоже имеет место быть, и где-то он даже более уместен, тут я спорить не буду. Моя библиотека - отражает мои инженерные ценности, и они просто немного не совпадают с вашими, такое бывает.
Вы сами читали таблицу сравнения, которую приложили? Там же по всем пунктам, практически, проигрыш. Или для вас это все преимущества?
В текстовой части комментария я также не вижу особых преимуществ. JSDA-Kit еще легче засунуть в Tauri, нет никаких проблем ни с темами, ни с адаптивностью, ни с локализациями ни с бесплатным хостингом (об этом даже прямо написано в README).
Гипер-базы - нет, но не уверен что это решение уровня common purpose, скорее какая-то очень частная история. Мы юзаем обычный PostgreSQL и Indexed DB на клиенте, если нужно. Адаптер с поддержкой промисов - входит в состав пакета.
Спасибо за приглашение, но я ведь объяснил, почему выбрал стратегию "ПОСЛЕ". Не вижу смысла делать иной выбор. Почему? Я подробно объяснил тут: https://habr.com/ru/articles/1008822/ (см слабосвязанная архитектура)
Помимо этого, вы предлагаете мне бросить проект с +/- 60 000 еженедельных загрузок, ради чего-то с 1 500? Масштабы несопоставимы.
Кроме того, у нас есть такая экосистемная штука: https://github.com/rnd-pro/jsda-kit. Можно подставить $mol в таблицу сравнения вместо Next.js. Думаю картина особо не изменится.
Ну и, заходя на сайт $mol, первое, что я увидел - это русские тексты при включенном английском в интерфейсе. Это многое говорит о уровне проекта. + куча других странных моментов, от просто неаккуратностей до явных ошибок.
Вы пытаетесь переизобрести платформу, но мне такой подход не близок. Я - опираюсь на стандарты и все то, что хорошо задокументировано на MDN.
Если вы способны написать статью, которая осветит сразу все edge-кейсы - я вам очень завидую. Но боюсь, что это просто невозможно. Если у вас нет желания разбираться - значит оно вам не надо, тут я вам никак помочь не могу. Если вы опишите подробнее свою задачу и покажете пример кода на vue, куда нужно встроиться - я приведу вам пример оптимального кода на Symbiote.js (в разумных пределах). И да, я делал сложные виджеты для vue и строил очень сложные приложения полностью на Symbiote.js (редакторы, дэшборды с кучей живых данных и тд). AI-ref есть в репозитории по ссылке.
Никто ничего не мьютит, на клиенте изоморфный компонент читает декларации биндингов из HTML-атрибутов и привязывает к ним обработчики, оставляя пришедшие с сервера данные примитивных типов (например тексты, которые вы видите в UI) без изменений до первого явного обращения к ним. Прекращайте критиковать до того как сами разобрались как оно работает. Для того чтобы разобраться - все необходимые материалы я предоставил. Ваше желание - ваша проблема.
Пока я слабо понимаю, как ваши компоненты будут работать с реактивностью vue. Писать обертку?
А причем тут реактивность vue? У Симбиота своя реактивность. Шаблон симбиота - это просто HTML с атрибутами, вывод (чанк) для последующей гидрации - аналогично - просто HTML. Если этот HTML будет полностью сформирован на стороне vue - симбиот просто подцепит его при активации. Если вы создадите кусок HTML-документа через родной SSR симбиота - он, также, просто гидриуется на клиенте. Никакой обертки не нужно. Грубо говоря, в vue шаблоне могут быть кастомные теги, если они созданы с помощью Symbiote - они сами разберутся как себя вести. Посмотрите примеры и доки по ссылкам, там все довольно наглядно.
то в браузере все равно поймаем ошибку гидратации
Нет, никакой ошибки не будет. Обновление таймера (если это таймер) просто обновит значение прилетевшее с сервера, без каких-то дополнительных действий с вашей стороны. Если это просто статичное время (странный кейс для динамического обновления) - можно вызвать notify для поля стейта. Можно время вывести через client-only компонент, можно просто оставить серверное значение и ничего специально не делать. Ни в одном из этих случаев не будет никакой ошибки.
Как же вы задолбали... Это написано и отформатировано полностью вручную, я об этом даже соответствующий дисклеймер вставил. Даже картинка в шапке нарисована мной лично в Inkscape.
Я бы поспорил. На мой скромный взгляд, лучшие инженерные решения рождаются из пересечения компетенций, и в данном случае это именно фронт и бэк. Переносить какие-то паттерны и ментальные модели с фронта на бэк - не такая уж плохая идея, если вы знаете что делаете. И использование общей кодовой базы как и инструментов окружения - это ОЧЕНЬ ценный момент, чтобы от него просто отмахнуться. Помимо этого, бэк - это такая же сегментированная область, как и фронт и там и там вы можете встретить транзакции (как минимум IndexedDB) и большие данные летающие по вебсокетам в дэшбордах реального времени... как и генерацию статических ассетов на сервере, для которой не так важна максимальная оптимизация по IO. Развитие разработчика в сторону фуллстека - это никакая не ошибка, а самый правильный, на мой взгляд, путь для любого, кто хочет стать специалистом выше среднего.
Круто! Я использую подобный сетап для работы во время стоянок в мотопутешествиях. Только у меня очки Viture Pro (хочу новые Xreal 1S), вместо компа - Galaxy 25 Ultra с удаленным доступом к основному компу, и Starlink Mini для связи в дебрях. А вот с клавиатурой у меня полная беда, использую китайскую складную, которой, естественно очень далеко до вашей. Я называю всю эту движуху - Outdoor Programming.
Чувак, я вообще не знаю кто ты, и кто тебя обидел. Я никаких минусов тебе не ставил. Если людям нет дела - они спокойно проходят мимо, но тебе, почему-то, есть дело, ты решил отметиться и нахамить. Может ты меня с кем-то перепутал?
Не вижу никакого смысла, в очередной раз, ввязываться в срач с вами. Извините.
Я какбэ не пиарил сайт, и не давал на него ссылок, я пиарил либу. И это не я вам Cloudflare блокирую. Но спасибо за очередную порцию неадеквата.
В Symbiote тоже не нужно ничего руками дергать для обновления, причем контексты данных также просто и свободно создаются на уровне всего приложения (как на клиенте так и на сервере), а не только локально, как в других мейнстримных либах. И тоже нет Virtual DOM. Но я говорил немного о другом - о том, что от вас зависит то, насколько эффективно вы взаимодействуете с DOM, но вы в любом случае, неизбежно взаимодействуете. Нельзя заявлять что вы это исключили из формулы, даже если вынесли всю основную кухню по подготовке к обновлениям в отдельную абстракцию.
Про ограничения веб-компонентов - это все сплошные мифы и заблуждения.
Хостовый объект не обязательно должен быть приаттачен к документу. Вы можете создавать экземпляры полностью в памяти, если вам это нужно (как и любой DOM-элемент). Если работа с данными организоване на этапе конструктора - вы не получите никаких дополнительных затрат, связанных с DOM. Такими объектами легко манипулировать в рамках Document Fragment, и это работает очень быстро.
Значениями атрибутов могут быть строки, потому, что они именно HTML-атрибуты, т. е. по определению - это часть HTML. Но никто не мешает вам работать со свойствами и методами экземпляров, которые могут иметь любой тип. В значения атрибутов можно писать любые сериализуемые данные (объекты или массивы), причем, десериализованы они будут быстрее, чем если бы вы определяли их в js-коде. Да, при таком подходе вы не можете передать прямые ссылки, но их, повторю, вы можете свободно передавать напрямую в объект компонента через геттеры, сеттеры, собственные поля и методы. Тут ВООБЩЕ нет никакой проблемы.
Жизненный цикл компонента начинается на этапе конструктора а не аттача.
Перенос хостового элемента приводит к реакции на
disconnectedCAllbackиconnectedCallback, и вам никто не запрещает НЕ выполнять никакой лишней логики в этот момент. Просто установите флаг. Зато есть куча случаев, когда такая реакция, наоборот, необходима и у вас есть замечательная возможность это использовать.Конфликт имен между либами обычно решается примитивными префиксами. Его словить совсем НЕ легко, мне лично, пока не удавалось. Но да, скоуп имен - общий. В Symbiote.js эта проблема решена в двух основных местах: автоматическое резервирование имен при коллизиях (браузер выдает ошибку, вы можете ее обработать как вам нужно) и при автоматической генерации элементов списков. Ну и вы можете разрешить коллизии тупо наследованием в своем контролируемом рантайме и задать нужные префиксы вручную.
Удалить компонент нельзя, но зачем это делать? Браузер просто хранит ссылку на конструктор, она особо кушать не просит.
В теневом DOM стили не "отваливаются", а изолируются. У такого поведения есть конкретное прямое назначение: избавить поставщиков решений от тех-же коллизий и глюков со стилями, оставив возможность безопасной конфигурации через дизайн-апи-токены. И тут важны два нюанса: стили вовсе не нужно никуда копировать, давно есть такая штука как adopted StyleSheets (поддерживается из коробки в Symbiote.js), и, что более важно, вас ВООБЩЕ никто не заставляет использовать Shadow DOM. Веб-компоненты могут быть БЕЗ Shadow DOM и стилизоваться самыми консервативными методами.
Веб-компоненты кое что знают о реактивности через `attributeChangedCallback`. Но, конечно, это не полноценная реактивность. И веб-компоненты - это не UI-библиотека чтобы это знать, а часть DOM API. Но на их основе вы можете сделать свои полноценные реактивные компоненты. Symbiote.js именно это и делает.
К сожалению, я не в Питере. Я живу в Аргентине. Но пришел бы с удовольствием.
Я бы вообще большинство задач, которые требуют браузера отправлял в puppeteer, через тот-же MCP. На мой взгляд, это гораздо более надежный способ, очень уж много глюков с расширениями и собственными тулзами агентов.
На мой взгляд, нельзя сказать, что какая-либо абстракция над DOM (как ваша компонентная модель) может решить какие-то фундаментальные проблемы, связанные с DOM. Это такая же манипуляция как и у разработчиков React, которые утверждали, что Virtual DOM - быстрее реального. Это вранье в принципе, так как этап синхронизации с реальным DOM - неизбежен. Они замели проблему под ковер и долго строили свой маркетинг на этом, но "проблема" никуда не делась. Это просто обман. Как и их функциональные компоненты с хуками, которые тянут сайд-эффекты, но продаются под брендом "чистая функция". А еще обман то, что такие проблемы, которые они решают таким образом - вообще существует.
В вашем случае - похожая ситуация. Вы рассказываете про то, что ваша компонентная модель лучше чем нативная, но эффективно строить веб UI без обращения к DOM API - невозможно. А Custom Elements - это часть современного DOM API (они не прибиты к DOM, они и есть DOM). И они - единственный способ организовать независимый и гранулярный жизненный цикл компонентов в браузере. Во всех остальных случаях - вы управляете жизненным циклом снаружи (как у вас), и это серьезный недостаток для целого ряда реальных задач (те-же виджеты) и возможных архитектур (гибридные изоморфные приложения). Главный минус веб-компонентов, это то, что в 2026-м году большинство разработчиков все еще не понимает что это такое.
Про гипер-базу - повторю, это частная задача, для которой существует стандартное платформенное решение - сервис воркеры. Да, в нашу экосистему не входит готовое решение, которое позволило бы включить оффлайн-режим простым флагом, но если оно действительно понадобится - не проблема добавить, это вообще не сложно.
В сухом остатке, у нас есть два противоположных друг-другу подхода.
Слабосвязанная архитектура, с опорой на стандарты, которая про максимальную гибкость (инверсия зависимостей через декларативные контракты и всякое такое) и устойчивость к изменениям
Cильно-связанная архитектура, которая про героическую борьбу с вашей мета-платформой при попытке сделать шаг вправо или в влево, но зато хорошо типы резолвятся в TypeScript и куча "магии" под капотом
Просто я - адепт именно первого варианта. Мне тесно в рамках, заданных кем-то, по непрозрачным для меня причинам. Второй подход тоже имеет место быть, и где-то он даже более уместен, тут я спорить не буду. Моя библиотека - отражает мои инженерные ценности, и они просто немного не совпадают с вашими, такое бывает.
Вы сами читали таблицу сравнения, которую приложили? Там же по всем пунктам, практически, проигрыш. Или для вас это все преимущества?
В текстовой части комментария я также не вижу особых преимуществ. JSDA-Kit еще легче засунуть в Tauri, нет никаких проблем ни с темами, ни с адаптивностью, ни с локализациями ни с бесплатным хостингом (об этом даже прямо написано в README).
Гипер-базы - нет, но не уверен что это решение уровня common purpose, скорее какая-то очень частная история. Мы юзаем обычный PostgreSQL и Indexed DB на клиенте, если нужно. Адаптер с поддержкой промисов - входит в состав пакета.
Это вы так пошутили, да?
Почитайте про стандарт Custom Elements
Спасибо за приглашение, но я ведь объяснил, почему выбрал стратегию "ПОСЛЕ". Не вижу смысла делать иной выбор. Почему? Я подробно объяснил тут: https://habr.com/ru/articles/1008822/ (см слабосвязанная архитектура)
Помимо этого, вы предлагаете мне бросить проект с +/- 60 000 еженедельных загрузок, ради чего-то с 1 500? Масштабы несопоставимы.
Кроме того, у нас есть такая экосистемная штука: https://github.com/rnd-pro/jsda-kit. Можно подставить $mol в таблицу сравнения вместо Next.js. Думаю картина особо не изменится.
Ну и, заходя на сайт $mol, первое, что я увидел - это русские тексты при включенном английском в интерфейсе. Это многое говорит о уровне проекта. + куча других странных моментов, от просто неаккуратностей до явных ошибок.
Вы пытаетесь переизобрести платформу, но мне такой подход не близок. Я - опираюсь на стандарты и все то, что хорошо задокументировано на MDN.
Вы, всего лишь, делаете ложные утверждения. Про эмоции вы тоже все сами себе придумали.
Спасибо, с вами приятно поговорить.
Если вы способны написать статью, которая осветит сразу все edge-кейсы - я вам очень завидую. Но боюсь, что это просто невозможно. Если у вас нет желания разбираться - значит оно вам не надо, тут я вам никак помочь не могу. Если вы опишите подробнее свою задачу и покажете пример кода на vue, куда нужно встроиться - я приведу вам пример оптимального кода на Symbiote.js (в разумных пределах). И да, я делал сложные виджеты для vue и строил очень сложные приложения полностью на Symbiote.js (редакторы, дэшборды с кучей живых данных и тд). AI-ref есть в репозитории по ссылке.
Никто ничего не мьютит, на клиенте изоморфный компонент читает декларации биндингов из HTML-атрибутов и привязывает к ним обработчики, оставляя пришедшие с сервера данные примитивных типов (например тексты, которые вы видите в UI) без изменений до первого явного обращения к ним. Прекращайте критиковать до того как сами разобрались как оно работает. Для того чтобы разобраться - все необходимые материалы я предоставил. Ваше желание - ваша проблема.
А причем тут реактивность vue? У Симбиота своя реактивность. Шаблон симбиота - это просто HTML с атрибутами, вывод (чанк) для последующей гидрации - аналогично - просто HTML. Если этот HTML будет полностью сформирован на стороне vue - симбиот просто подцепит его при активации. Если вы создадите кусок HTML-документа через родной SSR симбиота - он, также, просто гидриуется на клиенте. Никакой обертки не нужно. Грубо говоря, в vue шаблоне могут быть кастомные теги, если они созданы с помощью Symbiote - они сами разберутся как себя вести. Посмотрите примеры и доки по ссылкам, там все довольно наглядно.
Нет, никакой ошибки не будет. Обновление таймера (если это таймер) просто обновит значение прилетевшее с сервера, без каких-то дополнительных действий с вашей стороны. Если это просто статичное время (странный кейс для динамического обновления) - можно вызвать notify для поля стейта. Можно время вывести через client-only компонент, можно просто оставить серверное значение и ничего специально не делать. Ни в одном из этих случаев не будет никакой ошибки.
Не уверен, что понял вас. Вы хотите пример Symbiote-компонента внутри Vue приложения?
Я и сам знаю как он "палится" - никак. Лечите свою нейро-паранойю.
Как же вы задолбали... Это написано и отформатировано полностью вручную, я об этом даже соответствующий дисклеймер вставил. Даже картинка в шапке нарисована мной лично в Inkscape.
Один раз видел такую на парковке в Москве. Подошел поближе посмотреть - а там все как-то не очень...
...лучше бы пил и курил...
Я бы поспорил. На мой скромный взгляд, лучшие инженерные решения рождаются из пересечения компетенций, и в данном случае это именно фронт и бэк. Переносить какие-то паттерны и ментальные модели с фронта на бэк - не такая уж плохая идея, если вы знаете что делаете. И использование общей кодовой базы как и инструментов окружения - это ОЧЕНЬ ценный момент, чтобы от него просто отмахнуться. Помимо этого, бэк - это такая же сегментированная область, как и фронт и там и там вы можете встретить транзакции (как минимум IndexedDB) и большие данные летающие по вебсокетам в дэшбордах реального времени... как и генерацию статических ассетов на сервере, для которой не так важна максимальная оптимизация по IO. Развитие разработчика в сторону фуллстека - это никакая не ошибка, а самый правильный, на мой взгляд, путь для любого, кто хочет стать специалистом выше среднего.