Бенч mol и WC? Так для wc нужен фреймворк, там вот где-то в соседних ветках symbiote форсили, я хз что это, но наверное с ним можно. Lit конечно говно редкостное, рядом с mol и не лежал)
Push - как и все события dom. В mol наверное тоже они обрабатываются. Дальше оборачивается в push/pull в зависимости от statemanager. Не все через атрибуты.
JS объект не отрендеришь, тебе нужен див - оверхеда нет
Obj.title потом все равно вызовет div.textContent. И наоборот customElement.data.title быстрый.
Вы сравниваете mol с каким-то другим фреймворком, с Lit? Тогда при чем тут CE и WC?
pull семантика архитектурно не поддерживается WC
Чем она не поддерживается, CE или ShadowDom? Pull семантика у стейт менеджера, в WC нет дефолтного стейт менеджера, можно брать любой. Парсинг html - это про lit Кол-во строк кода - по сравнению чего с чем? Опять видимо Lit vs mol. Ну так и назовите статью “Вздор про lit и восхваление Mol”
Да, спасибо, про jit тоже треш какой-то. Как будто в mol вам не нужен textContent и setAttribute. Вы ведь не в канвас рендерить? Значит тот же дом, только на другом этапе. Хоть один аргумент стоящий есть?
CE отлично дружат с JS объектами, совершайте манипуляции в JS объекте. Про jit не вижу в статье.
WC ( Web components ) используют push семантику для реактивности. Pull думаю врядли буду поддерживать. Это ваше мнение. В CE нет реактивности, но никто не мешает в них добавить mobx, rxjs или вот ваш mol.state, наверное тоже можно?
Вы привели минусы веб компонентов: много занимают памяти и неудобная компоновка требующая дублирование логики. Оба аргумента не выдерживают критики, по крайне мере я так понял из ответа на мой комментарий. Тогда напрашивается вопрос, в чем минусы, в чем суть статьи?
Про сравнение памяти для объектов - второй вариант будет отрендерен в какой-нибудь див и будет занимать те же мегабайты наверное. А если виртуализация и он не будет рендериться, то и CE так же можно не рендерить. Логика переходит в контейнер выше.
Про композицию - делаем функции renderHeader, renderBody, renderFooter и переопределяем одну в наследнике. Лет 40 этой практике наверное.
А у Вас в браузере не включен хедер Accept-Encoding: ai? С ним текст сжимается с помощью LLM на сервере и вы получаете короткий abstract. Одна llm пишет, другая читает, а хабру просмотры и деньги от рекламодателей, которые еще не поняли, что llm не умеет покупать их товары
Мне кажется у Вас довольно превратное представление о чистом коде - примеры которые вы привели имеют мало общего с оригинальными идеями Мартина. Вы читали его книгу?
Да, это примерно то что нужно. Неудобно, что нужен комп с установленным сертификатом разработчика, у меня сразу же включается паранойя - если этот комп у человека, то он может запаблишить все что угодно без ревью, а это стремно.
Недавно завезли немного сахара для итераторов: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Iterator/map Через пару лет может и до asynciterator дойдут.
Бенч mol и WC? Так для wc нужен фреймворк, там вот где-то в соседних ветках symbiote форсили, я хз что это, но наверное с ним можно. Lit конечно говно редкостное, рядом с mol и не лежал)
Push - как и все события dom. В mol наверное тоже они обрабатываются. Дальше оборачивается в push/pull в зависимости от statemanager. Не все через атрибуты.
JS объект не отрендеришь, тебе нужен див - оверхеда нет
Obj.title потом все равно вызовет div.textContent. И наоборот customElement.data.title быстрый.
Вы сравниваете mol с каким-то другим фреймворком, с Lit? Тогда при чем тут CE и WC?
Чем она не поддерживается, CE или ShadowDom? Pull семантика у стейт менеджера, в WC нет дефолтного стейт менеджера, можно брать любой. Парсинг html - это про lit Кол-во строк кода - по сравнению чего с чем? Опять видимо Lit vs mol. Ну так и назовите статью “Вздор про lit и восхваление Mol”
Да, спасибо, про jit тоже треш какой-то. Как будто в mol вам не нужен textContent и setAttribute. Вы ведь не в канвас рендерить? Значит тот же дом, только на другом этапе. Хоть один аргумент стоящий есть?
Чтобы получить mol к ce нужно добавить mol и выкинуть ce.
CE отлично дружат с JS объектами, совершайте манипуляции в JS объекте. Про jit не вижу в статье.
Вы привели минусы веб компонентов: много занимают памяти и неудобная компоновка требующая дублирование логики. Оба аргумента не выдерживают критики, по крайне мере я так понял из ответа на мой комментарий. Тогда напрашивается вопрос, в чем минусы, в чем суть статьи?
Большой плюс веб компонентов - наличие спецификации, которая выбита в камне и реализована всеми браузерами.
Тогда о чем статья?
Про сравнение памяти для объектов - второй вариант будет отрендерен в какой-нибудь див и будет занимать те же мегабайты наверное. А если виртуализация и он не будет рендериться, то и CE так же можно не рендерить. Логика переходит в контейнер выше.
Про композицию - делаем функции renderHeader, renderBody, renderFooter и переопределяем одну в наследнике. Лет 40 этой практике наверное.
Twa пропускают в Appstore, в чем проблема?
А у Вас в браузере не включен хедер
Accept-Encoding: ai? С ним текст сжимается с помощью LLM на сервере и вы получаете короткий abstract. Одна llm пишет, другая читает, а хабру просмотры и деньги от рекламодателей, которые еще не поняли, что llm не умеет покупать их товарыНо фидбек - это ведь не ПД, почему его нельзя давать? С точки зрения законов или этики?
Мне кажется у Вас довольно превратное представление о чистом коде - примеры которые вы привели имеют мало общего с оригинальными идеями Мартина.
Вы читали его книгу?
Динамическая типизация тут ни при чем. Хранить версию в виде строки можно и в java и в C.
PVS-Studio умеет отлавливать такие "ошибки"?
Да, это примерно то что нужно. Неудобно, что нужен комп с установленным сертификатом разработчика, у меня сразу же включается паранойя - если этот комп у человека, то он может запаблишить все что угодно без ревью, а это стремно.
Универ можно будет потом сходить когда поймёшь что интересно. Но и в армию никак нельзя, так шо тикайте хлопцы
Спасибо за развернутый комментарий, стало понятнее.
Не хватает в обратную сторону api:
А так отличная новость, хорошая замена для
route-parserкоторому давно пора на пенсию