Комментарии 79
Web Components — не хватало дробления на "изолированные кусочки", серьезно? Web Components — это и есть изолированные кусочки, и это самое крутое, что сейчас есть для декомпозиции интерфейса. И все, кто реализует поддержку веб-компонентов в своей инфраструктуре (тот же Angular например) — делают абсолютно правильно. Про скорость virtual DOM читать уже смешно, учитывая что обычный DOM никуда не делся, а отделение обсерверов от непосредственной работы с DOM и оптимизации вызова рендер-методов компонентов — это совсем не исключительно Реактовская "магия" а просто принцип хорошей архитектуры в любой экосистеме. Зачем вообще писать про изоморфность, когда "рельсовое" API на сервере? Потому, что "Изоморфность" — просто умное слово? Какую задачу оно может решить эффективно? На практике там сплошная боль. Надоели уже эти дифирамбы Реакту, которые исключительно дань моде, и не содержат никакой ценной информации в инженерном плане.
Потому, что «Изоморфность» — просто умное слово? Какую задачу оно может решить эффективно?
Airbnb топит за «изоморфность» в том же смысле что автор — один js-код рендерит html на сервере (в ноде) и на клиенте в зависимости от контектста вызова. Для поисковых crawler-ов это, как будто, хорошо — индексируют ровно то что видит пользователь и не нужно дублировать логику рендера на сервере. Почему вам не нравится?
Я прекрасно знаю что это такое, как и то, что в реальных проектах использовать реактовский рендер на сервере — ужасно медленно и в целом бессмысленно если у вас SPA: времени больше тратиться больше на запрос к серверу чем на загрузку бандла (это если цель — сделать пререндер а потом его "оживить"). В том то и дело, что необходимо дублировать логику на сервере (иначе кто и как там страницу отрендерит?), но продублировать ее полностью идентично клиентскому приложению у вас не получится, там огромное количество нюансов (роутинг, пользовательские данные и т. д.). Добавьте сюда отдельную песню с кэшированием (при работе с фильтрами и сортировками каталогов, к примеру) и получите разумные сомнения в целесообразности такого подхода и преимуществ его перед другими. Но допустим, я просто не встречал нормальной реализации изоморфности (хотя я считаю, что это лучше делает тот-же Meteor но там эта история больше про данные), может мне кто-то расскажет о своем успешном кейсе, как-то за рамками булшит-маркетинга? Чтобы было понятно какая задача решалась и насколько успешно решилась в итоге? Да еще и с Реактом? Что там на эту тему есть у Airbnb? С удовольствием такое почитаю.
Вот я и говорю, сейчас модно говорить с умным видом "изоморфность", или там "персистентность", а в реале мало кто понимает зачем это все. Обидно, что стек технологий потом выбирается в соответствии с этой модой, и потом ты вдруг слышишь от реактовских фанбоев про то, что веб-компоненты это отстой или умение эффективно работать с DOM это не тру, есть ведь волшебный Virtual DOM! На этом фоне я постепенно становлюсь хейтером Реакта, хотя изначально работать мне с ним, в целом, нравилось.
https://twitter.com/TLobinger/status/710544845153107968/ — улыбнуло =) Вот как после такого относиться к этому фреймворку серьезно?
По пунктам:
- серверный рендеринг — любым удобным способом, веб-компоненты это же валидный HTML, их не нужно преобразовывать к какому-то другому HTML (в отличие от чего-то типа JSX).
- движки шаблонов — аналогично, никаких проблем, особенно простыни из дамб-компонентов (без логики, что нам, собственно и нужно получать с сервера)
- организация в папках — в чем проблема? Сейчас пилю приложение на компонентах, все в папках, я что-то неправильно понимаю?
- использование NPM — в чем проблема? Хоть mpm, хоть Bower хоть через git, как угодно
- про авто-дискавер — это еще про что? Определения компонентов доступны в поиске проекта их экземпляры видны в DOM, что они имели в виду?
- shadow DOM — это да, компоненты могут
Похоже ребята не очень хорошо понимают о чем говорят.
Хотите индексации? Делайте так: <my-component>Hello!</my-component> Хотите логики? Делайте так: <my-component component-data='{«myAttribute»: «Hello!»}'></my-component> Внутри — ванильный яваскрипт. Прогрессивная загрузка — не проблема, html-импорты дают мне полную гибкость в этом вопросе. В итоге мне нужен только внятный API для работы с данными. И тут я предпочту решение на чем-то более производительном, типа Go.
Признаюсь, доклад пока не смотрел, возможно ответ там есть.
- У меня нет никаой необходимости рендерить внутренние шаблоны дамб-компонентов на сервере для индескации, все индексируется и так. И у меня нет необходимости получать пререндер с сервера для SPA, мне нужны только голые данные.
- Я прекрасно знаю что такое движки шаблонов и какие они бывают, и все еще не вижу особых проблем в их использовании в сочетании с веб-компонентами. Для индексации — вполне рабочий вариант.
- Мои компоненты — повторяюсь — это папки с шаблонами, стилями и их логикой. Можно публиковать и все прочее делать. Подключаются в бандл одной строчкой, не автоматически (это конечно большой недостаток, сарказм).
Аналогичный совет про рисеч в области веб-компонентов, у меня крепнет уверенность, что вы очень поверхностно с ними знакомы.
Я никоим образом не хотел вас задеть, респект вам и уважуха за ваш фреймворк. Милый котик, позитив, все дела. Однако, вы хорошо должны понимать, что фреймворков и подходов при использовании каждого из них сейчас довольно много. И далеко не каждый из них оправдает время, потраченное на изучение. Все во многом зависит от конкретных задач, потребностей, технических и бизнес-предпосылок. Веб-компоненты позволяют, лично мне, довольно комфортно заниматься разработкой онлайн-редакторов реального времени (для всяких замороченых, сложных и скучных корпоративных таблиц и форм). На текущий момент, именно они дают мне лучший экспириенс, хотя до этого я имел дело далеко не только с ними. И когда мне что-то советуют, я стараюсь получить детальное представление о том, что я получу и чем я за это заплачу. Открывая вашу ссылку я вижу следующее прямо в центре лендинга (уж не знаю насколько это вырвано из контекста): Cat-Components – similar to web-components but organized as directories, can be rendered on the server and published/installed as NPM packages. И это меня сильно смущает, потому как все абсолютно тоже самое можно делать и с веб-компонентами (и я это делаю каждый день), и это "but" — выглядит очень странно. Еще мне предлагают посмотреть как легко я могу все установить через npm — замечательно. Но зачем? Еще мне рассказывают про прогрессивный рендеринг — и я сравниваю это с возможность абсолютно свободно работать с API и слоем данных из любого своего модуля и снова не понимаю зачем мне для этого рисерчить другое решение. Если во главу угла поставить изоморфность, то чем ваш фреймворк лучше того-же Meteor? Мне это сходу не понятно, а вы говорите весьма сомнительные, с моей точки зрения, конечно, вещи. Может стоит все это как-то более вкусно подать? Так, чтобы зацепить чем-то осязаемо-рациональным (производительностью там, к примеру)?
2) push из http2 используете?
Web Components — это и есть изолированные кусочки, и это самое крутое, что сейчас есть для декомпозиции интерфейса.
Веб компоненты не исключают реакта и можно их сочетать.
учитывая что обычный DOM никуда не делся, а отделение обсерверов от непосредственной работы с DOM и оптимизации вызова рендер-методов компонентов — это совсем не исключительно Реактовская "магия" а просто принцип хорошей архитектуры в любой экосистеме
Преимущество виртуального DOM в том, что это встроено в библиотеку, а не реализуется каждый раз, как, например, при оптимизации директив в Ангуляре.
Надоели уже эти дифирамбы Реакту, которые исключительно дань моде, и не содержат никакой ценной информации в инженерном плане.
Немного преимуществ Реакта:
- Нормальная работа с модульностью. Модули Ангуляр 1 не очень хорошо сочетаются с модульностью Javascript, т.к. объявляются и регистрируются в разных местах (ну или в одном, но тогда нужно следить, чтобы модуль был создан, ну или городить отложенную регистрацию).
- Нормальная работа с children (по сравнению с Ангуляром). Нормальная — в смысле на уровне абстракций фреймворка, а не на уровне DOM.
- Проверка шаблонов. В Реакте с TypeScript возможна компайл-тайм валидация шаблонов. В Ангуляре 1 шаблоны это просто строки, даже в рантайме не всегда валится ошибка. В Ангуляре 2 вроде чуть получше с этим, но тоже строки.
Веб-компоненты просто делают Реакт и всю его экосистему избыточной сущностью. Незачем сочетать, ибо делают одно и то-же по сути.
Ну частично да, согласен. Но, например, умный патчинг DOM на чистых веб-компонентах не реализуешь.
Это вы про обращение через react-id? А что тут умного, поясните? Во первых, подобное можно легко реализовать в компонентах, а во вторых, я предпочитаю прямые подписки через коллекции ссылок на DOM-элементы, которые формируются при рендере моделей компонентов (да, это нечто вроде virtual-DOM). Это позволяет делать прямой вызов методов вложенных компонентов и, как и в Реакте, делать рендер данных без лишних перерисовок.
Любопытно будет взглянуть на то как вы будете обновлять DOM прямыми вызовами при изменении формы поддерева, так чтоб не терять внутреннее состояние (css анимации итп).
А в чем именно вы видите тут проблему? Поясните пожалуйста подробнее.
И где я предлагал это делать без абстракций? Вот прямо в той цитате из моего коммента, которую вы привели, именно об этих абстракциях и написано. И эти абстракции — довольно просты, ибо это просто коллекции элементов. Лично я — всегда так делаю, и не вижу особых проблем. Мне точно не нужен для этого Реакт и весь зоопарк его зависимостей.
Посмотрите Rionite, это как раз попытка прилепить реактивные биндинги к кастомным элементам. Есть ещё набор компонентов на этой библиотечке: jsfiddle. Всё это пока малость сырое конечно, но ощущения от использования на реальном проекте реально здоровские, даже после реакта. Плюс всё это ещё и довольно шустрое получается: js-repaint-perfs .
Гораздо тормознее виртуального дома http://localvoid.github.io/kivi-dbmonster/
Но быстрее его реализации в реакте)) И мне одному кажется, что этот тест очень удобен для виртуального дома? В реальном интерфейсе обычно несколько тысяч активных биндингов и при каком-то действии пользователя меняются лишь несколько (1-10) из них. Именно меняются, не создаются/удаляются. Либо пользователь переключает раздел и тогда как-раз происходит массовое создание/удаление биндингов и опять же обновление лишь нескольких из них. Думаю если приблизить этот тест к реальности, то библиотеки с "точечными" биндингами (Rionite, rivets, ...) оставят далеко позади даже самые быстрые реализации виртуального дома.
Да, одному, можете выставить кол-во мутаций на 1% и будет worst case для виртуального дома. Этот бенчмарк плохой по совершенно другим причинам, например тк там упоротый счётчик фпс.
>Думаю если приблизить этот тест к реальности, то библиотеки с «точечными» биндингами (Rionite, rivets, ...) оставят далеко позади даже самые быстрые реализации виртуального дома.
Берём какой-нибудь mobx+react и получаем тысячи implicit granular per-value observer'ов. Просто те у кого опыта побольше, те знают как такие решения сосут на всяких дататэйблах, ну там где обычно узкие места в реальных приложениях ;)
В любом случае, скорости более чем хватает для реального проекта. Текущий проект, кстати, начинал на связке cellx+React, и уже на первом разделе были два места где немного притормаживало по вине реакта, позже начал с нуля на Rionite, доделываю второй раздел, пока всё летает)). Большой дататейбл тоже есть, как раз в том самом первом разделе. Проблема виртуального дома в том, что он вынужден считать дифф самого компонента и всех дочерних компонентов, и если рядом с обновляемым кусочком лежит какой-нибудь селект с несколькими тысячами опций (как-раз первое место с тормозами, селект был с городами) или что-нибудь в этом духе, то ему прийдётся всё это просмотреть. Тут, конечно, есть решения, но все они костыли по сути.
На счёт mobx не знаю, но на этом бенчмарке он в 10 раз медленнее cellx-а.
Ничего он не должен, если входящие данные не изменились, то можно ничего не диффать. А как уже узнавать о том что изменились — это уже выбирать в зависимости от проблемы. Если хочется вешать кучу обсерверов, то добавляем dirty флаг и обновляем только когда компонента грязная, хочется проверять входящие данные от парента, то либо используем immutable данные, либо используем внутренние часики и проверяем по дате модификации. Вобщем это не проблема виртуального дома, и всё очень сильно зависит от того что нужно реализовать.
добавляем dirty флаг
используем внутренние часики и проверяем по дате модификации
вот я и говорю — костыли :), с точечными биндингами проблемы нет в принципе.
кроме тысяч ненужных биндингов, которые вешаются как раз в тот момент когда происходят самые тормозные операции — добавление элементов.
ну а в случае со всякими фильтрациями, так вообще нужно вешать обсерверы на все фильтруемые значения, даже если отображается 10 из 10000.
кроме тысяч ненужных биндингов, которые вешаются как раз в тот момент когда происходят самые тормозные операции
добавить обработчик к эвентэмиттеру по сравнению с самим добавлением элемента — моментальная операция, не вижу проблемы. К тому же Rionite добавляет разметку компонентов фрагментами (один компонент — один фрагмент), а не по одному элементу и эти фрагменты, на момент добавления, уже обработаны, то есть куски типа "{name}" в них уже заменены на значения.
ну а в случае со всякими фильтрациями, так вообще нужно вешать обсерверы на все фильтруемые значения, даже если отображается 10 из 10000.
так мы обсуждаем биндинги или работу РП? Если прикрутить РП к виртуальному дому, то будет тоже самое и единственный способ уйти от этого — отказаться от РП, на что я вообще никак не согласен и я не знаю людей хорошо понявших эту парадигму и согласных писать что-то серьёзное без неё. Вы, конечно, как хотите))
Желаю поскорее наконец вам встретить нормальных инженеров, которые умеют решать проблемы наиболее подходящими способами, а не пытаются решить все проблемы с помощью РП, тк они «хорошо» её поняли.
Вы уже второй раз скатываетесь на какие-то странные намёки, первый:
Просто те у кого опыта побольше, те знают
К чему это? Недостаток аргументов или раздутое самомнение? Я вроде пытаюсь нормально говорить и приводить нормальные аргументы. Может чего и не понимаю, так объясните без выпендрёжа.
Ну и вообще, сравнение VDOM-vs-RP — довольно странное, как Слон-vs-Табурет, это не конкурирующие вещи, но они могут неплохо дополнять друг друга. Лучше запилите коннектор вроде этого: cellx-react, а я с удовольствием поставлю ссылочку на него у себя. Заодно сможете попробовать непонятную вам парадигму не отрываясь от своих наработок, плюс убедитесь, что АПИ вашей реализации позволяет полноценно делать такие коннекторы, в ранних версиях реакта у меня, помнится, были какие-то проблемы с этим.
>Если прикрутить РП к виртуальному дому, то будет тоже самое и единственный способ уйти от этого — отказаться от РП, на что я вообще никак не согласен и я не знаю людей хорошо понявших эту парадигму и согласных писать что-то серьёзное без неё."
От того что у меня будет одна подписка, которая будет кидаться в случае изменения любого фильтруемого значения, моя реализация не будет менее реактивной, но видимо я недостаточно «хорошо» что-то там понял.
>Ну и вообще, сравнение VDOM-vs-RP — довольно странное
Это вы там каким-то боком начали говорить про RP, видимо «хорошо» поняли, я лишь указывал на то что ваш датабайндинг подразумевает подписки на все значения, дата байндинг через виртуальный дом этого не требует и можно решать задачи наиболее подходящим способом.
моя реализация не будет менее реактивной, но видимо я недостаточно «хорошо» что-то там понял
видимо так, РП — это в первую очередь про потоки данных, а не про обновление разметки, как многие сейчас считают благодаря реакту.
ваш датабайндинг подразумевает подписки на все значения
так почему это плохо? Получается медленней при первичном построении DOM (использование фрагментов вполне может нивелировать эту разницу), но быстрее при точечном обновлении, в некоторых случаях в этом месте VDOM настолько медленный, что требует уже костылей. Вроде это всё или что-то забыл?
Ну так у меня на входе поток данных, который посылает сообщения о том что табличка изменилась. Всё вполне реактивно.
>а не про обновление разметки, как многие сейчас считают благодаря реакту.
Это что-то новое. Видимо это были лично ваши заблуждения и вы теперь думаете что у остальных были такие же проблемы.
>так почему это плохо? Получается медленней при первичном построении DOM (использование фрагментов вполне может нивелировать эту разницу)
Получается медленей так где итак всё тормозит, зато пытаемся ускорить кэйсы на которых всё спокойно отрабатывает втечении одного кадра.
>но быстрее при точечном обновлении, в некоторых случаях в этом месте VDOM настолько медленный, что требует уже костылей.
пруфов видимо не будет, и лишь только ваш личный опыт с реактом, который вы переносите на все остальные вдом библиотеки :)
Ну так у меня на входе поток данных, который посылает сообщения о том что табличка изменилась. Всё вполне реактивно.
ok, раз вас всё устраивает, значит так и оставьте))
Получается медленей так где итак всё тормозит
ну, можно относиться иначе: на 1-2% медленнее в тех местах, где и так тормозит и не плохо бы воткнуть какое-нибудь сообщение о загрузке.
зато пытаемся ускорить кэйсы на которых всё спокойно отрабатывает втечении одного кадра
Эх, если бы это всегда было так))
и лишь только ваш личный опыт с реактом
не только мой личный, это опыт большой команды в компании продуктами которой вы с большой вероятностью пользуетесь/овались. Думаю там очень не глупые люди сидят, да и я со своими 10+ годами продуктовой разработки уже чего-то стою. Плюс у меня есть свои реализации как VDOM, так и патчера без V составляющей. Мне тоже вся эта идея изначально очень нравилась и нахватавшись всяких кейсов вроде описанного выше я попытался исправить их в своём варианте, поняв, что это нормально сделать не получается, начал пилить morph-element, идея была такой: сравнение строк — идеально быстрая операция, причём не зависит от длинны строки, даже при очень длинных и почти совсем одинаковых строках сравнение происходит сверхбыстро где бы не находилось различие. Дальше вместо подстановки разметки дочернего компонента за счёт вызова его как функции, родитель должен был генерировать кастомные элементы разметка которых разворачивалась уже в attachedCallback (ныне connectedCallback) (он синхронный, полифилится на MutationObserver не синхронно, но это я тоже порешал). Что это давало? Получалось, что каждый компонент генерирует только свой собственный контент, но не контент потомков, то есть при первой генерации можно просто запомнить эту строку и при последующей сравнивать не два огромных объекта со всем контентом потомков, а две относительно короткие строки, что в 100500 раз быстрее. Ну и естественно не перегенерировать контент потомков при равности контента родителя с предыдущей вариантом. То есть лишняя перегенерация всё же происходила (родитель), но уходила не на всю глубину, а максимум на один уровень. Такой подход решал некоторые проблемы VDOM, но не все и в целом патчинг с реального DOM (без виртуальной составляющей) всё же получается медленней, как бы я не пытался его оптимизировать и что бы там не говорил разработчик оригинального morphdom.
В общем, пока я в тупике, а все другие варианты, что я посмотрел, предлагают костыли вроде:
добавляем dirty флаг
используем внутренние часики и проверяем по дате модификации
А хочется то нормальный фреймворк, который позволяет просто спокойно кодить не расставляя эти самые костыли по всему коду.
Сейчас я для себя пришёл к выводу, что VDOM — тупиковая идея, но я не исключаю, что ошибаюсь и возможно ещё вернусь к ней))
Пока вернулся к точечным биндингам, тут тоже не всё в идеале, но всё же явно лучше.
Ну, я выше рассказал, почему я выкинул VDOM))
http://localvoid.github.io/kivi-dbmonster/?m=0.001&n=5000
10,000 рядов (~20,000 компонент, элементов хз сколько, но дохера, браузеру становится плохо)
0.1% мутаций
У меня на десктопе апдэйт с помощью вдома происходит за ~1.6мс. При этом всё невероятно тормозит из-за того что кол-во элементов на странице очень большое (лэйаут, лт апдэйт, пэинт >150мс).
Жду пруфов о том какой невероятной скорости вы добились в вашем фрэймворке на «create» и «clear» кэйсах в этом бэнчмарке: https://github.com/krausest/js-framework-benchmark
Должно быть не сложно продемонстрировать о том как всё замечательно, там всего-лишь будет два биндинга на каждый ряд, идеальные условия для вашего фрэймворка.
https://cdn.rawgit.com/krausest/js-framework-benchmark/4e47158a10e52122bf4244724cf99b6de4ef7ac1/webdriver-java/table.html
http://localvoid.github.io/kivi-dbmonster/?m=0.001&n=5000
прежде чем предлагать кому-то повторить этот тест, доведите его до состояния, когда туда нормально можно добавить свою либу. Тайпскрипт (я не против, но всё же стандарт для таких тестов — VanillaJS), сборка, деплой, после сборки зачем-то требует SDK, дальше я не осилил. Сейчас это тест для одной библиотеки — вашей, и что вы там сравниваете непонятно.
Жду пруфов о том какой невероятной скорости вы добились в вашем фрэймворке на «create» и «clear»
кажется вы не слишком внимательно читаете, я как раз без проблем признаю, что в создании/удалении мой подход будет медленнее, а вот у вас с признанием недостатков похоже проблемы. Какой смысл использовать вашу реализацию, если вы не готовы признавать её очевидные подводные камни. Сколько их там ещё? Для реакта они хотя бы нормально описаны в Интернете, прощупаны многими самостоятельно и есть отработанные костыли для их обхода.
Давайте по пунктам:
- есть ситуации в которых vdom начинает рендерить/диффать слишком много лишнего, что может приводить к тормозам и без костылей в коде проекта не решается.
- в этих же ситуациях точечный биндинг — это просто запуск чего-то легковесного (ячейки в случае Rionite) и обработчика из одной строчки: github. Очевидно, что у такого подхода никаких проблем с производительностью не будет.
Если есть нормальные контраргументы, я вас слушаю, но не надо кидаться в меня очередными тестами или мнением очередного "авторитета".
Если вы нашли хороший способ избавляться от лишнего рендера/диффа, расскажите как, то что вы предложили выше — костыли похлеще тех, что использую я, видимо специфичны для вашей реализации. По крайней мере такой жести:
используем внутренние часики и проверяем по дате модификации
я ещё ни у кого не видел.
Вы про этот? https://github.com/krausest/js-framework-benchmark
Это не мой бэнчмарк, там полным полно библиотек, закоммиченных различными людьми. Никаких проблем у меня не возникло с реализацией, где-то за 15 минут спортировал, глядя на реализацию реакта и сделал пулл риквест, автор потом прогнал и обновил табличку. Но видимо для разработчиков с 10+ летним опытом это всё слишком тяжело.
Или вы про дбмон? Не совсем понял, у вас вроде есть реализация дбмона, я тут просто выкрутил параметры N=5000, mutations=0.001. Худший кэйс для вдома, и ведь как-то справляется.
>кажется вы не слишком внимательно читаете, я как раз без проблем признаю, что в создании/удалении мой подход будет медленнее, а вот у вас с признанием недостатков похоже проблемы.
Возможно вас удивит насколько ваша реализация будет медленее :) Ато вы там про какие-то 1-2% фантазируете. Я конечно понимаю что наверно возможно сделать такую библиотечку с таким маленьким оверхэдом, просто я пока не встречал таких.
>есть ситуации в которых vdom начинает рендерить/диффать слишком много лишнего, что может приводить к тормозам и без костылей в коде проекта не решается.
пруф будет что это может приводить к тормозам?
>я ещё ни у кого не видел.
Использовалось ещё до того как immutable в реакте стало модным, так же используется в куче реальных проектов, например в дискорде. То что вы этого не видели, с вашим 10+летним опытом, отлично показывает что у вас за опыт.
А dirty флаг — возможно для вас это будет новостью, но веб браузеры именно так и работают. Да и большинство нативных ui библиотек последние лет 20 так же работали.
Но видимо для разработчиков с 10+ летним опытом это всё слишком тяжело.
То что вы этого не видели, с вашим 10+летним опытом, отлично показывает что у вас за опыт.
Общаться с вами стало просто неприятно, удачи вам.
http://localvoid.github.io/kivi-dbmonster/?m=0.001&n=5000, У меня на десктопе апдэйт с помощью вдома происходит за ~1.6мс.С этим явно что-то не то, при 100% мутаций обновление идет раз в 2 сек, а это 0.5 FPS, но стат-бар в правой панели отображает 60 FPS, врет.
У меня на десктопе апдэйт с помощью вдома происходит за ~1.6мс. в этом бэнчмарке: https://github.com/krausest/js-framework-benchmarkЭтот бенчмарк не удалось погонять, он падает при сборке «npm run build», попробую когда автор починит (или когда у меня появится время пофиксить это).
FPS счётчик использует EMA, и стартует с 60, так что если кадр рендерится раз в 2 сек, то он будет очень долго добираться до нужного значения.
Можно открыть dev tools timeline и там всё будет предельно ясно.
FPS счётчик использует EMA, и стартует с 60, так что если кадр рендерится раз в 2 сек, то он будет очень долго добираться до нужного значения.Кстати на оригинальном dbmon, Angular 2 стартует с 100 FPS и за пару минут снижается до 30 FPS или ниже, это тоже с расчетом связано или баги в ангуляре...?
Надо будет свои расчет вкуртить для проверки.
там вообще не fps, а то с какой частотой вызывается функция ping(), поэтому реализации которые успевают втечении одного кадра несколько раз проапдэйтить дом(грязный дом значительно быстрее обновляется) и вызвать функцию ping() начинают резко показывать >200fps :)
Вот angular2 реализация со счётчиком, который по rAFу считает: https://cdn.rawgit.com/lhorie/mithril.js/rewrite/examples/dbmonster/angular/index.html
Смотрю вы там пытаетесь всё собрать :) Я так и не смог там всё собрать и особенно запустить большой раннер, глянул исходники, понял что там пробиты маковские пути и забил на эту идею. Я просто тупо сделал так чтоб моя реализация локально собиралась внутри директории и предоставляла нужные npm run скрипты, тк глобальный npm build просто бегает по всем директориям и исполняет локальные установки, потестировал что всё правильно работает и отправил пулл риквест, всё остальное он там сам сделает :)
10,000 рядов (~20,000 компонент, элементов хз сколько, но дохера, браузеру становится плохо)
В таких условиях побеждает не тот, кто быстрее рендерит, а тот, кто не рендерит лишнего. VDOM оптимизирует лишь "последнюю милю", когда вы уже решили перерендерить, но не хотите сильно менять DOM. Тем не менее, блоки, что не попадают в видимую область не то, что рендерить, а даже данные для них загружать и подготавливать не имеет смысла. Ленивая архитектура хорошо масштабируется и не требует костылей. VDOM же для такой архитектуры — как собаке пятая нога.
Нет, причем тут react-id. Я об "умном" обновлении ДОМ дерева, том, что, собственно, и делает Реакт реактивным.
В Реакте дерево ДОМ элементов является функцией, или проекцией, состояния приложения. И при изменении этого состояния дерево элементов перестраивается не полностью, а частично, производя минимальные изменения, необходимые для приведения дерева в нужное состояние.
Если не использовать Реакт (и другие virtual DOM библиотеки), то придется либо перестраивать все дерево полностью — и забыть о производительности, либо, как в Ангуляре, оптимизировать перестроение дерева для каждой отдельной директивы.
Используйте один стор
А лучше — Redux.
Причем код, который взаимодействует с бекендом, можно вынести в один или несколько отдельных модулей
Это надо делать априори ввиду Single Responsibility.
… PureRenderMixin
Уже есть PureComponent.
Прямо сейчас это тренд… отрендерить HTML страницу на сервере, передать ее на клиент (с кешированием и CDN) чтобы она мгновенно отобразилась в браузере ...
Воистину история движется по спирали.
В статье:
Несмотря на то, что Baobab не предлагает иммутабельных структур данных (только персистентные)
Тогда как на деле:
Baobab is a JavaScript persistent and immutable (at least by default) data tree supporting cursors and enabling developers to easily navigate and monitor nested data through events.
https://github.com/Yomguithereal/baobab
Конечно, это опционально, и настраивается. При разработке используется заморозка объектов, чтобы убедиться в корректности кода, а на продакшене её можно отключить, для производительности.
immutable boolean [true]: should the tree's data be immutable? Note that immutability is performed through Object.freeze and should be disabled in production for performance reasons.
Вопрос вот в чём, если отбросить период обучения, выиграю ли я применяя вместо espress+jade/pug nodejs+react?
Что выиграть хотите?
Требования точнее бы, чтоб наверняка. Но в целом на React у меня писать получается побыстрее, чем на прежних JQuery. Дебажить легко, разделять на компоненты легко, расширений в принципе уже хватает
Точно могу посоветовать вместо express Koa с Babel: async/await очень упрощает код по сравнению с бесконечными if(err) fail else success, тут Вы точно выиграете и без React
— комментарий перемещен ---
Отсутствие redux. Не использование babel с es 6/7, не использование пререндеринга на сервере…
Благодаря технологии Virtual DOM изменения страницы происходят очень быстро. Но стоит заметить, что в последнее время мы часто встречаем статьи ...React хоть и быстр, все равно он медленнее конкурентов* в 2 (а то и больше раз), возможно вам этого хватит, но там где реакт начнет тромозить, другие будут нормально работать.
ES6/ES7 позволяет писать компоненты реакта более локанично и правильно, но например jshint не поддерживает еще ES7, так как спецификация не готова, но нормально задавать handler'ы компонентов через => функцию можно только в ES7, так как она автомато биндит this, а в ES6 приходится вручную биндить внутренние обработчики в конструкторе, кроме того в ES6 нельзя внутри класса объявить статическое свойства, например propTypes (приходится их писать после объявления самого класса).
Короче развелся целый зоопарк технологий, но вроде как самое нормально сочетание сейчас react/redux/es6/es7 и jest для тестирования, после всяких ангуляров, что первого, что второго — это просто чистое счастье.
Что касается виртуального дома, то эта идея действительно крута и правильна, redux как последний кирпичик все расставил на места, не менялась ссылка на объект, значит не изменилось состояние, значит рендерить не надо, потому что состояние должно быть immutable. Виртуальный дом это очень хорошо, получше всяких ангуляров (я на ангулярах 3 года просидел). virtual dom решает почти все проблемы, если не решает то надо писать на нативном JS, но надо знать что делать, код должен быть оптимизированным. Кстати очень хорошая книга High Performance JS, без ее прочтения я бы даже не допустил человека к написанию кода на JS.
время модификации данных раньше чем время последнего обновления компоненты, значит рендерить не надо и состояние может быть mutable.
Пример, пожалуйста. Я правильно понял, Вы предлагаете к каждому объекту прикреплять timestamp? Так:
const user = {
name: "John"
age: 23,
contacts: {
phone: 123456
email: foo@bar.com,
socials: {
vk: "vk.com/john",
fb: "fb.com/john",
_timestamp: 12345676
},
_timestamp: 12345677
}
_timestamp: 12345678
}Ага, ясно, тогда получается это удобство vs производительность. Я пока не столкнулся с необходимостью отказываться от иммутабельности, и больше склоняюсь к мысли, что не следует жонглировать оптимизациями раньше времени, хотя, конечно, когда прижмёт как Discord, придётся локально вырубать иммутабельность в узких местах, благо это не сложно
Это лишь дань моде.
Замечание относительно изоморфности.
То Вы говорите, что круто, что ничего не генерится на сервере, то вдруг круто, что все генерится еще и на сервере.
Как бы можно это понять, если все на том самом коде. Но в статье 2 разные языка.
Да и вряд ли реакт быстро сгенерирует страничку на сервере. Хотя c кешированием ОК.
Только странно, что сайт должен оживать, а не живой сразу.
Зачем 2 раза гонять те же самые данные? :) Сначала в HTML, потом в JSON (JS).
Год использования ReactJS: подводим итоги