Крутая штука, спасибо за овервью. Есть несколько вопросов:
Когда планируете в open source? Хочется пощупать :)
Возможно ли в визуальном редакторе настраивать связи между компонентами и добавлять динамику? Ну например, есть компонент таблички, хочу взять данные с API и засунуть их туда, прикрутить пагинацию и тд, без девов. (Ну или сделать простой toggle и тд)
Слушайте, проблема производительности гидратации не в том, что она плохо влияет на метрики. А в том, что популярные Фреймворки в упор не видят проблемы и не пытаются ее решить, предлагая костыльные решение в виде ленивой гидратации, которая также не решает проблему на 100%. Если ставить вопрос глобально, то jquery работает все равно быстрей, чем реакт. И дело именно в том, как ядро реакта написано.
Если интересно, посмотрите мою статью, я там разобрал вопрос производительности и добился очень хороший цифр при этом без ущерба функционалу.
2. Согласен
3. У меня в списке элементы заново не рендерятся. Так-то можно через привязку к ключу реализовать.
Конкретно по производительности, пользователи уже привыкли, что сайты у них открываются по 10 секунд.
Аналитика пользовательского поведения говорит немножко о другом: отказы прямо зависят от того, как медленно работает веб-сайт/приложение. Почему вы считаете, что пользователи привыкли и это не особо важно?
Тестанул. Действительно, я переусердствовал с оптимизацией.
Реактивные либы, если биндить зависимости, но пропускать работу рендера, работают отлично и никакого overhead не добавляют. Походу где-то я накосячил с предыдущим бенчем.
Попробую узнать, как можно внедрить в svelte. Будет круто, если не нужно будет дальше изобретать велик.
1. Согласен
2. Двусторонний биндинг можно кастомизировать с помощью своей директивы
3. Так и есть, как часто вообще используется «ручной» перенос?
4. На данный момент так и есть, нужен свой MobX, Vuex и т.д.
Проблем много, но они решаемы. Вопрос только нужно ли новое решение… И насколько остро стоит вопрос производительности при запуске фреймворка. А-ля замена «jQuery» для сайтов с изолированными компонентами и нормальным тестированием.
Так Я за, но они все вызывают функции для поиска зависимостей и от этого никуда не деться. Соотвественно просядет производительность, если есть какой то способ, как избежать этого, и вы его вдруг знаете, будет супер.
Computed есть, транзакций пока нет, но тоже добавить реально.
Единственное, что делает Фреймворк, он проставляет зависимости для computed и subscriber без вызова функции на этапе компиляции. Чтобы не вызывать эту функцию в рантайме
Верно. Как указали ниже, обёртку можно и другую использовать, это не проблема.
Проблемы появляются когда используются вычисляемые свойства. Любая реактивная библиотека запускает subscriber, чтобы проставить зависимости. Это добавляет лишнее время на запуск js кода. Когда у вас 10 компонентов — это не критично, но когда у вас много статики, тогда время до интерактивности улетает в небеса.
Я был бы очень рад, если бы это кто то сделал за меня и приложения стали работать быстрее, правда.
Но на базе условного Реакта не получиться сделать. Проблема глобальна, из за огромного количества абстракций в виде реактивных библиотек и виртуального DOM и т.д.
Крутая штука, спасибо за овервью. Есть несколько вопросов:
Когда планируете в open source? Хочется пощупать :)
Возможно ли в визуальном редакторе настраивать связи между компонентами и добавлять динамику? Ну например, есть компонент таблички, хочу взять данные с API и засунуть их туда, прикрутить пагинацию и тд, без девов. (Ну или сделать простой toggle и тд)
Поделитесь скриншотом редактора?
Слушайте, проблема производительности гидратации не в том, что она плохо влияет на метрики. А в том, что популярные Фреймворки в упор не видят проблемы и не пытаются ее решить, предлагая костыльные решение в виде ленивой гидратации, которая также не решает проблему на 100%. Если ставить вопрос глобально, то jquery работает все равно быстрей, чем реакт. И дело именно в том, как ядро реакта написано.
Если интересно, посмотрите мою статью, я там разобрал вопрос производительности и добился очень хороший цифр при этом без ущерба функционалу.
Гидратация в sinuous очень медленная, хуже чем во Vue.
5кб это из за роутинга и глобальных компонентов, которые добавлены в SSR
Сделаю, но скорее всего больше, цель была не размер сократить, а скорость сделать быструю.
Подход с innerHTML и template тоже использую.
Верю, но хочется увидеть живой пример, цифры pagespeed
А можете показать пример проекта, где производительность реакта Вас устраивает?
В том то и дело, что весь базовый функционал реализован. А скорость при этом быстрая.
3. У меня в списке элементы заново не рендерятся. Так-то можно через привязку к ключу реализовать.
Аналитика пользовательского поведения говорит немножко о другом: отказы прямо зависят от того, как медленно работает веб-сайт/приложение. Почему вы считаете, что пользователи привыкли и это не особо важно?
Реактивные либы, если биндить зависимости, но пропускать работу рендера, работают отлично и никакого overhead не добавляют. Походу где-то я накосячил с предыдущим бенчем.
Попробую узнать, как можно внедрить в svelte. Будет круто, если не нужно будет дальше изобретать велик.
Точно. Что-то я не подумал об этом. Можно попробовать разделить subscriber на 2 этапа:
— «Биндинг» зависимостей
— Работа с DOM
Возможно это решение можно будет прикрутить к Svelte и не нужно будет изобретать велосипед. Попробую, спасиб!
2. Двусторонний биндинг можно кастомизировать с помощью своей директивы
3. Так и есть, как часто вообще используется «ручной» перенос?
4. На данный момент так и есть, нужен свой MobX, Vuex и т.д.
Проблем много, но они решаемы. Вопрос только нужно ли новое решение… И насколько остро стоит вопрос производительности при запуске фреймворка. А-ля замена «jQuery» для сайтов с изолированными компонентами и нормальным тестированием.
Вычислять зависимости на этапе компиляции, чтобы при запуске на клиенте не выполнилась лишняя работа
Есть, роутинг пока очень простой. Но он везде делается и там и там, где есть ssr
Так Я за, но они все вызывают функции для поиска зависимостей и от этого никуда не деться. Соотвественно просядет производительность, если есть какой то способ, как избежать этого, и вы его вдруг знаете, будет супер.
Computed есть, транзакций пока нет, но тоже добавить реально.
Единственное, что делает Фреймворк, он проставляет зависимости для computed и subscriber без вызова функции на этапе компиляции. Чтобы не вызывать эту функцию в рантайме
Верно. Как указали ниже, обёртку можно и другую использовать, это не проблема.
Проблемы появляются когда используются вычисляемые свойства. Любая реактивная библиотека запускает subscriber, чтобы проставить зависимости. Это добавляет лишнее время на запуск js кода. Когда у вас 10 компонентов — это не критично, но когда у вас много статики, тогда время до интерактивности улетает в небеса.
Почти так оно и есть, только Гидратация работает быстрее раз в 10.
Я был бы очень рад, если бы это кто то сделал за меня и приложения стали работать быстрее, правда.
Но на базе условного Реакта не получиться сделать. Проблема глобальна, из за огромного количества абстракций в виде реактивных библиотек и виртуального DOM и т.д.
Во первых, на прямую во фреймворках вы со всем этим все равно не работаете.
Во вторых, вы говорите про то, как реактивность работает под капотом.
Не понимаю вашего «лол» и что я должен понять из приведённого участка кода. А самое главное, что в проекте на текущий момент сделано не так как надо.