А сейчас даже Parcel люди не знают (или боятся), хотя он исправляет то, за что все критикую Вебпак (отвратительный DX с кучей конфигов).
Мой опыт с Parcel'ом: недавно исправлял issue в библиотеке от пользователя parcel'а с тем что он не умеет подставлять значения во время сборки (DefinePlugin в вебпаке или rollup-plugin-replace в роллапе), заменил на process.env. которые parcel умеет. Дальше собираю демонстрационный проект с флажком для scope hoisting'а, прохожусь prettier'ом по собраному файлу чтоб посмотреть во что он там насобирал и с печалью вижу что у него проблемы с примитивным tree shaking'ом на уровне webpack'а и он не выкидывает кучу неиспользуемых функций.
У меня нет глубокого понимания на тему внутренностей бандлеров, возможно у Parcel'а правильная архитектура итд, но на данный момент меня совершенно не устраивает тот бандл, который он генерирует.
То же самое с Vue — все критикую Реакт что там ничего не понятно и сторонние библиотеки (типа роутера) плохие, но продолжают боятся Vue (так как он не мейнстрим).
Небольшая история о том как развивался Vue: когда-то давно(после выхода реакта) я и ещё один человек работали над библиотеками, реализующими vdom алгоритмы и очень сильно задротствовали на тему производительности, на тот момент мы не понимали очень много мелочей о том как правильно должен работать реконсайлер, где-то через пол года появился ещё один разработчик который написал свою ещё более примитивную библиотеку, которую он делал глядя в наши исходники и естественно понимал ещё меньше о том как правильно должен работать реконсайлер(худшая библиотека на тот момент в плане поведения), потом появился Vue2, который использовал исходники этой примитивной библиотеки с добавлением своих костылей :) В итоге vue вобрал в себя ужасные идеи, которые я использовал в своих старых поделках + примитивный дифф алгоритм с кучей заплаток для эдж кэйсов, о которых все кроме авторов Реакта даже не догадывались в 2016ом.
Виноваты авторы Реакта в том что у них есть большой багаж знаний и они понимают что невозможно сделать "one size fits all" решение и поэтому не пихают всё подряд в свою библиотеку? Может кому-то со стороны кажется что это всё недостатки реакта, но большинство критики реакта связано с отсутствием глубокого понимания предметной области.
Реакт есть за что критиковать и разработчики реакта часто умышленно умалчивают о различных недостатках своих решений, но приводить в пример Vue как решение проблем React'а — сомнительная затея.
> а вы уверенны, что это внутреннее состояние компонентам необходимо?
пусть будет внутреннее состояние элементов: css анимации, позиция скролла, позиция курсора в инпут полях, документ в ифрэйме, медиа элементы и куча других кэйсов.
Причём тут расширить? Это простой пример когда приходит снэпшот данных и нужно обновить DOM структуру, не теряя внутреннее состояние. ~60 строчек кода на любой современной библиотеке, вот к примеру тоже самое на React[1]. Реализуйте тоже самое поведение без использования библиотек вроде lit-html, это ведь так легко «когда есть геттеры/сеттеры и прокси».
> и задачи биндинга и рендеринга можно решить без архитектурно-алгоритмических ухищрений
Традиционный клиент-сервер юзкэйс когда сервер отправляет снэпшоты данных невозможно решить без дифф алгоритма, тк отсутствуют какие-либо данные о том как нужно переставлять дом элементы чтобы прийти к конечному состоянию. Если будете обновлять с помощью innerHTML, то потеряете внутреннее состояние всех компонентов.
> вообще я сделал такой же точно по входным тербованям пример на реякте (вызывал инкремент у редакса)
То что вы сделали на реакт+рекдакс скорее всего отрабатывало инкремент экшен в редаксе, вызывало синхронный запуск реконсайлера и обновление DOM элемента миллион раз. Не понимаю что вы там пытались протестировать таким образом, не существует реальных юзкэйсов когда нужно обрабатывать много различных редакс экшенов за один фрэйм, такое ощущение что вы не понимаете как используется redux.
Что это за странный юзкэйс? Зачем вы трогаете innerHTML у одного элемента 1 миллион раз за фрэйм. Все современные декларативные библиотеки умеют батчинг.
Беру тормозной virtual dom, традиционный бэнчмарк с кучей апдэйтов dbmonster[1], смотрю на профайлер в хроме и вижу «85.72% (program)». Чо оптимизировать то?
У lit-html как минимум есть смысл в том чтоб проверить теорию о том насколько эффективно такой подход будет работать на кэйсах с маленьким количеством динамических биндингов (простые веб приложения). Но на данный момент они как-то умудрились в этом бэнчмарке[1] во всех тестах показывать результаты хуже чем у vdom библиотеки, хотя в этом бэнчмарке они должны быть в выигрышном положении так как здесь практически нет динамических биндингов, не требуется использовать композицию и можно просто клонировать большой кусок dom'а и в дополнение они ещё абузят event delegation[2].
Тем не менее, вы сами можете все легко проверить: lit-element.polymer-project.org/guide/start
К сожалению полимеровцы так же любят рассказывать о высокой производительности, но при этом никогда не показывают реальных цифр :) С нетерпением жду вашей статьи с реальными цифрами.
все vdom реализации как минимум предоставляют два примитива: динамический список чилдренов и динамические атрибуты. Первое в lit-html есть, второе отсутствует https://github.com/Polymer/lit-html/pull/213 .
> Также, именно по этой причине, любой фреймворк, основанный на близком подходе будет медленнее примерно раза в 2 (и больше) чем при использовании нативного парсинга шаблона до вставки элемента на страницу.
Можете продемонстрировать это на каком-нибудь примере?
У него идея в том что если мы создадим очень быстрый реконсайлер, то не нужно будет замарачиваться со всякими redux'ами/mobx'ами и можно будет просто при каждом изменении делать полный ререндер и вынимать данные откуда угодно. Поэтому он в этом бенчмарке не использует `sCU`, а делает полный ререндер. Но это только про полный ререндер, в остальном же я полностью согласен с тем что реализация на реакте оч корявая.
Автор пытался протестировать скорость реконсайлера и поэтому при каждом изменении всё рендерится целиком. А так да, реализация бенчмарка на реакте там какая-то совсем корявая. Года 3 назад он ещё использовал ресайклинг в реализации на Имбе и делал заявления что Имба в 40 или 60 раз быстрее Реакта, печально что чувак за эти годы так ничему и не научился.
А ещё в Imba есть крутая фича как отсутствие компонентов, так что можете забыть о композиции даже на уровне реакта в 2014ом. Наконец-то вы сможете насладиться любимым ООП и наследоваться от DOM элементов :)
Так же там поддерживается возможность хранить в памяти все элементы, которые никак не используются после того как они удалены из документа, но к сожалению там предусмотрены примитивные эвристики, которые при совсем большом засирании начнут подчищать неиспользуемые элементы. Это конечно не так круто как в современной реализации нового Gmail'а когда даже из документа не вычищаются неиспользуемые элементы, но раз уж Gmail использует подобные техники, то наверно это должно значительно улучшить производительность :)
И невероятная производительность Имбы, которая на порядки быстрее виртуального дома подтверждается даже на других корявых бэнчмарках (полный ререндер без каких-либо `shouldComponentUpdate` оптимизаций):
Мой опыт с Parcel'ом: недавно исправлял issue в библиотеке от пользователя parcel'а с тем что он не умеет подставлять значения во время сборки (
DefinePluginв вебпаке илиrollup-plugin-replaceв роллапе), заменил наprocess.env.которые parcel умеет. Дальше собираю демонстрационный проект с флажком для scope hoisting'а, прохожусь prettier'ом по собраному файлу чтоб посмотреть во что он там насобирал и с печалью вижу что у него проблемы с примитивным tree shaking'ом на уровне webpack'а и он не выкидывает кучу неиспользуемых функций.У меня нет глубокого понимания на тему внутренностей бандлеров, возможно у Parcel'а правильная архитектура итд, но на данный момент меня совершенно не устраивает тот бандл, который он генерирует.
Небольшая история о том как развивался Vue: когда-то давно(после выхода реакта) я и ещё один человек работали над библиотеками, реализующими vdom алгоритмы и очень сильно задротствовали на тему производительности, на тот момент мы не понимали очень много мелочей о том как правильно должен работать реконсайлер, где-то через пол года появился ещё один разработчик который написал свою ещё более примитивную библиотеку, которую он делал глядя в наши исходники и естественно понимал ещё меньше о том как правильно должен работать реконсайлер(худшая библиотека на тот момент в плане поведения), потом появился Vue2, который использовал исходники этой примитивной библиотеки с добавлением своих костылей :) В итоге vue вобрал в себя ужасные идеи, которые я использовал в своих старых поделках + примитивный дифф алгоритм с кучей заплаток для эдж кэйсов, о которых все кроме авторов Реакта даже не догадывались в 2016ом.
Виноваты авторы Реакта в том что у них есть большой багаж знаний и они понимают что невозможно сделать "one size fits all" решение и поэтому не пихают всё подряд в свою библиотеку? Может кому-то со стороны кажется что это всё недостатки реакта, но большинство критики реакта связано с отсутствием глубокого понимания предметной области.
Реакт есть за что критиковать и разработчики реакта часто умышленно умалчивают о различных недостатках своих решений, но приводить в пример Vue как решение проблем React'а — сомнительная затея.
Надо отметить, что это отличный способ добавлять XSS уязвимости.
Создание замыканий не такая уж и проблема, а вот то что многие начнут писать код с утечками памяти из-за closure context sharing'а — это печально.
пусть будет внутреннее состояние элементов: css анимации, позиция скролла, позиция курсора в инпут полях, документ в ифрэйме, медиа элементы и куча других кэйсов.
1. github.com/localvoid/uibench-react/blob/master/js/fc.jsx
1. github.com/localvoid/uibench-lit-html/blob/0fab2ca944c5dc585bc5c595ff43d7a0f0fc289a/src/main.js
Традиционный клиент-сервер юзкэйс когда сервер отправляет снэпшоты данных невозможно решить без дифф алгоритма, тк отсутствуют какие-либо данные о том как нужно переставлять дом элементы чтобы прийти к конечному состоянию. Если будете обновлять с помощью innerHTML, то потеряете внутреннее состояние всех компонентов.
То что вы сделали на реакт+рекдакс скорее всего отрабатывало инкремент экшен в редаксе, вызывало синхронный запуск реконсайлера и обновление DOM элемента миллион раз. Не понимаю что вы там пытались протестировать таким образом, не существует реальных юзкэйсов когда нужно обрабатывать много различных редакс экшенов за один фрэйм, такое ощущение что вы не понимаете как используется redux.
1. localvoid.github.io/ivi-examples/benchmarks/dbmon/?m=1
А чо спорить то, делаете громкие заявления — как минимум показывайте синтетические тесты с цифрами.
1. krausest.github.io/js-framework-benchmark/current.html
2. github.com/krausest/js-framework-benchmark/blob/e469a62889894cb4d4e2cac5923f14d91d1294f8/frameworks/keyed/lit-html/src/index.js#L126
К сожалению полимеровцы так же любят рассказывать о высокой производительности, но при этом никогда не показывают реальных цифр :) С нетерпением жду вашей статьи с реальными цифрами.
все vdom реализации как минимум предоставляют два примитива: динамический список чилдренов и динамические атрибуты. Первое в lit-html есть, второе отсутствует https://github.com/Polymer/lit-html/pull/213 .
Можете продемонстрировать это на каком-нибудь примере?
Тут даже хуже, человек не владеет жаваскриптом, тк для композиции в реакте не нужно изучать реакт.
Так же там поддерживается возможность хранить в памяти все элементы, которые никак не используются после того как они удалены из документа, но к сожалению там предусмотрены примитивные эвристики, которые при совсем большом засирании начнут подчищать неиспользуемые элементы. Это конечно не так круто как в современной реализации нового Gmail'а когда даже из документа не вычищаются неиспользуемые элементы, но раз уж Gmail использует подобные техники, то наверно это должно значительно улучшить производительность :)
И невероятная производительность Имбы, которая на порядки быстрее виртуального дома подтверждается даже на других корявых бэнчмарках (полный ререндер без каких-либо `shouldComponentUpdate` оптимизаций):
— Imba: localvoid.gitlab.io/imba-dbmon/?m=0.001
— vdom: localvoid.github.io/ivi-examples/benchmarks/dbmon-raw/?m=0.001
Хотя нет, чота не подтверждается.