Обновить

Комментарии 27

Респект за написание статьи, но чувак, ты со своим $mal иногда выглядишь как фанатик. Люди инертны, консервативны. Статьями на хабре призвать их использовать хорошее доброе вечное... вряд ли получится. Основывай свою корпорацию, делай ее продукт популярным и навязывай хорошие фоеймворки так! :)

спасибо)

только фанатики могут двигать не фанатиков на изучение нового)

Корпорация тоже будет!

Пацан к успеху идет: хочет стать топ-2 токсиком Хабра (после Карловского)

хахахахахаха))

Про сравнение памяти для объектов - второй вариант будет отрендерен в какой-нибудь див и будет занимать те же мегабайты наверное. А если виртуализация и он не будет рендериться, то и CE так же можно не рендерить. Логика переходит в контейнер выше.

Про композицию - делаем функции renderHeader, renderBody, renderFooter и переопределяем одну в наследнике. Лет 40 этой практике наверное.

C виртуализацией не всё так просто
бенч https://t.me/giper_dev/11/288
статья про неё https://mol.hyoo.ru/#!section=docs/=gjboo1_xhyrnq

Про композицию абсолютно согласен, тут поинт скорее в том что это архитектурное решение, то есть разработчик никак не может сделать плохо ( как я показал )
ну а чем меньше ошибок может допустить програмист и отловить компилятор - тем лучше



Опять же аппеляция к тому что не надо думать и писать "лишний" код

Тогда о чем статья?

не понял вопрос, может выйдет раскрыть ?

Вы привели минусы веб компонентов: много занимают памяти и неудобная компоновка требующая дублирование логики. Оба аргумента не выдерживают критики, по крайне мере я так понял из ответа на мой комментарий. Тогда напрашивается вопрос, в чем минусы, в чем суть статьи?

в статье есть еще аргументы)
про память - аргумент выдерживает критику ( веб компоненты обязаны занимать эту память, а с js обьектом можно много манипуляций до рендера провернуть )
про jit - тоже
про pull push реактивность тоже

Я работал с Lit, но совсем не понял, что там такого ценного. Компоненты JS можно и так писать.

Может и есть что-то очень полезное в Web Component, но лично я ничего такого не нашел.

лит добавляет реактивность для веб компонент
вроде у него еще и своя модель компонент есть, глубоко не копал

Вы почему-то скрыли от публики часть результатов вашего-же изначального сравнения. Именно ту, где были реальные значимые цифры, и они были СИЛЬНО не в пользу $mol. Кроме того, вы не боитесь открыть ящик Пандоры и добиться того, что кто-то все-таки не выдержит, и потратит время на РЕАЛЬНОЕ сравнение? Боюсь, оно будет разгромным.

буду рад получить реальное сравние от независимого автора, только таким, научным, методом рождается истина

я там бенч изначально неверно составил с размером ( в корне были мои мусорные файлы которые тянулись во все бандлы локально у меня )

Настоящий размер составил 181 кб, честно указал его в бенче

https://github.com/b-on-g/todomvc-compare

что бы проверить вы можете выполнить

git clone https://github.com/hyoo-ru/mam.git
cd mam
npm install
npm start hyoo/todomvc

и в папке hyoo/todomcv/-/web.js -- вы тут получите весь собранный код


PS поправил пути, и у меня на чистую 185 вышло щас

Я до конца не уверен, клон ли вы Дмитрия, или настоящий живой человек, но что касается общения - ему явно стоило бы у вас поучится. По технической части я вернусь с фидбеком позже.

не клон)
спасибо)
да я там фиксанул еще пути, проверил теперь собирается то что нужно

Подтверждаю: это настоящий человек - знаю его ирл)

Да, в целом ты прав, но ты немного радикально обобщаешь. Проблема не столько в самих веб-компонентах, сколько в том, как их используют. Если просто наивно рендерить тысячи элементов через DOM -любой подход упрётся в лимиты, не только WC.

я так же думаю, но почему многим это важно ( вот тут https://habr.com/ru/articles/1014708/#comment_29737390 )

эти многие реально смотрят на https://github.com/krausest/js-framework-benchmark
и думают что там реальная производительность показывается

тут фрустрация и отторжение из за "попытки обмануть" бенч этот
но если бенч плохой, зачем он нужен

я считаю лучше применять всё что можно, все допинги, и показывать реальную максимальную производительность JS. Она тоже не бесконечна, но насколько Не ? никто не знает. все упёрлись в html

по моим расчётам на моле можно свою OC написать, и она будет быстрее и стабильнее многих ныне живущих) ( и даже уведомления будут сразу прилетать и колокольчик краситься )

Не стоит рендерить то - что не видно.

Да, я именно так и думаю, когда поиск по странице ничего не находит, если это не на экране /s

плюсик в карму) согласен)

забавно, но в $mol поиск как раз таки работает)
но для этого нужно переопределять поиск стандартный ( в моле по дефолту )

Тут все просто, как по мне. Если делаем SPA - берем $mol. Он для этого топ-1. Если делаем сайт с интерактивными элементами - берем SSG (или классический веб-фреймворк с шаблонизатором, типа Laravel) и одно из вышеупомянутых WC-based решений. Все.

вопрос приоритетов
для ssg я бы всё равно конечно мол взял ( темы\локализация\адаптивность ) по дефолту идут

А вот WC если нужно куда в уже существующий проект пропихнуть то почему бы и нет
я бы даже к себе в $mol приложение попробовал сунуть

Вы так сподвигнете наконец изучить веб-компоненты и попробовать их на чём-нибудь реальном

это же хорошо)
на $mol, кстати, тоже можно их использовать, и писать )

Хорошая попытка, но нет. Привычнее Vue/React.

попробую как нибудь еще)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации