Хабр Курсы для фронтендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Фронтенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 23
Саму библиотеку обсуждать не берусь - не вижу ей практического применения. Но вот проблемы, описываемые в статье мне очень близки, как думаю и опенсорсерам.
Например, ИИ даже при полной передаче АПИ и документации непопулярной библиотеки все равно скатывается в "среднестатистический" код и усложняет на ровном месте, хотя из апи следует, что решение может быть намного элегантней и проще.
И хорошего варианта пока не видно. Можно, конечно, предоставлять 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 тоже не нужно ничего руками дергать для обновления, причем контексты данных также просто и свободно создаются на уровне всего приложения (как на клиенте так и на сервере), а не только локально, как в других мейнстримных либах. И тоже нет 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 именно это и делает.
К сожалению, я не в Питере. Я живу в Аргентине. Но пришел бы с удовольствием.
Всё по фактам, мне и ответить нечего)
Спасибо за хорошую дисскуссию
А мне вот есть чего: https://page.hyoo.ru/#!=w4f8dv_1kexfe
На мой взгляд, нельзя сказать, что какая-либо абстракция над DOM (как ваша компонентная модель) может решить какие-то фундаментальные проблемы, связанные с DOM.
Компонентная модель $mol не является абстракцией над DOM - это отдельная самодостаточная абстракция. И да, она действительно решает некоторые проблемы DOM за счёт его отсутствия, когда он не нужен (находится за пределами видимой области, временно скрыт или не требует визуализации вообще). Яркий пример: километровый иерархический список с кучей селектов в каждом пункте и разными источниками данных.
эффективно строить веб UI без обращения к DOM API - невозможно
Рендеринг на холсте и в 3d реализуются через совсем иные API.
Во всех остальных случаях - вы управляете жизненным циклом снаружи (как у вас), и это серьезный недостаток для целого ряда реальных задач (те-же виджеты) и возможных архитектур (гибридные изоморфные приложения).
Довольно странный тезис. В случае веб компонент жизненным циклом управляет браузер, а не я. В чём преимущество потери контроля - остаётся загадкой.
Ну а отсутствие серверного рендеринга теневого дома - тот ещё геморрой для изоморфных приложений. И только не надо рассказывать нам про его опциональность. Это такая же часть "современного DOM API", без которой смысла в веб-компонентах никакого нет, ибо это не более чем крайне не удобный и не практичный способ управления жизненным циклом компонент.
инверсия зависимостей через декларативные контракты и всякое такое
Не увидел у вас в доке ничего про инверсию зависимостей. Про инверсию контроля я даже не заикаюсь - вы просто не сможете подменить в поддереве реализацию кнопки, не переписав все компоненты, ибо за каждым именем компонента глобально и навсегда закрепляется одна единственная реализация.
Cильно-связанная архитектура, которая про героическую борьбу с вашей мета-платформой при попытке сделать шаг вправо или в влево
Не стоит разбрасываться терминами, в которых вы плаваете. То, что вы описываете далее - это сильное зацепление, которого у нас, разумеется, нет. Я бы даже сказал, что $mol - единственный фреймворк, где любой модуль легко собирается в полностью независимый бандл, и детально кастомизируется не только по стилям и поведению, но и по композиции.
но зато хорошо типы резолвятся в TypeScript и куча "магии" под капотом
Пренебрежительное отношение к типам в частности и контрактам вообще, выдаёт в вас незрелого технического специалиста, не имевшего опыта поддержки больших кодовых баз разными разработчиками. Вы правда именно такое впечатление хотите производить на коллег?
Ну а любая достаточно развитая технология неотличима от магии, если не читать доки, да.
в рамках, заданных кем-то, по непрозрачным для меня причинам
В нашей энциклопедии за 10 лет накопилось много материалов с подробным объяснением и причин, и альтернатив. Конкретно по веб-компонентам отдельного анализа нет, правда. Надо будет добавить, а то вижу до сих пор находятся люди, верящие в жизнеспособность этого апи.
На картинке много бреда. Зачем вводить людей в заблуждение нейрослопом?
в $mol используются те же стандарты
Более того, любой $mol компонент легко регистрируется в качестве web компонента, используя бридж $mol_view_component.
я предлагаю бросить силы туда, где они принесут куда больший куммулятивный эффект
Нет смысла предлагать человеку бросить путь, которому тот посвятил несколько лет жизни. Он никогда его не бросит, даже если тот ведёт в тупик.
суём в tauri для полной кроссплатформы
Это касается любых веб-технологий, не только $mol.
Гипер база
Она хоть и написана на $mol, но отношения к нему не имеет.
хостинг бесплатен, так как у нас "обычный" сайт
Он не бесплатен, просто за него платит сообщество.
проект с +/- 60 000 еженедельных загрузок, ради чего-то с 1 500?
У нас нет понятия "загрузок". Хз, откуда вы взяли этих попугаев. Но если именно на этот KPI вы ориентируетесь, то как CTO вы профнепригодны. Пытаться пускать пыль в глаза - удел маркетологов, а не технических специалистов.
Кроме того, у нас есть такая экосистемная штука: https://github.com/rnd-pro/jsda-kit. Можно подставить $mol в таблицу сравнения вместо Next.js.
Ближайший (но всё ещё далёкий) аналог у нас - это MAM, а не $mol. $mol - широкий набор библиотек, лишь одна из которых ($mol_view) занимается рендерингом компонент.
русские тексты при включенном английском в интерфейсе. Это многое говорит о уровне проекта
И что же отсутствие толпы переводчиков на все языки мира у оупенсорс проекта говорит о его техническом уровне?
куча других странных моментов, от просто неаккуратностей до явных ошибок.
О чём речь? Ну ладно, давайте я лучше про косяки вашего сайта расскажу, раз уж ваша статья про серьёзные проблемы. Вот сделали вы SSR, чтобы быстро показывать нерабочую страничку, пока не прогрузятся скрипты. Но ради бесячего "эффекта тормозного терминала" выключаете изначально свет. В результате, невозможно ничего прочитать.
Надо ли говорить, что в России, где живёт подавляющее большинство аудитории, на которую вы пиарите сейчас свою либу, ваш сайт вообще не загрузится без VPN?
Про изменение размеров компонент по мере инициализации скриптов я даже не заикаюсь.
Я какбэ не пиарил сайт, и не давал на него ссылок, я пиарил либу. И это не я вам Cloudflare блокирую. Но спасибо за очередную порцию неадеквата.
Надо ли говорить, что в России, где живёт подавляющее большинство аудитории, на которую вы сейчас пиарите свою либу, ваш сайт вообще не загрузится в большинстве мест через мобильный интернет?
Очень много пафоса для библиотеки, до которой никому нет дела. Из поста в пост те, кому не лень, пишут одни и те же аргументы, почему им это не нравится.
Из поста в пост автор на любую критику раздается пространными рассуждениями ни о чем и жалко ставит минусы к комментариям.
Помрет дед Максим, да и хер с ним.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
У Symbiote.js — серьезные проблемы