Comments 12
Саму библиотеку обсуждать не берусь - не вижу ей практического применения. Но вот проблемы, описываемые в статье мне очень близки, как думаю и опенсорсерам.
Например, ИИ даже при полной передаче АПИ и документации непопулярной библиотеки все равно скатывается в "среднестатистический" код и усложняет на ровном месте, хотя из апи следует, что решение может быть намного элегантней и проще.
И хорошего варианта пока не видно. Можно, конечно, предоставлять skills - но это очень ненадежный и часто игнорируемый моделями файл, тем более что для всего зоопарка моделей и их весов и других характеристик не получится сделать стабильно. Даже если автоматизировать в CI промпт "напиши на Symbiote с нуля сайт вот с таким функционалом" и давать десятку разных агентов - результат будет всегда разным, это очень сложно проверить.
А ждать, пока конкретная библиотека "завирусится" и будет настолько широко использоваться, что перебьет веса других либ - очевидно, совершенно нерабочая схема. MCP же только для энтузиастов, его всегда надо использовать осторожно - очень большие риски для безопасности, и точно не для массового потребителя.
По сложности работы с Custom Elements и расхождению типов и рантайма тоже распространенная проблема, я вот стараюсь избегать всех технологий, которые к этому приводят.
а присоединяйтес к нам в $mol коммьюнити, у нас как раз привязка данных "ДО" создания html
а базовый компонент вообще выглядит вот так
$mycomponent $mol_viewпри этом этот компонент может быть вообще любым html элементом, даже придуманным по типу "article"
$mol это по сути максимально прокачанные веб компоненты, там под капотом очень много грамотных технических решений, крайне рекомендую
даже придуманным по типу "article"
Тут вроде как именно с "придуманными" и собираются работать, и все танцы ради них.
У нас и то и то одинаково хорошо работает 😄
Почитайте про стандарт Custom Elements
Спасибо за приглашение, но я ведь объяснил, почему выбрал стратегию "ПОСЛЕ". Не вижу смысла делать иной выбор. Почему? Я подробно объяснил тут: https://habr.com/ru/articles/1008822/ (см слабосвязанная архитектура)
Помимо этого, вы предлагаете мне бросить проект с +/- 60 000 еженедельных загрузок, ради чего-то с 1 500? Масштабы несопоставимы.
Кроме того, у нас есть такая экосистемная штука: https://github.com/rnd-pro/jsda-kit. Можно подставить $mol в таблицу сравнения вместо Next.js. Думаю картина особо не изменится.
Ну и, заходя на сайт $mol, первое, что я увидел - это русские тексты при включенном английском в интерфейсе. Это многое говорит о уровне проекта. + куча других странных моментов, от просто неаккуратностей до явных ошибок.
Вы пытаетесь переизобрести платформу, но мне такой подход не близок. Я - опираюсь на стандарты и все то, что хорошо задокументировано на MDN.
довольно большие отличия, в том числе от next
в $mol используются те же стандарты
я предлагаю бросить силы туда, где они принесут куда больший куммулятивный эффект
в $mol слишком много плюсов что бы его игнорировать
он даёт:
• одно приложение сразу для Web / Windows / macOS / Linux / Android / iOS + WebExtension ( тут оговорка что суём в tauri для полной кроссплатформы )
• работает офлайн ( любое написанное приложение, за 1 доп-строчку кода )
• локализацию из коробки
• адаптивность из коробки
• сss in ts
• темизация из коробки
• Гипер база при появлении сети, синхронизирует данные автоматически, без конфликтов
• сервер не нужен - не нужно поднимать БД, не нужно хранить бэкапы так как все данные у клиентов, авторизация происходит мгновенно при первой загрузке сайта
• состояния хранятся локально + синкаются через гипер-базу
• строгая типизация, real-time sync, end-to-end шифрование
• хостинг бесплатен, так как у нас "обычный" сайт
Вы сами читали таблицу сравнения, которую приложили? Там же по всем пунктам, практически, проигрыш. Или для вас это все преимущества?
В текстовой части комментария я также не вижу особых преимуществ. JSDA-Kit еще легче засунуть в Tauri, нет никаких проблем ни с темами, ни с адаптивностью, ни с локализациями ни с бесплатным хостингом (об этом даже прямо написано в README).
Гипер-базы - нет, но не уверен что это решение уровня common purpose, скорее какая-то очень частная история. Мы юзаем обычный PostgreSQL и Indexed DB на клиенте, если нужно. Адаптер с поддержкой промисов - входит в состав пакета.
в $mol используются те же стандарты
Это вы так пошутили, да?
Читал, плюсов вижу больше чем минусов
Дело в том что в $mol это всё уже под капотом сделано и можно не тратить на это время а просто собирать интерфейс
Сколько строк нужно написать что бы ваше приложение могло полностью работать офлайн ? Для любого $mol приложения это 1 строка, не для компонента, для приложения
Про стандарты я имею ввиду немножко другое. Да в моле своя компонентная модель. Но она работает лучше чем веб компоненты за счёт грамотных архитектурных решений
Это похоже на "прокачанные веб компоненты" но да, вне экосистемы мола она не будут работать
Зато мы не получаем минусов веб компонентов, которые гвоздями прибиты к dom
Ещё добавлю про гипер базу. С ней вам не нужен бэкенд. Достаточно описать модели на клиенте и база сама всё синхронизирует, без конфликтов и потерь данных, так как под капотом используется crdt типы.
Так же база защищена с помощью криптографии, это позволяет индефицировать пользователя по ключам, регистрация не прос то в 1 клик, регистрация буквально происходит при открытии сайта.
И для защиты от флуда/Форда используется Prof of work, на криптографии.
В общем, это не далеко не то же самое что indexdb или postgres
На мой взгляд, нельзя сказать, что какая-либо абстракция над DOM (как ваша компонентная модель) может решить какие-то фундаментальные проблемы, связанные с DOM. Это такая же манипуляция как и у разработчиков React, которые утверждали, что Virtual DOM - быстрее реального. Это вранье в принципе, так как этап синхронизации с реальным DOM - неизбежен. Они замели проблему под ковер и долго строили свой маркетинг на этом, но "проблема" никуда не делась. Это просто обман. Как и их функциональные компоненты с хуками, которые тянут сайд-эффекты, но продаются под брендом "чистая функция". А еще обман то, что такие проблемы, которые они решают таким образом - вообще существует.
В вашем случае - похожая ситуация. Вы рассказываете про то, что ваша компонентная модель лучше чем нативная, но эффективно строить веб UI без обращения к DOM API - невозможно. А Custom Elements - это часть современного DOM API (они не прибиты к DOM, они и есть DOM). И они - единственный способ организовать независимый и гранулярный жизненный цикл компонентов в браузере. Во всех остальных случаях - вы управляете жизненным циклом снаружи (как у вас), и это серьезный недостаток для целого ряда реальных задач (те-же виджеты) и возможных архитектур (гибридные изоморфные приложения). Главный минус веб-компонентов, это то, что в 2026-м году большинство разработчиков все еще не понимает что это такое.
Про гипер-базу - повторю, это частная задача, для которой существует стандартное платформенное решение - сервис воркеры. Да, в нашу экосистему не входит готовое решение, которое позволило бы включить оффлайн-режим простым флагом, но если оно действительно понадобится - не проблема добавить, это вообще не сложно.
В сухом остатке, у нас есть два противоположных друг-другу подхода.
Слабосвязанная архитектура, с опорой на стандарты, которая про максимальную гибкость (инверсия зависимостей через декларативные контракты и всякое такое) и устойчивость к изменениям
Cильно-связанная архитектура, которая про героическую борьбу с вашей мета-платформой при попытке сделать шаг вправо или в влево, но зато хорошо типы резолвятся в TypeScript и куча "магии" под капотом
Просто я - адепт именно первого варианта. Мне тесно в рамках, заданных кем-то, по непрозрачным для меня причинам. Второй подход тоже имеет место быть, и где-то он даже более уместен, тут я спорить не буду. Моя библиотека - отражает мои инженерные ценности, и они просто немного не совпадают с вашими, такое бывает.
ну, в моле нету virtual dom, там напрямую меняется
так же не нужно руками что то дергать что бы интерфейс обновился, мол сам узнаёт через автоматический граф зависисмостей, перевычесляется при этом только то что изменилось
по поводу ограничений веб компонентов
Хостовой объект, приаттаченый к документу - это крайне медленно. И JIT компилятор тут ничем помочь не может.
Значениями атрибутов могут быть лишь строки .
Жизненный цикл компонента начинается лишь в момент аттача хостового элемента.
Перенос хостового элемента приводит к реаттачу всего поддерева компонент.
Легко словить конфликт имён компонент между разными либами. И механизмов разрешения этого конфликта нет.
Единожды зарегистрированный компонент уже нельзя удалить.
В теневом доме отваливаются все стили - их надо копипастить в каждый теневой дом отдельно.
Веб компоненты ничего не знают про пулл реактивность.
скопировал отсюда https://habr.com/ru/articles/968384/comments/#comment_29145688
гипер база это не просто "сервис воркер + флаг". Это CRDT база которая синхронизирует сама, с end-to-end шифрованием и криптографической авторизацией. с ней не нужен сервер для 95% приложений
пример приложения https://b-on-g.github.io/blitz/
понимаю идею вашего подхода и почему вам он заходит
но у этого есть цена - больше бойлерплейта и инфраструктурного кода
в моле нет ни того ни другого, отчего кода получается меньше чем у конкурентов. в целом мне нравиться как там всё продумано
про виджеты да, тут веб компоненты топ, но как будто узкий кейс не частый
Моя библиотека - отражает мои инженерные ценности, и они просто немного не совпадают с вашими, такое бывает.
и это абсолютно нормально, пожал бы вам руку лично
а если вдруг в питере, приходите на @piterjs ( в тг точно так же пишется )
и руки пожмем и пообщаемся) там много крутых ребят
У Symbiote.js — серьезные проблемы