На мой взгляд, нельзя сказать, что какая-либо абстракция над DOM (как ваша компонентная модель) может решить какие-то фундаментальные проблемы, связанные с DOM.
Компонентная модель $mol не является абстракцией над DOM - это отдельная самодостаточная абстракция. И да, она действительно решает некоторые проблемы DOM за счёт его отсутствия, когда он не нужен (находится за пределами видимой области, временно скрыт или не требует визуализации вообще). Яркий пример: километровый иерархический список с кучей селектов в каждом пункте и разными источниками данных.
эффективно строить веб UI без обращения к DOM API - невозможно
Рендеринг на холсте и в 3d реализуются через совсем иные API.
Во всех остальных случаях - вы управляете жизненным циклом снаружи (как у вас), и это серьезный недостаток для целого ряда реальных задач (те-же виджеты) и возможных архитектур (гибридные изоморфные приложения).
Довольно странный тезис. В случае веб компонент жизненным циклом управляет браузер, а не я. В чём преимущество потери контроля - остаётся загадкой.
Ну а отсутствие серверного рендеринга теневого дома - тот ещё геморрой для изоморфных приложений. И только не надо рассказывать нам про его опциональность. Это такая же часть "современного DOM API", без которой смысла в веб-компонентах никакого нет, ибо это не более чем крайне не удобный и не практичный способ управления жизненным циклом компонент.
инверсия зависимостей через декларативные контракты и всякое такое
Не увидел у вас в доке ничего про инверсию зависимостей. Про инверсию контроля я даже не заикаюсь - вы просто не сможете подменить в поддереве реализацию кнопки, не переписав все компоненты, ибо за каждым именем компонента глобально и навсегда закрепляется одна единственная реализация.
Cильно-связанная архитектура, которая про героическую борьбу с вашей мета-платформой при попытке сделать шаг вправо или в влево
Не стоит разбрасываться терминами, в которых вы плаваете. То, что вы описываете далее - это сильное зацепление, которого у нас, разумеется, нет. Я бы даже сказал, что $mol - единственный фреймворк, где любой модуль легко собирается в полностью независимый бандл, и детально кастомизируется не только по стилям и поведению, но и по композиции.
но зато хорошо типы резолвятся в TypeScript и куча "магии" под капотом
Пренебрежительное отношение к типам в частности и контрактам вообще, выдаёт в вас незрелого технического специалиста, не имевшего опыта поддержки больших кодовых баз разными разработчиками. Вы правда именно такое впечатление хотите производить на коллег?
Ну а любая достаточно развитая технология неотличима от магии, если не читать доки, да.
в рамках, заданных кем-то, по непрозрачным для меня причинам
В нашей энциклопедии за 10 лет накопилось много материалов с подробным объяснением и причин, и альтернатив. Конкретно по веб-компонентам отдельного анализа нет, правда. Надо будет добавить, а то вижу до сих пор находятся люди, верящие в жизнеспособность этого апи.
проект с +/- 60 000 еженедельных загрузок, ради чего-то с 1 500?
У нас нет понятия "загрузок". Хз, откуда вы взяли этих попугаев. Но если именно на этот KPI вы ориентируетесь, то как CTO вы профнепригодны. Пытаться пускать пыль в глаза - удел маркетологов, а не технических специалистов.
Кроме того, у нас есть такая экосистемная штука: https://github.com/rnd-pro/jsda-kit. Можно подставить $mol в таблицу сравнения вместо Next.js.
Ближайший (но всё ещё далёкий) аналог у нас - это MAM, а не $mol. $mol - широкий набор библиотек, лишь одна из которых ($mol_view) занимается рендерингом компонент.
русские тексты при включенном английском в интерфейсе. Это многое говорит о уровне проекта
И что же отсутствие толпы переводчиков на все языки мира у оупенсорс проекта говорит о его техническом уровне?
куча других странных моментов, от просто неаккуратностей до явных ошибок.
О чём речь? Ну ладно, давайте я лучше про косяки вашего сайта расскажу, раз уж ваша статья про серьёзные проблемы. Вот сделали вы SSR, чтобы быстро показывать нерабочую страничку, пока не прогрузятся скрипты. Но ради бесячего "эффекта тормозного терминала" выключаете изначально свет. В результате, невозможно ничего прочитать.
Надо ли говорить, что в России, где живёт подавляющее большинство аудитории, на которую вы пиарите сейчас свою либу, ваш сайт вообще не загрузится без VPN?
Про изменение размеров компонент по мере инициализации скриптов я даже не заикаюсь.
Ну вот набрали вы команду копирайтеров, пролистнули у них перед глазами чертежами всех самолётов, дали им задание на разработку вертолёта, и ждёте, что полученная вундервафля полетит.
Это не спасает, ибо при конфликте имён будет падение. Поэтому при конкатенации регулярок в любом случае нужно переименовывать группы. С позиционными группами тут даже немного проще.
Поэтому нужно не регулярки развивать, а добавить удобное апи для описания регулярных парсеров, как тут. Побочный эффект такого апи - возможность не только компоновать, парсить и валидировать, но и генерировать строки, гарантированно соответствующие синтаксису.
и как обычно это не правильно решение. А правильно - локально сохранять заявку на перевод, которая не потеряется при перезагрузке приложения, и автоматически ретраить ее доставку, пока она не дойдет до сервера.
Вот вам навскидку пища для размышлений касательно попсовых теорий и реального наблюдаемых явлений:
https://youtu.be/Yh3StOAutgk - про скорость света
https://www.youtube.com/watch?v=NKxAO1WA0aI - про наблюдения в астрономии
https://www.lppfusion.com/science/cosmic-connection/plasma-cosmology/the-growing-case-against-the-big-bang/ - про большой взрыв
https://youtu.be/tJCKfZkcE1k - про теорию, которая объясняет эффекты без парадоксов
Ага, и
придумалскопирайтил теорию со встроенными парадоксами, которые какими только тёмными сущностями не латали, а всё бестолку.Компонентная модель $mol не является абстракцией над DOM - это отдельная самодостаточная абстракция. И да, она действительно решает некоторые проблемы DOM за счёт его отсутствия, когда он не нужен (находится за пределами видимой области, временно скрыт или не требует визуализации вообще). Яркий пример: километровый иерархический список с кучей селектов в каждом пункте и разными источниками данных.
Рендеринг на холсте и в 3d реализуются через совсем иные API.
Довольно странный тезис. В случае веб компонент жизненным циклом управляет браузер, а не я. В чём преимущество потери контроля - остаётся загадкой.
Ну а отсутствие серверного рендеринга теневого дома - тот ещё геморрой для изоморфных приложений. И только не надо рассказывать нам про его опциональность. Это такая же часть "современного DOM API", без которой смысла в веб-компонентах никакого нет, ибо это не более чем крайне не удобный и не практичный способ управления жизненным циклом компонент.
Не увидел у вас в доке ничего про инверсию зависимостей. Про инверсию контроля я даже не заикаюсь - вы просто не сможете подменить в поддереве реализацию кнопки, не переписав все компоненты, ибо за каждым именем компонента глобально и навсегда закрепляется одна единственная реализация.
Не стоит разбрасываться терминами, в которых вы плаваете. То, что вы описываете далее - это сильное зацепление, которого у нас, разумеется, нет. Я бы даже сказал, что $mol - единственный фреймворк, где любой модуль легко собирается в полностью независимый бандл, и детально кастомизируется не только по стилям и поведению, но и по композиции.
Пренебрежительное отношение к типам в частности и контрактам вообще, выдаёт в вас незрелого технического специалиста, не имевшего опыта поддержки больших кодовых баз разными разработчиками. Вы правда именно такое впечатление хотите производить на коллег?
Ну а любая достаточно развитая технология неотличима от магии, если не читать доки, да.
В нашей энциклопедии за 10 лет накопилось много материалов с подробным объяснением и причин, и альтернатив. Конкретно по веб-компонентам отдельного анализа нет, правда. Надо будет добавить, а то вижу до сих пор находятся люди, верящие в жизнеспособность этого апи.
На картинке много бреда. Зачем вводить людей в заблуждение нейрослопом?
Более того, любой $mol компонент легко регистрируется в качестве web компонента, используя бридж $mol_view_component.
Нет смысла предлагать человеку бросить путь, которому тот посвятил несколько лет жизни. Он никогда его не бросит, даже если тот ведёт в тупик.
Это касается любых веб-технологий, не только $mol.
Она хоть и написана на $mol, но отношения к нему не имеет.
Он не бесплатен, просто за него платит сообщество.
У нас нет понятия "загрузок". Хз, откуда вы взяли этих попугаев. Но если именно на этот KPI вы ориентируетесь, то как CTO вы профнепригодны. Пытаться пускать пыль в глаза - удел маркетологов, а не технических специалистов.
Ближайший (но всё ещё далёкий) аналог у нас - это MAM, а не $mol. $mol - широкий набор библиотек, лишь одна из которых ($mol_view) занимается рендерингом компонент.
И что же отсутствие толпы переводчиков на все языки мира у оупенсорс проекта говорит о его техническом уровне?
О чём речь? Ну ладно, давайте я лучше про косяки вашего сайта расскажу, раз уж ваша статья про серьёзные проблемы. Вот сделали вы SSR, чтобы быстро показывать нерабочую страничку, пока не прогрузятся скрипты. Но ради бесячего "эффекта тормозного терминала" выключаете изначально свет. В результате, невозможно ничего прочитать.
Надо ли говорить, что в России, где живёт подавляющее большинство аудитории, на которую вы пиарите сейчас свою либу, ваш сайт вообще не загрузится без VPN?
Про изменение размеров компонент по мере инициализации скриптов я даже не заикаюсь.
Пфф, вот вам кшок-контент: https://www.youtube.com/shorts/Q0FXGRB8U0c?feature=share
https://ru.wikipedia.org/wiki/Язык_спецификаций
Не берут. Джуны и так никому не нужны. А тупые тем более.
Но она не пройдёт формальную верификацию.
Не работает. Копирайтера никто не возьмёт на должность инженера даже если у него есть 20 лет опыта копирайтинга чертежей.
...если под полнотой понимать возможность написания чуши.
Ну вот набрали вы команду копирайтеров, пролистнули у них перед глазами чертежами всех самолётов, дали им задание на разработку вертолёта, и ждёте, что полученная вундервафля полетит.
Это не спасает, ибо при конфликте имён будет падение. Поэтому при конкатенации регулярок в любом случае нужно переименовывать группы. С позиционными группами тут даже немного проще.
Поэтому нужно не регулярки развивать, а добавить удобное апи для описания регулярных парсеров, как тут. Побочный эффект такого апи - возможность не только компоновать, парсить и валидировать, но и генерировать строки, гарантированно соответствующие синтаксису.
Не понятно с чего вы взяли, что изменения DOM хоть как то влияют на события, которые уже находятся в очереди JS на обработку.
С такой удачей лучше купить партию лотерейных билетов.
А чтобы создать ключ операции нам нужно иметь ключ операции создания ключа операции…
и как обычно это не правильно решение. А правильно - локально сохранять заявку на перевод, которая не потеряется при перезагрузке приложения, и автоматически ретраить ее доставку, пока она не дойдет до сервера.
Ну и что же не так с этими терминами?