Comments 105
Вы забыли оставить ссылку на статью, на которую написали свою реакцию, чтобы она не выглядела, как диалог с воображаемым другом: https://habr.com/ru/articles/1014708/
"бифы" программистов это весело :)
Поддержу-ка я автора, ссылаемая здесь статья откровенно глупая.
Что не так с веб-компонентами?
Если кратко - да все с ними ТАК. Это замечательный набор современных браузерных технологий, для решения реальных задач веб-разработки. Веб-компоненты позволяют делать очень многое, более просто и элегантно, чем это было бы без них. А главное, они позволяют, с потрясающей гибкостью, решать задачи “со звездочкой” - те, которые немного выходят за рамки и требуют более творческого подхода от разработчика.
А что Вы можете сказать начинающему разработчику, который только хочет изучить Ваши веб-компоненты?
Во-первых, можете ли Вы перечислить их; назвать их сильные и слабые стороны, а также обрисовать в целом наиболее подходящий их изучения/овладения?
Во-вторых, можете ли Вы привести сравнительные примеры того, как одни и те же задачи решаются без применения веб-компонентов и с применением веб-компонентов.
И, конечно же, в-третьих, можете ли Вы объяснить, почему, вообще, возникают эти самые задачи "со звёздочкой"? (Кстати! А что это за задачи?)
Боюсь, чтобы полноценно ответить на ваш комментарий нужно целую отдельную статью написать. Поэтому простите, но пройдусь кратко:
Начинающему разработчику я посоветую почитать доки, и написать пару компонентов самому, чтобы получить базовое представление. Можно попросить ИИ помочь, он все подробно объяснит и посоветует куда дальше двигаться.
Про сильные стороны - я написал в статье. Эти три пункта - и есть то, ради чего стоит в эту тему вникать. Образно говоря, веб-компоненты - это клей, который склеивает HTML, JS, CSS в тех точках вашего приложения, где вам это нужно. Причем, как на клиенте, так и на сервере, как в пространстве (положение в DOM), так и во времени (контроль жизненного цикла). Без них, такая задача как, например, SSR - становится на порядок сложнее.
Простой пример задачи со звездочкой - это виджеты. Представьте, что вы создаете сервис, позволяющий вставить чат, прием оплаты или загрузку пользовательских файлов на любой сайт. Сайты ваших клиентов могут быть реализованы на чем угодно - любом фреймворке, CMS, серверном шаблонизаторе... С любым пайплайном сборки, с любыми "подводными камнями", которые только можно и нельзя придумать. Так вот, веб-компоненты - это, практически, единственный способ создать такое решение с минимальным количеством боли и без необходимости писать отдельные обертки и адаптеры под весь этот всевозможный зоопарк. И даже если вы будете писать эти адаптеры - это будет сделать на порядок проще, если внутри будет общее универсальное решение, поддерживаемое по умолчанию, на уровне стандартов самой платформы.
Вот вам задача с двумя звёздочками: встраиваете вы к себе этот прекрасный сторонний чат, но понимаете, что вместо кнопки "отправить" вам нужен селект из двух вариантов "отправить сейчас" и "отправить позже", а рядом с ним нужен флаг "отправить тихо", а при наведении на имя пользователя нужно показывать всплывашку со статистикой активности на вашем сайте, да и вообще имя пользователя должно быть разного цвета, в зависимости от ролевой модели вашего сайта. Но как на зло, автор чата даже подумать не мог, что вам потребуются такие кастомизации, поэтому не подстелил где-надо slot, где надо part. Расскажите же, про потрясающую гибкость веб-компонент в решении этой задачи.
С удовольствием расскажу. В отдельной статье.
Делается очень просто, если компонент нормально отправляет события, и чуть сложнее, если нет.
Именно потому, что ты вообще не понимаешь и не принимаешь ничего кроме своего, ты и не можешь разобраться, как работать с веб-компонентами. Тебе куча народа это уже говорила, но, как говорится - "а еслим читан, то не понят, а если понят - то не так".
Во-вторых, можете ли Вы привести сравнительные примеры того, как одни и те же задачи решаются без применения веб-компонентов и с применением веб-компонентов.
Если бы с ними все было так, их бы использовали. Безотносительно наличия хейтерских или фанбойских статей. 15 лет уже технологии скоро будет.
Ну да, ну да, конечно, никто не пользуется. У Lit - двукратный рост по загрузкам в npm за год, у Symbiote.js - трехкратный. GitHub, YouTube, Microsoft, IBM и даже SpaceX - это совсем-совсем никто.
Да, да. Я тоже руководствовался громкими именами когда повелся на этот хайп в свое время. В реальности оно крутится под капотом у полутора землекопов, и то потому что зачем то взяли, а теперь выпилить не могут.
Ангуляром тоже пользуются и Гугл ?который его и "поддерживает") и некоторые громкие имена из Легаси банкинга в рф, но хорошим фреймворком он от этого не стал
Я вам больше скажу, даже React - лидеру всех на свете рейтингов по использованию, ОЧЕНЬ далеко до звания "хорошего", в техническом плане. Поэтому "пусть расцветают сто цветов". А те, кому надо, выберут то, что им надо.
То есть не веб компоненты
Лишняя абстракция же просто, что в б2б что в б2с совсем другие проблемы, веб компоненты их никак не решают
Веб-компоненты - это неотъемлемая часть современного DOM API, называть это лишней абстракцией, при том, что все остальное (фреймворки) - это и есть абстракции над DOM - крайне странно. Вы путаете курицу с яйцом.
Про то, какие проблемы они решают - буквально написано и в статье и в комментах. Если никогда не выходить за рамки одной мета-платформы, вы может никогда и не встретите таких задач. Веб-компоненты нужны, прежде всего, для тех, кто с такими задачами сталкивается.
https://github.com/rnd-pro/jsda-kit?tab=readme-ov-file#jsda-kit-vs-nextjs - вот тут становится все более очевидно.
Единственное решение реальных проблем это изоляция с shadow dom, но и она не работает из коробки, как тот же iframe, и тем более не сработает в принципе с 3rd party которые на этих компонентах не написаны
У реальных приложений в вебе вообще другого рода проблемы, компоненты их никак не решают
Dx тоже сомнительный
Ок, хорошо. У вас Shadow DOM не работает, у меня - работает. У вас - компоненты проблем не решают, у меня - решают. Как минимум, половине из нас двоих, веб-компоненты - нужны.
Вот только не надо рассказывать нам про "реальные" приложения таким тоном, как будто вы в этом лучше разбираетесь. У вас нет никаких оснований для этого. Вы можете поделиться собственным опытом, но не говорите за всех.
Мы мигрировали на Lit год назад - это было лучшее решение. И более приятного DX я в жизни не имел.
Чтобы не быть голословным, я когда-то очень ими интересовался и успел поработать на продакшене с Polymer и Lit. До сих пор иногда пишу небольшие компоненты без фреймворков, чтобы по быстрому вставить в какую-нибудь древность. За красивыми словами про глобальные стандарты (как будто кому то не пофиг), нативность против ненативности (как будто кому то не пофиг) в реальности это полное говно уровня чуть выше бэкбона с точки зрения DX.
Можно просто открыть доку к любой либе поверх них, включая либу многоуважаемого автора, посмотреть какое это убогое говно и закрыть.
Начинающим разработчикам рекомендую не тратить на них много времени, ознакомиться и просто иметь в виду, что оно вообще есть.
Уже второй раз вы приходите в комменты к моим статьям чисто нахамить, на ровном месте, без внятных аргументов. По существу есть что сказать?
Ты возможно что-то перепутал, но я напомню что ты публикуешься на открытом ресурсе.
В эпоху агентской разработки побеждает тот, на ком натренирована максимально обширная и качественная кодовая база. Я (речь про фронтенд) уже больше половины кода вообще не пишу, а ревьюю и правлю. А кто-то по слухам не уже пишет совсем.
Если ты не используешь нейронки для разработки, про работу можешь забыть уже сейчас. Если ты используешь нейронки, чтобы генерить приложения из подобного шлака - аналогично. Если кто-то до сих пор не понял, что руками больше писать не надо, то очень скоро он это поймет через рынок.
Какой у тебя там красивый стандарт лежит в основе всем глубоко насрать, так как людям нужны разработчики, которые могут делать просто быстро, качественно и поддерживаемо. И это правильно.
Вот это аргумент, поддерживаю! О бедных вайбкодерах забыли подумать. Не хочу тебя пугать, но нейросети становятся умнее, и сами скоро будут выбирать более легковесные технологии. А вот ты - умнее явно не становишься.
Впрочем, не вижу больше смысла в препираниях на таком уровне, дальше - игнор.
какие нейронки? ChatGPT не может элементарнейший конфиг для Postfix написать не наделав кучу детских ошибок.
которые могут делать просто быстро, качественно и поддерживаемо
Золотые слова, но что они делают в контексте вайбкодинга?
Начну с самой жести - откровенного вранья, манипуляций и подтасовок.
Нам рассказывают про то, что в веб-компоненты можно передавать свойства ТОЛЬКО с типом “строка”
... но ведь HTML-атрибуты (которые вы дальше по тексту разбираете) действительно передаются через коллбэк в виде строк, вы попросту не сможете это опровергнуть, ибо это правда. Ну, и в принципе element.getAttribute() всегда строковый. Пришлось отложить чтение статьи, так как опровергается очевидно и заведомо правильный тезис, лол.
Мне кажется, тот абзац надо переписать яснее, ибо я его так и не понял.
Ну куда уж проще: атрибуты - это атрибуты (текст). Свойства класса - это поля объекта (в JS). Не нужно путать атрибуты со свойствами. Не нужно утверждать, что атрибуты - это единственный способ передать параметр. Все нормальные библиотеки, основанные на веб-компонентах, передают данные в js-рантайме, никто не использует парсинг JSON из атрибутов, если это не требуется специально для чего-то.
Комментарий не для автора, а для начинающих фронтенд-разработчиков. Не начинающие уже и так либо все знают, либо уволены. Если вы хотите работать, не выбирайте эту херь с веб-компонентами. Этот путь - он тупиковый. Автор в свое время поставил не на ту лошадку, а теперь, когда пушной зверек уже пришел, фрустрирует по статье в неделю.
Как реально работает сейчас фронтенд-разработка:
Строятся хорошо формализованные требования к дизайну, создается достаточно гибкий юайкит. Дизайнеры, которые до сих пор путают фигму и фотошоп пойдут ко дну следующими.
Этот юайкит реализуется в виде сторибука на стороне фронтенда, мапится на данные с фигмы насколько это возможно. Сторибук проверяется отдельным агентом, проверки встраиваются в пайплайны при желании
Из компонентов этого юай-кита дизайнерами собираются экраны. Экраны на стороне фигмы валидируются плагином на предмет отсутствия компонентов не из юай-кита. Unsafe-зоны с непредсказуемым результатом реализации по желанию.
Эти экраны экспортируются из фигмы в виде JSON и преобразуются в пригодное для нейронки дерево компонентов.
Другой агент из этого дерева делает в точности то, что вы сверстали бы руками, но в несколько (десятков) раз быстрее. При этом сам проверяет результат в браузере.
Далее по вкусу и возможностям, автоматическая реализация интеграций, особенно при наличии OpenAPI или аналогичных контрактов
Так убирается куча ручной работы и вырастает скорость. И это в разы усиливает фокус на том ЧТО надо, а не на КАК. Еще это приводит к тому, что джуны и даже мидлы больше просто не нужны. И к этой реальности им надо подстраиваться: учить теорию, учить паттерны, учиться получать от нейронки результат, соответствующий и бизнесовым и техническим требованиям.
Если вы не будете так делать, вы будете не нужны. Фронтенд в своей массе - это первые кандидаты на выход, если не перестраиваться.
Ну либо можете писать нетипизируемый код, философствовать о плюсах и минусах размещения компонентов в глобальной области и вздыхать о нереализовавшихся мечтах, делиться этими чувствами на собеседованиях. Это сократит конкуренцию на рынке труда.
Проблема в том, что вы сами не понимаете, с чем боретесь. ИИ-модели прекрасно разбираются в стандартах, и если попросить агента разработать веб без зависимостей, он это сделает именно на тех стандартах платформы, с которыми вы боритесь. Вы упускаете главное: те же фреймворки, на которых ИИ вам нагенерит код по умолчанию, будут работать поверх тех же базовых технологий, о которых написана эта статья. В чем, собственно, ваша проблема? Ну то есть, это снова фундамент, который вы пытаетесь выбить из-под ног, чтобы все рухнуло. А подход с опорой на стандарты, кстати, банально жрет меньше токенов.
Другой вопрос: почему вы так токсично общаетесь? Просто, как будто веб-компонент наступил вам на ногу. Ведь речь в статье совсем не о том, что людям нужно учить, а о том, чтобы не тянуть за собой ненужные зависимости. Можете, кстати, отправить этот разговор той же ИИ-модели для фактчека - посмотрите, чью сторону она займет.
Я без всяких нейронок вам скажу, что никакие веб компоненты ни в реактовую, ни в какую либо другую кодовую базу модель не нагенерит, если я ее специально не попрошу.
Так что нет, не на тех стандартах.
И я не борюсь, я просто говорю есть. Выйдите на рынок труда и посмотрите сами.
И как это противоречит его словам?
когда вы дописали "Так что нет, не на тех стандартах." - стало противоречить словам и действительности ))
Только если не учитывать контекст беседы. Я использую реакт, вью, свелт и некоторые их производные. Никто из них не использует апи из стандарта веб компонентов. И ни одна модель их в кодовую базу по умолчанию не предложит для генерации. Потому что они никому там не нужны и нейронка эти вероятности видит
Я, к слову, согласен с вами по поводу текущего состояния рынка труда - сам активно в нем участвую. Да и автор статьи, кажется, с этим фактом не спорил.
Но суть-то в другом: фреймворки все равно работают на нативных веб-стандартах браузера, от этого никуда не деться. Вы же сами пользуетесь нейронками - у вас есть идеальный инструмент под рукой, чтобы разложить этот технический нюанс по полочкам и убедиться. Попробуйте.
Не работают фреймворки на стандарте веб компонентов.
Lit, Stencil, LWC и многие другие инструменты построены ИМЕННО на стандарте веб-компонентов. А те инструменты, которые перечислили вы - да, внутри себя используют другие механики. Но даже им приходится с этим стандартом считаться, потому что этого требует индустрия:
У Vue официально поддерживается макрос
defineCustomElementдля сборки в веб-компоненты прямо из коробки.У Svelte есть встроенная директива и флаг компилятора
customElement: trueдля тех же задач.У Angular под это вообще выделен целый официальный пакет Angular Elements.
А команда React еще в 19-й версии (2024 год) в официальном блоге отчиталась о существенном улучшении поддержки Custom Elements (наконец-то исправив свои старые архитектурные костыли с пропсами именно ради совместимости с этим стандартом).
Вы утверждаете, что эти технологии никому не нужны, но создатели ваших любимых фреймворков почему-то потратили массу времени на интеграцию этого стандарта.
Нейронке не нужно “учитывать вероятности”, она читает официальные спецификации. И если попросить ее сделать независимый переиспользуемый виджет, она без проблем соберет вам нативный кастомный элемент, который будет работать где угодно.
Чтобы собрать нативный переиспользуемый виджет, веб компоненты тоже не нужны. Откройте для себя zero runtime компоненты того же свелта. Кстати будет лучше чем веб компоненты.
Ну и естественно если вы попросите в свелтовом проекте создать нативный переиспользуемый виджет, то про веб компоненты модель без напоминания не вспомит.
Что до поддержки фреймворками, вы пробовали это использовать? Может объясните для чего она нужна? Хоть один юзкейс, по какой причине мне надо одновременно париться о двух разных способах управления компонентом и их жизненным циклом.
Я кроме как подрубить готовый компонент на том же lit не представляю зачем это надо и не знаю никого, кто это использует. А я знаю много разработчиков
Да что уж там, даже в $mol есть поддержка веб-компонент, на реализацию которой была потрачена масса времени (целый час).
Напишите статью на эту тему. И статью не начинающим фронт-энд разработчикам, а уже скорее дизайнерам, которым хотелось бы попробовать что-то новое, т.к. исходя из ваших слов разработчик уже и не нужен тут.
Я думаю, напишут и без меня. Разработчик в плане механический кодер (а это куча фронтовой работы) больше действительно не нужен. Тех кто не учится работать так как я описал, увольняют. Нужен опытный оператор и ревьюер нейронки + никуда не деваются задачи по просяснению требований, а это не механический скилл а скорее софтовый.
Причина простая: хоть ты сто раз сеньор, 'talk is cheap, show me the code'. Скорость разработки видна по гитхабу, качество видно по соответствию требованиям. И зачем платить от $3000 при цене нейронки в $200? Против такого же сеньора с настроенным агенстким флоу ты уже никто. Не учишься - конкурировать будешь теперь с мидлами на нейронках в лучшем случае. К счастью, те у кого мозг, а не ганглии, в большинстве переучиваются.
Точно также механические дизайнеры, которые не способны собрать нормально юайкит и собрать из него экраны тоже не нужны. Нейронкам на вход нужны максимально формализованные требования, читай дизайны из компонентов накиданные без всяких Shape и Text и отступов "я так вижу" для красоты. Не умеешь так делать - замедляешь работу дальнейших этапов - теряешь скорость разработки по сравнению с конкурентами.
Дизайнерам которые хотят попробовать что-то новое я бы посоветовал не ждать статей на хабре, которые все разжуют, а включать голову и думать, пока не пришли ребята поумнее, как уже пришли на фронтенд.
Автор, ходить по каждому комментарию и по ставить по минусу - это позорно и жалко :) Более жалко будет только оправдываться, что это не ты.
Жалко, кажется, это писать ещё один, очередной провокационный коммент.
И верх этого, это жаловаться на это при сказанном ранее:
Ты возможно что-то перепутал, но я напомню что ты публикуешься на открытом ресурсе.
Ты прав! Это еще было не жалко! Вот реально дно:
@KonBone - первый коммент с 2022 шгода, пишет из песочницы
@replicate_1 - по приглашению от @i360u, недельная рега
@Mr_FatCat - по приглашению от @i360u
@codegentop – по приглашению от @Mr_FatCat
Тут теряюсь, то ли @i360u сюда воспитательницу еще позвать забыл, то ли пора его пощупать за всякие места за ботоводство. Но в любом случае - это днище.
@Exosphere посмотрите @KonBone @replicate_1 и @codegentop на всякий - минимум комментов, все комменты в топиках автора, всегда появляются, чтобы оставить коммент в его пользу и молча посливать комментарии против. Насколько я знаю, ботоводство запрещено правилами.
Реальным пользователем выглядит только @Mr_FatCat
Да, @Exosphere, посмотрите, пожалуйста.
Честно говоря редко встретишь человека в комментариях, который настолько пренебрегает правилом.
Оскорблять других пользователей, не следить за эмоциями
https://habr.com/ru/docs/help/rules/
Уважаемый @i360u! Я по отношению к вам и вашим ботам адресных оскорблений не допускал. А называть описываемое в статье барахло - барахлом правилами не запрещено. То, что вы воспринимаете критику вашего решения как хамство по отношению лично к вам, еще не делает его таковым.
А вот сливать втихую карму ботами это поинтереснее будет.
Чел, прости, но я искренне считаю, что ты психически не очень здоровый человек. Может это и не так, но выглядит - так. Я бы хотел тебе как-то помочь, но, честно, не знаю чем.
@Exosphere переход на личности и оскорбление.
и это просто милые слова… https://habr.com/ru/articles/1019206/comments/#comment_29775948
Дружище, я тебе карму заминусил за твой стиль общения. Ты лично не считаешь свои выпады хамством, например такой:
Можно просто открыть доку к любой либе поверх них, включая либу многоуважаемого автора, посмотреть какое это убогое говно и закрыть.
Я, например, считаю.
У тебя такой пронзительный стиль общения, что тут боты не нужны для кармослива. Ты и сам прекрасно справляешься.
Дополню тут, раз уж делимся теориями заговора:
Ситуация выглядит, как попытки пиара $mol путём "Задушить конкурента"(?).
@cmyser - явно упомянул, что связан с ним
@nin-jin - также, вероятно, связан, хотя прямо не говорил, либо я уже забыл
@Synopticum - его связь со $mol не понятна, но общий мотив сообщений похож на стратегию их пиара
Не прошу с этим ничего делать.
@nin-jin - это нездоровый автор поделия под названием mol и всей его экосистемы, не умеющий ни общаться, ни принимать каую-либо критику, а @cmyser очень похож на его альтер-эго.
@Synopticum раньше не встречал, но судя по его ответам, пахнет точно такойже cat-piss - либо тотже лагерь, либо альтер-эго.
Не прошу с этим ничего делать.
А вот я, наборот, прошу @Exosphere что-нибудь с этим сделать, ибо эти персонажи реально достали, как и весь их братвополь.
Что до веб-компонент - это лучшее и реально полезное, что случалось с вебом за последнее время.
Дима, слава богу, здоров)
Критику он принимает, но остро отвечает ( что, согласен, не всегда хорошо и часто превращает спор в полемику )
я не альтер эго, я искренне считаю что $mol имеет огромное кол-во преимуществ с которыми невозможно спорить и от которых невозможно отказываться
приходите лично пообщаться на t.me/piterjs ( лично невозможно токсить, уверяю вас )
обсудим веб компоненты и иже с ними)
Критику он не принимает, для него есть только его поделие и все, остальные, кто не с ним - идиоты - это не признак здоровости.
Кроме этого он не гнушается манипуляциями и переходами на личности, что тоже не признак ума или чего-то ещё.
Чтобы не быть голословным, вот последняя его статья, где все отлично видно, особенно в комментах https://habr.com/ru/articles/1014708/
mol, если его сделать честным, а не как делает автор, например исключая оффскрин ноды и сравнивая с либами где они честно присутствуют ни какими плюсами по скорости обладать не будет, а с таким самодуром во главе - и подавно.
да, те ответы его не красят, не буду как то оправдывать
но по бенчам - они все честные ( в js-framework мола нет )
https://t.me/giper_dev/11/24890 - гляньте, там разные js либы используются, никакого жульничества, чистый js
про рендеринг в js-framework-bench скажу что мол не умеет рисовать не виртуализированный интерфейс
Тут я склоняюсь к тому что бенч не отражает реальных возможностей фреймворков, я бы разрешил виртуализацию всем ( пользователю ведь хочется быстрый интерфейс а не 100К честно отрендеренных карточек за минуту реального времени )
если хочеться приятно поболтать, приходите на t.me/piterjs ( быть токсиком лицом к лицу просто невозможно! )
мы никого не душим) если кого и критиковать дак это react)))
скорее просто пытаемся разобраться в вопросе веб компонент, ну и спорим, где то аргументировано где то не очень
я живой, отдельный человек) приходите на t.me/piterjs
пообщаемся лично ( в живую кстати, никогда не видел что бы кто то токсчил так что живое общение - лучший способ коммуникации я считаю)
я пишу на моле, Дима - его автор, третий это хз кто, хейтер какой то левый
Открою вам потрясающий секрет: в реальном ИТ-мире помимо нейронок и ботов существует такое понятие, как коллеги.
Когда вам по делу больше ответить нечего, в ход идут универсальные заглушки про "нейрослоп" и "это все боты". Забавно, что вы вообще рассуждаете о "дне" на фоне того, что вы пришли хамить всем подряд и проявляете поразительно аномальную активность в негативном ключе исключительно к одному автору во всех ветках.
Если в этом треде и есть подозрительные персонажи, чье поведение стоит изучить модераторам - так это вы и те, кто тут спамит ссылками на свой проект и откровенно неадекватными скриншотами.
Не любите веб компоненты? Вы просто не умеете их готовить.
Возможно многие выбирают не ту задачу для веб компоненты. Можно начать с простого UI kit на веб компонентах для проекта на vue, svelte или ещё чем-то
часто вижу похожее мнение, не согласен с ним
задача же у нас всех одна - нарисовать удобный быстрый интерфейс
тут веб компоненты проигрывают, сильно проигрывают
Кому они проигрывают? Что опять за чушь?!
Ваша фраза звучит примерно так "CSS проигрывает FastApi", ага.
Любой инструмент работает в контексте, так вот, если без фреймворка и нативно, без сборщиков и тд требуется нарисовать "красивый и удобный интерфейс", то у веб-компонент просто не существует конкурентов.
И рассматривать их надо не как конкурентов фреймоворков, а как дополнительная киллер-фича, которую можно использовать совместно, это же касается и shadow DOM.
Не чушь, надо было сразу ссылку дать
они проигрывают по потреблению памяти
вот тут сделал аналитику https://habr.com/ru/articles/1019420/
И рассматривать их надо не как конкурентов фреймоворков, а как дополнительная киллер-фича, которую можно использовать совместно, это же касается и shadow DOM.
Согласен. Просто много появляется фреймворков основанных чисто на них, и они уже конкурируют с "обычными" фреймворками
Вы реально думаете, что сравнивать сколько потребляется памяти в нэтиве DOM элементов и js объекты, которые потом плюсом рендерится в элементы DOM - это действительно корректно? Особенно если учитывать нагрузку на CPU при этом.
Если да - у меня больше вопросов нет)
О боги, вы опять передёргиваете факты. Скажите пожалуйста, а ваш $mol не в DOM рендерится? А после рендера каждого компонента в DOM узел у вас разве не выделится тот же объём памяти, что и у веб-компонентов?
Вы берете специфичный кейс ленивой инициализации (который в большинстве приложений не нужен), возводите его в абсолют, и кричите: смотрите, народ, веб-компоненты в 8 раз потребляют больше памяти, чем $mol!
Поэтому с вами и невозможно дискутировать, потому что вы живёте в своем мире вымышленных проблем.
не передергиваю
мол использует виртуальный рендеринг и не деградирует, а вот всё остальное - деградирует, так как рендерит полностью
Без комментариев)
по памяти Если бы мол рендерил всё - было бы так же
но он же не рендерит
кейс не специфичный - проблема производительности сейчас массовая
я не стараюст как то передернуть, в сущности то вы правы - но фактически нет
проблема веб компонент в том что им обязательно занять эти минимальные 124 байта, вот суть то, еще до обработки уже памяти больше нужно
Проблема производительности массовая, потому что VDOM когда-то победил. Но благо сообщество опомнилось, и стали появляться нормальные фреймворки.
Госпади 😁 опять вы со своими 124 байтами. Так не создавайте веб-компоненты, которые не собираетесь рендерить. У меня ощущение, что вы попали в ментальный плен к Дмитрию, готов оказать психологическую помощь 😅
😄
Те что отрендерены без виртуализации будут)
Я просто правда искренне считаю что мол лучше всех, поэтому и защищаю)
Вот в этом и проблема: в инженерном мире нет "лучшего" решения. У веб-компонентов есть свои минусы, но есть и неоспоримые плюсы. Как и у Реакта, и других фреймворков.
Перестаньте играть в эти детские игры: лучше или хуже, а выбирайте то, что максимально подходит в вашей ситуации.
P.S. у вас в документации $mol очень специфичный UX, я бы не хотел, чтобы все сайты были такими. И это о многом говорит... Вы фокусируетесь на бенчмарках и байтах, а не на реальном удобстве для пользователей.
Мне кажется что есть всё таки, новые фрейморки появляются чтобы заменить старичков, но и те и те решают одни и те же задачи
По поводу доки, да она отстойненькая)
Но никто не запрещает делать красиво, например как у меня вот
https://b-on-g.github.io/blitz/
Подробнее:
И на самом деле я как раз стараюсь думать про пользователей, бенчи тут так, просто в тему для объективности
К тому же никому не нравятся лаги) и баги)
Ещё раз все сайты на моле не одинаковые !!! Это миф !)
Это 3 сайт на моле, который я увидел, и сразу понятно что это $mol. А как у вас дела с CLS обстоят? Метрика может нормальная, но вот из-за этой виртуализации сайт воспринимается как нечто дерганное.
Это уже успех?) Честно лучше не выставляйте такое, это позор.
Лишняя шапка меня выдала!)
о, багу не заметил, надо поправить будет
рестарт страницы поможет кстати ;)
всё остальное работает, не позор)
по метрикам
FCP возможно расчитывается неправильно, не уверен
на декстопе еще добавлю
Наверное да, ошибки бывают, но когда вы на такую «горячую тему» пишете и спорите на хабре надо железобетонно вылизывать все сервисы и страницы; на разных браузерах; на мобильном и декстопе. Иначе с такими пусть и hotfix косяками ну не продадите обществу, ну не. При ужн текущей спорной репутации $mol я бы над каждой мелочью дрожал и тестировал шоб работало идеально. А так, что 6 лет назад в комментариях github issues по сути, что сейчас.
В мол действительно есть интересные идеи, но почему так плохо протестировано и нарочито навязано. это будет отталкивать
Lighthouse заброшен. Используйте PageInsight (оф рекомендация гугла)
Если вдруг в Питере приходите развиртуализироваться на t.me/piterjs !
Там очень лампово и уютно ( и иногда шутять про смол 😄)
Отличная статья. Приверженцы $mol разоблачены и выведены на чистую воду 😅
Большой плюс веб компонентов - наличие спецификации, которая выбита в камне и реализована всеми браузерами.
Что не так с веб-компонентами?