полимеровцы уже отказались от развития своих придумок в пользу lit-html, это было благородно наверное, если бы lit-html сам по себе не был таким же поперек придуманным относительно веб компонентов
если сильно отличается это должны быть разные шаблоны, каждый из этих шаблонов вы уже имеете в объектной модели браузера, быстро и дешево клонируете и подрендериваете динамические данные, тут надо понимать, что вам не обязательно перерендеривать что-то или даже все, на каждое изменение, т.к. вы можете сбиндить логику делающую простую перезапись данных по ссылке при проявлении изменений в системе.
да, но правильнее даже наверное .textContent или setAttribute для заменяемых значений, так типобезопаснее и скорее всего прозиводительнее, а основная часть просто должна быть внутри тегов ну если надо динамически еще есть .insertAdjacentHTML()
стоит отметить, что даже фреймворки использующие веб-компоненты делали это, как-бы это сказать, не очень привлекательно с точки зрения архитектора и инженера, так например многие использовали разные «шаблонизаторы» надстраивающие или подменяющие native templates, когда в них нет особой необходимости, нарушающие принцип разделения ответственностей хтмл импорты, старый страшный синтаксис джаваскрипта и другие причуды, т.е. примеры их практического использования не выглядели выйгрышно в сравнении с популярными фреймворками, которые не используют браузерные стандарты
жетская связь не позволит сделать расширяемую систему, каждый раз когда вы изменяете кнопку, вам придется менять/пересобирать/перезагружать и связанные с ней компоненты. ML языки априори слабосвязные, т.к. их основная задача обеспечивать расширяемую семантику документа, модульные и компонентные системы должны быть слабосвязными для задач масштабирования и адаптации, но когда вы делаете слабую связь между самой кнопкой и сбинденым на нее действием это как раз тот случай когда собирать воедино и отлаживать все будет проблематично.
в вашем примере вы в рантайме создаете шаблон, когда оптимальнее для производительности разместить его сразу в html, тогда он будет разобран браузерным движком раньше и быстрее и быстрее, затем вы там основную работу делаете строками, т.е. преимущества собственно шаблонной технологии не используются
это был простейший минимальный пример инкремента счетчика с обновлением отображения результата. Веб-компоненты при том, что аналогичная задача реализованная с их помощью не приводила к росту потребления или утечке памяти, была оптимизирована браузером, а не алгоритмами в js рантайме и хитровыделанной архитектурой и как результат выполнилась за разумное время и вообще отработала успешно.
вопрос будет ли ваша оптимизация работающая на джаваскриптовом рантайме работать быстрее оптимизаций и рендеринга браузерного движка. Я делал бенчмарк 1000000 изменений данных прибинденых к интерфейсу, сравнивая вебкомпоненты + прокси и реакт и редакс. Нативный образец просчитался за 5-6 секунд и отобразил сразу финальное значение, в то время как рякт с пропсами (это был стартер прямо из yeoman) работал несколько минут, сожрал всю память и упал так и не отобразив ни одного изменения
Мы явным образом импортируем компонент Button. Если удалить импорт, то у нас произойдет ошибка в рендеринге. С веб-компонентами ситуация другая, мы просто рендерим html-тэги, а они магическим образом оживают.
это называется слабая связность, когда она между компонентами или модулями это дает преимущества масштабируемости системы: вы можете добавлять и изымать части системы без нарушения ее работоспособности. В рякте же все с ног на голову: слабая связность применена между логикой представления (его компонентами) и бизнес-логикой (редакс и пр.), что усложняет разработку, у меня например не работало автодополнение в среде разработки, следовательно будут пропускаться и ошибки, а прямая связность — в лейауте, что сильно снижает открытость архитектуры для изменений.
В случае lit-element в последнем Хроме я наблюдаю явную просадку FPS при открытии меню. В Preact-версии такого нет. Исходный код демок можно посмотреть вот здесь.
lit-element это не совсем веб-компоненты, это штука больше похожая на react и видимо от тех же проблем страдающая, а метод рендеринга собственно веб-компонентов это Native Templates, когда вы клонируете экземпляр шаблона и апендите, это работает намного быстрее любого шаблонизатора, потому что на момент работы жс рантайма шаблон уже разобран браузером и не нуждается в значительных рендеринг операциях
очень часто жадность предела не имеет и как-то так и хотят, печально конечно еще и то, что многие вместо того что космический корабль за две недели не построить и с коленки не запустить беруться. Ну а на шаред хостинге оно не будет работать банально из-за органичений по времени выполнения сркипта, потребляемой памяти и т.п., но осоздание того что надо было делать таки по-нормальному по законам жанра должно придти когда будет уже вбухано много денег, времени, нервов, написано куча костылей, нагерерировано данных и пр.
несколько лет получал настоящую многозадачность (ну или на 99% как у взрослых) с форком процессов и обменом данными с помощью PCNTL и обертки из ZendX для нее. Из недостатков: юникс онли и некоторое время на спавн нового процесса, но многопоточность и изящность это дело более-менее компенсировала.
глобалы, процедурный стиль и лисапеды — дорога в ад
фтп показал 20-60 килобайт/сек в обе стороны
вебморда на аплоад показала какие-то еще менее выдающиеся результаты
дав на скачивании вырос с 20 до 120 килобайт, на пытке аплоада просто встал на нуле
т.е. по качеству оно годится только для самых скупердяев;)
Уважаемые рельсовики перфекционисты, сделайте пожалуйста в Redmine настройку видимости полей у задач в зависимости от ролей и проектов. Очень нужно, а который год ждем. Спасибо;)
я купил ультимейт с месяц назад (по этой же скидке), посмотрим:)
к сожалению ультимейт умеет создавать только джава проекты, хоть и позиционируется как универсальная среда. Они об этом нигде не предупреждают, так что предостерегаю от покупки его вместо пичарма, рубимайна или веб/пиейчпишторма
это называется слабая связность, когда она между компонентами или модулями это дает преимущества масштабируемости системы: вы можете добавлять и изымать части системы без нарушения ее работоспособности. В рякте же все с ног на голову: слабая связность применена между логикой представления (его компонентами) и бизнес-логикой (редакс и пр.), что усложняет разработку, у меня например не работало автодополнение в среде разработки, следовательно будут пропускаться и ошибки, а прямая связность — в лейауте, что сильно снижает открытость архитектуры для изменений.
lit-element это не совсем веб-компоненты, это штука больше похожая на react и видимо от тех же проблем страдающая, а метод рендеринга собственно веб-компонентов это Native Templates, когда вы клонируете экземпляр шаблона и апендите, это работает намного быстрее любого шаблонизатора, потому что на момент работы жс рантайма шаблон уже разобран браузером и не нуждается в значительных рендеринг операциях
глобалы, процедурный стиль и лисапеды — дорога в ад
фтп показал 20-60 килобайт/сек в обе стороны
вебморда на аплоад показала какие-то еще менее выдающиеся результаты
дав на скачивании вырос с 20 до 120 килобайт, на пытке аплоада просто встал на нуле
т.е. по качеству оно годится только для самых скупердяев;)
И конечно backupninja, к сожалению только под линукс
www.godaddy.com/email/online-storage.aspx?ci=55861
к сожалению ультимейт умеет создавать только джава проекты, хоть и позиционируется как универсальная среда. Они об этом нигде не предупреждают, так что предостерегаю от покупки его вместо пичарма, рубимайна или веб/пиейчпишторма