Да, нативное всегда лучшее, согласен, но проблема CustomElements в том, что они регистрируются на глобальном уровне и иногда это мешает. Я некоторое время назад (лет восемь наверное прошло :) ) занимался поставкой достаточно сложных виджетов на клиентские сайты, и было бы очень не православно гадить в глобальную область видимости своими кастомными тегами переключателей, слайдеров и прочей мелочью (которой было достаточно много).
Собственно жизненный цикл это всего шесть хендлеров и требование пользоваться специальными (нестандартными) методами компонентов в пределах приложения, никаких других проблем.
//hello-world component
<div as="hello-world">
<h1 ref="content"></h1>
<input ref="input" placeholder="type your name here">
<h2>Hello <span ref="name">Anonimous</span>!</h2>
<script type="javascript">
var me=this;
this.ref.input.oninput = function(e){
me.setData(me.ref.input.value);
};
this.onSetData = function(data){
me.ref.name.innerText = data || 'Anonimous';
};
</script>
</div>
//root of app
<div as="double-hello-world">
<hello-world>Hello first</hello-world>
<hr>
<hello-world>Hello second</hello-world>
</div>
И никакого повторяющегося кода :)
А CustomElements очень хороши для изоляции стилей и красивой установки виджета, тогда приходилось с этим приседать и наклоняться ;).
Прочёл все Ваши статьи и заметил что с каждой итерацией Symbiote становится всё больше похож на W3View, который существует уже с 2016 года практически без изменений.
Осталось только отказаться от использования CustomElements в качестве основы для внутренней компоновки, ну и пройтись бритвой Оккама по всяким модным двусторонним связываниям - this.ref - вполне достаточен.
В целом этот тренд всецело поддерживаю - HTML, CSS и JS - это всё что нужно для построения приложений любой сложности.
Хотите сказать что Virtual DOM чудесным образом уменьшает это все при добавлении одной ноды в дерево?
Я открывал профилировщик и сравнивал React с одной мало известной библиотекой - результат время на рендеринг без изменений, процессор и память в разы больше утилизируются при использовании Virtual DOM
Virtual DOM был придуман не для оптимизации перерисовки, а для того чтобы натянуть сову на глобус - заменить innerHTML и продолжать генерить страницы как привыкли.
И пусть REACT, на мой взгляд, не шибко хорошо демонстрирует эту идеологию, зато, в своё время, он был одним из первых, кто решил вернуть программистов сайтов с императивного пути массового внедрения JavaScript на путь декларативного программирования
коллеги опять перепутали декларативное программирование и декларативный язык разметки :)
:) я придумал — w3view, он обходится без темплет. HTML и JS разделены но код связный, компоненты настоящие, работает быстрее чем react, покрывает 100% потребностей и провоцирует декомпозицию, куда прийти за миллиардом?
Мы может быть и разные, но тараканы у нас одинаковые, универсального решения на все случаи жизни нет и быть не может.
Чем больше на себя берёт библиотека или фреймворк, тем уже скоуп решаемых задач и больше навязываемых ограничений.
Ой, я всё пропустил, ;)
На мой частный взгляд основная проблема современных библиотек и фреймворков на js заключается в попытке управлять живыми объектами через «поток вывода» (шаблонизатор) и игнорирование всего предыдущего опыта программирования пользовательских интерфейсов.
Как вы думаете, отчего в мире java, например, не появляются каждый год десятки новых JFX?
— Оттого, что JFX решает ВСЕ поставленные задачи, не навязывает вместе с костылями никаких ограничений и вообще ведёт себя прилично.
Отчего в мире JS так упорно отказываются от прямого использования DOM?
— Оттого, что в голове у JS разработчиков плотно засел HTML и они не могут представить себе как можно отказаться от шаблонизации.
Мы всё ещё плотно заняты поиском идеальной серебряной пули, которая убьёт всех без исключения монстров, хотя остальной мир давно понял что чудес не бывает и спокойно продолжает использовать MVC и его производные по вкусу и в зависимости от решаемых задач.
В общем, я плавно подвёл вас дорогие товарищи к w3view, о котором мною была написана пара статей на хабре :). Хотите развития, расширяйте кругозор :).
За сим разрешите откланяться.
PS замечательная фраза «Вам все так же надо вручную думать»
сигнал мне — о том, что пример с todomvc, возможно, сложноват для первого знакомства, и надо было начинать с чего-то попроще
Это кагбе сигнал о том что с dap что-то не так. Задачка простая, на вечерок на любом известном фреймворке, и на неизвестном тоже :) и безо всякого фреймворка тоже на вечерок-два.
И кстати дап вообще не про функции-хелперы
А про что dap?
Вы так и не рассказали в чём профит от использования именно dap, по сравнению с тем-же React или Vue, что в нём не такого как в React (кроме маленького футпринта)?
Пока, после трёх статей, у меня например впечатление, что для работы с dap необходимо родиться хотя бы на столько-же гениальным как Вы, ну или пройти обучение в Хогвардсе.
Кстати как обстоят дела с 75к ( в прямом и переносном смысле )?
Да, чтобы Сберовские получить — надо постараться, я чеки не выписываю.
Список того, что я называю "весь фунуционал" распределён между десятками команд, и он постоянно растёт — agile, как ни как :)
Собирать его ради пепла мне ни к чему, но Вы можете открыть новую версию приложения и ознакомиться с ним.
«Да могу в 75кБ» — Вы уже сказали, но это громкое заявление и за него нужно отвечать.
Извинений я не просил, а требовал, поскольку Вы не захотели отвечать за свои слова.
Пепла на Вашей голове в данный момент вполне достаточно, просто Вы его не в состоянии заметить.
Хвалебные статьи Ваши тоже никому не нужны.
Лучше напишите статью про Ваше замечательное оборудование и что оно делает, это всем будет гораздо интереснее чем никому (и Вам в том числе) не нужный dap.
А сейчас Ваш UPD Выглядит как те пресловутые 75кБ.
Ну тут дело сложное :) человек не «подписывался» приходить за деньгами сам, отказывается от единственного возможного способа получить доступ к mAPI и прочей документации.
Да, нативное всегда лучшее, согласен, но проблема CustomElements в том, что они регистрируются на глобальном уровне и иногда это мешает.
Я некоторое время назад (лет восемь наверное прошло :) ) занимался поставкой достаточно сложных виджетов на клиентские сайты, и было бы очень не православно гадить в глобальную область видимости своими кастомными тегами переключателей, слайдеров и прочей мелочью (которой было достаточно много).
Собственно жизненный цикл это всего шесть хендлеров и требование пользоваться специальными (нестандартными) методами компонентов в пределах приложения, никаких других проблем.
И никакого повторяющегося кода :)
А CustomElements очень хороши для изоляции стилей и красивой установки виджета, тогда приходилось с этим приседать и наклоняться ;).
Прочёл все Ваши статьи и заметил что с каждой итерацией Symbiote становится всё больше похож на W3View, который существует уже с 2016 года практически без изменений.
Осталось только отказаться от использования CustomElements в качестве основы для внутренней компоновки, ну и пройтись бритвой Оккама по всяким модным двусторонним связываниям - this.ref - вполне достаточен.
В целом этот тренд всецело поддерживаю - HTML, CSS и JS - это всё что нужно для построения приложений любой сложности.
Успехов
Вообще-то виртуал дом это оптимизация innerHTML и с ним заведомо медленнее чем с натуральным DOM
Маленькое уточнение - JS начинает работать не после загрузки страницы а в процессе
Хотите сказать что Virtual DOM чудесным образом уменьшает это все при добавлении одной ноды в дерево?
Я открывал профилировщик и сравнивал React с одной мало известной библиотекой - результат время на рендеринг без изменений, процессор и память в разы больше утилизируются при использовании Virtual DOM
Virtual DOM был придуман не для оптимизации перерисовки, а для того чтобы натянуть сову на глобус - заменить innerHTML и продолжать генерить страницы как привыкли.
которой нет
Отличная была практика, отказ от нее привел к тому, что верстальщики решили что они стали программистами.
коллеги опять перепутали декларативное программирование и декларативный язык разметки :)
Чем больше на себя берёт библиотека или фреймворк, тем уже скоуп решаемых задач и больше навязываемых ограничений.
На мой частный взгляд основная проблема современных библиотек и фреймворков на js заключается в попытке управлять живыми объектами через «поток вывода» (шаблонизатор) и игнорирование всего предыдущего опыта программирования пользовательских интерфейсов.
Как вы думаете, отчего в мире java, например, не появляются каждый год десятки новых JFX?
— Оттого, что JFX решает ВСЕ поставленные задачи, не навязывает вместе с костылями никаких ограничений и вообще ведёт себя прилично.
Отчего в мире JS так упорно отказываются от прямого использования DOM?
— Оттого, что в голове у JS разработчиков плотно засел HTML и они не могут представить себе как можно отказаться от шаблонизации.
Мы всё ещё плотно заняты поиском идеальной серебряной пули, которая убьёт всех без исключения монстров, хотя остальной мир давно понял что чудес не бывает и спокойно продолжает использовать MVC и его производные по вкусу и в зависимости от решаемых задач.
В общем, я плавно подвёл вас дорогие товарищи к w3view, о котором мною была написана пара статей на хабре :). Хотите развития, расширяйте кругозор :).
За сим разрешите откланяться.
PS замечательная фраза «Вам все так же надо вручную думать»
Это кагбе сигнал о том что с dap что-то не так. Задачка простая, на вечерок на любом известном фреймворке, и на неизвестном тоже :) и безо всякого фреймворка тоже на вечерок-два.
А про что dap?
Вы так и не рассказали в чём профит от использования именно dap, по сравнению с тем-же React или Vue, что в нём не такого как в React (кроме маленького футпринта)?
Пока, после трёх статей, у меня например впечатление, что для работы с dap необходимо родиться хотя бы на столько-же гениальным как Вы, ну или пройти обучение в Хогвардсе.
Кстати как обстоят дела с 75к ( в прямом и переносном смысле )?
Список того, что я называю "весь фунуционал" распределён между десятками команд, и он постоянно растёт — agile, как ни как :)
Собирать его ради пепла мне ни к чему, но Вы можете открыть новую версию приложения и ознакомиться с ним.
«Да могу в 75кБ» — Вы уже сказали, но это громкое заявление и за него нужно отвечать.
Извинений я не просил, а требовал, поскольку Вы не захотели отвечать за свои слова.
Пепла на Вашей голове в данный момент вполне достаточно, просто Вы его не в состоянии заметить.
Хвалебные статьи Ваши тоже никому не нужны.
Лучше напишите статью про Ваше замечательное оборудование и что оно делает, это всем будет гораздо интереснее чем никому (и Вам в том числе) не нужный dap.
А сейчас Ваш UPD Выглядит как те пресловутые 75кБ.
Чтобы неплохо заработать надо для начала слезть со своей голубятни или открыть наконец глаза.
Просто интересно, сколько времени Вы готовы потратить на эти 75кБ кода и что для Вас значит «неплохо заработать»
Ну я не настолько кровожаден, чтобы настаивать.
Я прямо в понедельник начну организовывать для Вас конференцию.