весь этот пример основан на записи строки в которую интерполяцией подставляются значения через свойство .innerHTML, т.е. этот тест не проверяет веб-компоненты, а как максимум часть называющуюся Custom Elements, поэтому что если вы откроете любую статью или книгу про веб-компоненты вы там увидите и упоминания Native Templates т.е. шаблонов в теге template клонируемых в dom
Тут нигде не указано что вы говорите о фреймворках Большой Тройки.
ну svelte к ним точно сейчас не относится, ember наверное уже не относится, про preact я слышал только от поклонников реакта, так что тоже наврядли, действительно можно говорить только о трех фреймворках на сегодня
Например? Фреймворки просто работают и те механизмы, которые они используют зависят только от мейнтейнеров и комьюнити.
популярные фреймворки курируются корпорациями навроде фейсбука или гугла и сейчас на фронте все чаще популяризируются неудачные решения и идеи противоречащие принципам программной инженерии, такие как смешение бизнес-логики с версткой, отрицание ооп, игнорирование стандартов. Все современные популярные фреймворки развиваются поперек стандартизированных технологий, в том числе тех, что входят в группу веб-компонентов. Например ангуляр многим хорош, но шаблоны у него свои, а не нативные, и валидацию форм они сделали свою неудобную, когда есть отличное стандартизированное апи хтмл5. У остальных фреймворков проблем еще больше.
То есть по вашему раздел стандрата HTML Import как-то описывал то, как должны писаться Веб-компоненты?
была проектная группа которая разрабатывала стандарты w3c, и html imports тоже предполагался, поэтому использовался в полимере, но он встретил сопротивление и был совсем отвергнут разработчиками фаерфокс например, а затем и вовсе не был утвержден как стандарт
Вот как этот же код мог бы выглядеть на Svelte (если работать с компонентами отдельно, как у вас):
какая-то странноватая придумка, импорт грамотнее будет сделан нативными модулями, а для роутинга можно использовать любую понравившуюся библиотеку, или вовсе не роутить а перерендеривать явно, из вашего примера не очень понятно сразу, что происходит
О каком DX тут вообще может идти речь? Даже такую вроде как очевидную вещь как property reflection приходится делать в полностью ручном режиме:
ну надо просто перестать воображать что проперти класса и атттрибуты это одно и тоже и все встанет на свои места. Вы сами правильно заметили, что аттрибуты поддерживают только примитивы (потому что они задаются литералами), а на класс можно присвоить все что угодно, в том числе экземпляры других классов
а и непонятно, почему я должен использовать найтив темплейты? И при этом с какого-то перепугу замеряю не то.
потому, что нейтив темплейты входят в группу стандартов объединенных термином, веб компоненты, а вы замеряете вставку строки с интерполяцией в dom и называете это веб-компонентами
О чем вы вообще?
строка включает движок эджа, зачем такое в тестах?
что на сегодняшний день код на различных популярных фреймворках практически никак между собой не совместим
Вы видимо Svelte не посмотрели, тогда бы хоть значи о чем речь. )))
svelte не является популярным фреймворком, я имел ввиду react, vue, angular, если вы записанное простыми предложениями понять не можете я вам помочь ничем не смогу
Видите как получается, на стандарт даже Гугл положиться не может, куда уж нам смертным.
у смертных не выполняющих стандарты шансов еще меньше, стандарт был не удачный и он не был принят, и разработка полимера была отменена, в отличии от большого количества неудачных решений популярных и не очень фреймворков.
Боюсь вы не поняли) html imports
я указал на подобие т.е. механизм импорта вермишели из js, стилей и разметки в html который я увидел в коде для вашего ферймворка, такой же применяется в .vue
вы ведь используете там преобразование строки (да еще и с интерполяцией) с разметкой в dom, а не нейтив темплейты, т.е. замеряете не то. Кроме, того вы это запускаете в эдже? Зачем там мета совместимости?
То то Youtube в Firefox до сих пор тормозит безбожно.
полумер полагался на html imports, принятие которых в стандарт заблокировал как раз таки фаерфокс, т.е. там они скорее всего работают через полифил и жс рантайм, а в хроме нативно, вот вам и разница заметная на глаз. Как я понимаю, этот ваш Svelte использует какой-то такой же подход, который был по причинам нарушения принципа разделения ответственностей индустрией отвергнут. Лично мне, точно также кажется обилие странностей фреймворка неоправданным, что-бы завязываться на него. Классы-инстансы для хранения и линковки состояния я могу легко подключить в компоненты с инжектором если что-бы красиво или нехитрым собственным мета-кодом.
то поняли бы, почему Джордж вынужден дефайнить компонент внутри
он не должен этого делать ни в каком случая, в этом сила веб-компонентов, что вы можете дефайнить компонеты потом в том числе и для динамического рендеринга
Подмену компонентов в рантайме также можно легко реализовать в любом фреймворке.
подмена это небезопасная коллизионная история, мне кажется так делать просто недопустимо, т.к. непонятно что делать с уже отрендеренными компонентами, непонятно почему ваши компоненты может кто-то подменить. Вы можете в частном порядке разрешать конфликты присваивая им другие тегнеймы.
Еще раз — если я взял сложный 3rd-party компонент и хочу его поместить в свое приложение
вы лично может не хотите, а кому-то без этого не решить задачи. Основное назначение кода — быть расширяемым и дорабатываемым, и харкод в том числе конфигурации и бутстрапа эту возможность существенно ограничивает. По уму должны быть доступны оба варианта: у вас есть класс-компонент который вы можете сбиндить на любой тегнейм и у вас есть бутстрап для готового использования который конфигурирует его и биндит на определенный тегнейм. Есть библиотека что-бы расширять и переиспользовать и бандл что-бы просто подключить.
в этом треде я приводил пример когда затык кода на вебкомпонентах разрешился за 5-6 секунд, а рякт работал на том же коде несколько минут пока не сожрал всю доступную память.
Вы можете также нагуглить публичные бенчмарки, я не знаю как они там мерили, но там в числе лидеров веб-компонентный Svelte (https://medium.com/@ajmeyghani/javascript-frameworks-performance-comparison-c566d19ab65b), но тут над понмимать, что этот фреймворк наворачивает свой mustache подобный шаблонизатор над нейтив темплейтами или вовсе без них в рантайме, т.е. занимается тем же бестолковым преобразованием строк в объекты дом с полнотекстовым поиском плейсхолдеров для замены вместо оптимизированного дерева (dom)
не будет задефайнен его нельзя поместить в разметку?
вы писали что его надо дефайнить прямо сразу в том же жс выдав себя за боба;)
не будет задефайнен его нельзя поместить в разметку?
абсолютного решения этой проблемы без побочных эффектов не существует, используя другие компонентные ферймворки можно сделать что-то вроде статической сборки, но в этом случае у вас не будет модульности, а будет монолит, а это никому, кроме джунов вчера увидевших впервые рякт, не нужно. Все понимают, что любой вася может собрать хеловорлд СПА на рякте, вы сделайте что-бы у вас безконфликтно на экране работало и взаимодейтсвовало 5 инстансов рякта и столкнетесь со всеми теми же проблемами и решениями.
зачем мне инжекторы, если для меня это должен быть черный ящик из одного компонента?
бывают задачи шеринга некоторого кода или состояния между компонентами, можно пытаться ограничится одними эвентами, но это будет несколько экстенсивно
да нет тут более адекватного, да, на фоне фреймворков популярной тройки и даже фреймворков использующих веб-компоненты использование просто веб-компонентов может показаться близким к идеалу, конечно для этого на сегодняшний день местами надо приложить свои прямые руки. Например вебкомпоненты смотрятся гораздо хуже без современных нативных модулей, типобезопасности и других возможностей esnext и технологий
По моим измерениям – это не так. Не согласны – приводите свои замеры с цифрами.
тут достаточно просто понимать, что все ваши оптимизации и бетчинги выполняются в достаточно медленном рантайме джаваскрипта, и когда вы в нем делаете генерацию джаваскрипта, который всеравно будет засунут в реально дерево вы сами создаете себе проблему, которую потом не особо эффективно учитывая, что у вас еще и одно ядро процессора и поток решаете
это минифицированный код, который всеравно будет разбираться джаваскриптовым интерпретатором, в ваших кодах будут ссылки на методы «ядра» из этих библиотек, которые в интепретируемом языке будут делать бестолковые манпипуляции, если вы запускали хоть раз профайлер то видели, что он часто указывает на какую-то одну-две функции используемые повсеместно
Вот этих самых примеров мне и не хватает. Что вы имеете в виду?
реализации технологий веб-компонентов доступны в виде библиотек-заменителей для браузеров в которых они не реализованы, навроде интернет эксплорера 11 (получается то же что с фреймворками), если вы запустите код с билбиотеками, а потом их отключите в современном браузере полагаясь на нативную реализацию, разница в скорости работы может быть заметна без замеров.
Джордж задефайнил компонент date-select чтобы использовать его внутри компонента datetime-chooser, другого способа использовать веб-компонент не определено стандартом.
что-бы использовать одни элементы в других нет необходимости дефайнить их в строго определенном порядке, в этом крутизна веб-компонентов, что пока вы не задефайнили кастомный элемент браузер его просто пометил как неизвестный и пропустил
Во-первых, вы опять доказали, что сами по себе, веб-компоненты практически недееспособны, раз чтобы заюзать парочку компонентов нужно сверху крутить DI
крутить или не крутить решают разработчики ферймворка, вот вам не нравится — вы не крутите, а тот кто понимает зачем это и имеет опыт — прикрутит
Да, наверное это так, но в случае с веб-компонентами, система их регистрации делает практически невозможным реализацию подобной вещи, без участия конечного пользовательского кода.
так и где тут проблема? зато с участием можно сделать как угодно: я знаю минимум 2 способа несложно сделать это самому, есть готовые библиотеки-инжекторы, есть те или иные решения во фреймворках. В конце концов вы действительно можете решить, что вам хватит одних компонентов или глобальной персистанс системы типа редакса. Веб компоненты это набор технологий-стандартов, а не фреймворк и не библиотека.
это не верное пожелание, дело в том, что на сегодняшний день код на различных популярных фреймворках практически никак между собой не совместим и многие проекты переписываются ежегодно с нуля на очередной сомнительной распиаренной «технологии».
Веб компоненты в свою очередь стандартизированы в виде ряда технологий решающих разные задачи и дающих почти полную замену среднему фронтенд-фреймворку в сумме, также они реализованны во всех современных движках и браузерах, за счет этого они и работают тоже быстрее, не требуя в полифилинга, т.к. загрузки и выполнения лишнего жс кода на старте. Разница когда вы отключили жс-бибилиотеки заметна на глаз даже на простейших примерах.
дело в том, что вася и джорж не должны были делать дейфайн там же где объявлен код компонентов, т.к. это как раз таки означает использовать глобал в своих кодах или как-то еще безусловно хардкодить конфигурацию. Хотя им скорее всего показалось проще и быстрее делать именно так, как и делать верстку прямо в жс коде.
Сбутстрапить компоненты наинжектив им заодно зависимостей должен был некоторый общий код, какой-то аналог DI фреймворка, как в ангуляре или спринге, тогда и коллизиями можно было бы управлять. От них невозможно совсем избавится, есть частичные решения в виде выбора компонента на основе приоретизации или прямого связывания в конфигурации и алиясинга (который вы можете самостоятельно докрутить), но они подразумевают некоторый компромисс. Вобщем это та часть технологии, которая отдается на откуп фреймворкам и библиотекам я думаю.
этот тест не учитывает особенность реактоподобных фреймворков перерендеривать компоненты зря, например когда я открываю фейсбук у меня начинает расти потребление памяти до гигабайтов и паедаться до 5 % core i7 даже при бездействии
Есть ли реальные юз кейсы, где видно пользу от предлагаемого вами решения? Пока мне видны только минусы.
паттерны были разработаны на слезах и крови разрабатывающих как им кажется быстрее и прямо сейчас удобнее поэтому практические примеры подтверждающие правильность их использования разработчику должны по идее встречаться регулярно, ну может быть лично вам повезло работать только со своими нерасширяемыми велосипедами конечно и только писанными лучше вашего собственного уровня и только на задачах в русле возможностей и ограничений предпочитаемой технологии или системы, но мой опыт говорит об том, что технологии разработанные по сиюминутным представлениям не переживают активной фазы своих создателей, т.е. 1-3 лет развития, тот же жквери в свое время имел множество сторонников и претензий к нему на том уровне понимания задач было мало, а теперь никому кроме пенсов он не кажется хорошим решением
http-equiv=«X-UA-Compatible» content=«ie=edge»
весь этот пример основан на записи строки в которую интерполяцией подставляются значения через свойство .innerHTML, т.е. этот тест не проверяет веб-компоненты, а как максимум часть называющуюся Custom Elements, поэтому что если вы откроете любую статью или книгу про веб-компоненты вы там увидите и упоминания Native Templates т.е. шаблонов в теге template клонируемых в dom
ну svelte к ним точно сейчас не относится, ember наверное уже не относится, про preact я слышал только от поклонников реакта, так что тоже наврядли, действительно можно говорить только о трех фреймворках на сегодня
популярные фреймворки курируются корпорациями навроде фейсбука или гугла и сейчас на фронте все чаще популяризируются неудачные решения и идеи противоречащие принципам программной инженерии, такие как смешение бизнес-логики с версткой, отрицание ооп, игнорирование стандартов. Все современные популярные фреймворки развиваются поперек стандартизированных технологий, в том числе тех, что входят в группу веб-компонентов. Например ангуляр многим хорош, но шаблоны у него свои, а не нативные, и валидацию форм они сделали свою неудобную, когда есть отличное стандартизированное апи хтмл5. У остальных фреймворков проблем еще больше.
была проектная группа которая разрабатывала стандарты w3c, и html imports тоже предполагался, поэтому использовался в полимере, но он встретил сопротивление и был совсем отвергнут разработчиками фаерфокс например, а затем и вовсе не был утвержден как стандарт
какая-то странноватая придумка, импорт грамотнее будет сделан нативными модулями, а для роутинга можно использовать любую понравившуюся библиотеку, или вовсе не роутить а перерендеривать явно, из вашего примера не очень понятно сразу, что происходит
ну надо просто перестать воображать что проперти класса и атттрибуты это одно и тоже и все встанет на свои места. Вы сами правильно заметили, что аттрибуты поддерживают только примитивы (потому что они задаются литералами), а на класс можно присвоить все что угодно, в том числе экземпляры других классов
потому, что нейтив темплейты входят в группу стандартов объединенных термином, веб компоненты, а вы замеряете вставку строки с интерполяцией в dom и называете это веб-компонентами
строка включает движок эджа, зачем такое в тестах?
svelte не является популярным фреймворком, я имел ввиду react, vue, angular, если вы записанное простыми предложениями понять не можете я вам помочь ничем не смогу
у смертных не выполняющих стандарты шансов еще меньше, стандарт был не удачный и он не был принят, и разработка полимера была отменена, в отличии от большого количества неудачных решений популярных и не очень фреймворков.
я указал на подобие т.е. механизм импорта вермишели из js, стилей и разметки в html который я увидел в коде для вашего ферймворка, такой же применяется в .vue
полумер полагался на html imports, принятие которых в стандарт заблокировал как раз таки фаерфокс, т.е. там они скорее всего работают через полифил и жс рантайм, а в хроме нативно, вот вам и разница заметная на глаз. Как я понимаю, этот ваш Svelte использует какой-то такой же подход, который был по причинам нарушения принципа разделения ответственностей индустрией отвергнут. Лично мне, точно также кажется обилие странностей фреймворка неоправданным, что-бы завязываться на него. Классы-инстансы для хранения и линковки состояния я могу легко подключить в компоненты с инжектором если что-бы красиво или нехитрым собственным мета-кодом.
он не должен этого делать ни в каком случая, в этом сила веб-компонентов, что вы можете дефайнить компонеты потом в том числе и для динамического рендеринга
подмена это небезопасная коллизионная история, мне кажется так делать просто недопустимо, т.к. непонятно что делать с уже отрендеренными компонентами, непонятно почему ваши компоненты может кто-то подменить. Вы можете в частном порядке разрешать конфликты присваивая им другие тегнеймы.
вы лично может не хотите, а кому-то без этого не решить задачи. Основное назначение кода — быть расширяемым и дорабатываемым, и харкод в том числе конфигурации и бутстрапа эту возможность существенно ограничивает. По уму должны быть доступны оба варианта: у вас есть класс-компонент который вы можете сбиндить на любой тегнейм и у вас есть бутстрап для готового использования который конфигурирует его и биндит на определенный тегнейм. Есть библиотека что-бы расширять и переиспользовать и бандл что-бы просто подключить.
Вы можете также нагуглить публичные бенчмарки, я не знаю как они там мерили, но там в числе лидеров веб-компонентный Svelte (https://medium.com/@ajmeyghani/javascript-frameworks-performance-comparison-c566d19ab65b), но тут над понмимать, что этот фреймворк наворачивает свой mustache подобный шаблонизатор над нейтив темплейтами или вовсе без них в рантайме, т.е. занимается тем же бестолковым преобразованием строк в объекты дом с полнотекстовым поиском плейсхолдеров для замены вместо оптимизированного дерева (dom)
вы писали что его надо дефайнить прямо сразу в том же жс выдав себя за боба;)
абсолютного решения этой проблемы без побочных эффектов не существует, используя другие компонентные ферймворки можно сделать что-то вроде статической сборки, но в этом случае у вас не будет модульности, а будет монолит, а это никому, кроме джунов вчера увидевших впервые рякт, не нужно. Все понимают, что любой вася может собрать хеловорлд СПА на рякте, вы сделайте что-бы у вас безконфликтно на экране работало и взаимодейтсвовало 5 инстансов рякта и столкнетесь со всеми теми же проблемами и решениями.
бывают задачи шеринга некоторого кода или состояния между компонентами, можно пытаться ограничится одними эвентами, но это будет несколько экстенсивно
да нет тут более адекватного, да, на фоне фреймворков популярной тройки и даже фреймворков использующих веб-компоненты использование просто веб-компонентов может показаться близким к идеалу, конечно для этого на сегодняшний день местами надо приложить свои прямые руки. Например вебкомпоненты смотрятся гораздо хуже без современных нативных модулей, типобезопасности и других возможностей esnext и технологий
тут достаточно просто понимать, что все ваши оптимизации и бетчинги выполняются в достаточно медленном рантайме джаваскрипта, и когда вы в нем делаете генерацию джаваскрипта, который всеравно будет засунут в реально дерево вы сами создаете себе проблему, которую потом не особо эффективно учитывая, что у вас еще и одно ядро процессора и поток решаете
это минифицированный код, который всеравно будет разбираться джаваскриптовым интерпретатором, в ваших кодах будут ссылки на методы «ядра» из этих библиотек, которые в интепретируемом языке будут делать бестолковые манпипуляции, если вы запускали хоть раз профайлер то видели, что он часто указывает на какую-то одну-две функции используемые повсеместно
реализации технологий веб-компонентов доступны в виде библиотек-заменителей для браузеров в которых они не реализованы, навроде интернет эксплорера 11 (получается то же что с фреймворками), если вы запустите код с билбиотеками, а потом их отключите в современном браузере полагаясь на нативную реализацию, разница в скорости работы может быть заметна без замеров.
что-бы использовать одни элементы в других нет необходимости дефайнить их в строго определенном порядке, в этом крутизна веб-компонентов, что пока вы не задефайнили кастомный элемент браузер его просто пометил как неизвестный и пропустил
крутить или не крутить решают разработчики ферймворка, вот вам не нравится — вы не крутите, а тот кто понимает зачем это и имеет опыт — прикрутит
так и где тут проблема? зато с участием можно сделать как угодно: я знаю минимум 2 способа несложно сделать это самому, есть готовые библиотеки-инжекторы, есть те или иные решения во фреймворках. В конце концов вы действительно можете решить, что вам хватит одних компонентов или глобальной персистанс системы типа редакса. Веб компоненты это набор технологий-стандартов, а не фреймворк и не библиотека.
Веб компоненты в свою очередь стандартизированы в виде ряда технологий решающих разные задачи и дающих почти полную замену среднему фронтенд-фреймворку в сумме, также они реализованны во всех современных движках и браузерах, за счет этого они и работают тоже быстрее, не требуя в полифилинга, т.к. загрузки и выполнения лишнего жс кода на старте. Разница когда вы отключили жс-бибилиотеки заметна на глаз даже на простейших примерах.
Сбутстрапить компоненты наинжектив им заодно зависимостей должен был некоторый общий код, какой-то аналог DI фреймворка, как в ангуляре или спринге, тогда и коллизиями можно было бы управлять. От них невозможно совсем избавится, есть частичные решения в виде выбора компонента на основе приоретизации или прямого связывания в конфигурации и алиясинга (который вы можете самостоятельно докрутить), но они подразумевают некоторый компромисс. Вобщем это та часть технологии, которая отдается на откуп фреймворкам и библиотекам я думаю.
паттерны были разработаны на слезах и крови разрабатывающих как им кажется быстрее и прямо сейчас удобнее поэтому практические примеры подтверждающие правильность их использования разработчику должны по идее встречаться регулярно, ну может быть лично вам повезло работать только со своими нерасширяемыми велосипедами конечно и только писанными лучше вашего собственного уровня и только на задачах в русле возможностей и ограничений предпочитаемой технологии или системы, но мой опыт говорит об том, что технологии разработанные по сиюминутным представлениям не переживают активной фазы своих создателей, т.е. 1-3 лет развития, тот же жквери в свое время имел множество сторонников и претензий к нему на том уровне понимания задач было мало, а теперь никому кроме пенсов он не кажется хорошим решением