Apache/Nginx + php-fpm !== Apache/Nginx (sendFile). Тут php-fpm выступает как более узкое горлышко. А если ещё и делаете какие-то IO операции из php - то естественно ситуация становится ещё хуже.
В любом случае отдача чистой статики средствами одного веб-сервера будет дешевле. И статику можно кешировать на клиенте, прокси, и т.д. Я конечно уже не помню в деталях, может что-то подобное связанное с кешированием для php-fpm тоже есть.
Мы просто трансформировали тонкого клиента в толстого. И в этом огромные преимущества для серверной инфраструктуры. Статический хостинг попробуй за DDOS-ить в отличие от Apache/Nginx + PhP-Fpm. Дак и к тому же накладные расходны гораздо меньше.
Я тоже непонимаю зачем возвращают серверный рендеринг. Идиотизм какой-то у них там в головах.
Бесконечные списки обычно исползуются в сценарии когда требуется подгружать n-ое кол-во строк с бека при движении прокрутки ближе к концу контейнера, т.е. заранее не известно кол-во строк.
Если вы делаете что-то такое дикое в теле компонента, что при повторном вызове тела происходят тормоза, то в любом случае надо по разбираться, что там тормозит и использовать useMemo для тормозных вычислений.
Я опять повторюсь, что если ваша логика рендеринга чиста от сайд эффектов и все тормозные участки замемоизированы, тогда нет никакого преимущества от выноса логики в статическое хранилище, так как вы разницу визуально не заметите.
К тому же react разработчики сами пишут, что рендеринг компонента может запускаться и без вашего участия, поэтому стараться уменьшить кол-во перерендеров через такие стейт менеджеры лишено смысла.
React Compiler выпустят в OpenSource и тогда все эти стейт менеджеры у которых единственная глобальная цель оптимизировать рендеринг потеряют актуальность и вам всем потом захочется с таким же энтузиазмом переписывать всё на React state + reducer + context. Кстати в PR-ах в React репу можно найти видео, где разработчик добавил функцию отображения авто-мемоизированных компонентов и уже тестирует на каком-то коде.
Я считаю что чем меньше хлама затащим в проект, тем меньше потом работы будет чтобы выпиливать все это.
И кстати чем плох Redux в рамках RTK Query? Сейчас вместо Redux же предлагается использовать RTK и он вполне уже не так многословен, как оригинальный Redux. В состав входит Immer, можно мутировать стейт, если прям не нравится деструктуризация. useSelector вызывает рендеринг только если стейт, который он возвращает, поменялся. По идее так же точечно как и Effector, MobX будет обновлять компоненты.
Чем плох повторный рендеринг UsersTable? Повторный рендеринг - это не всегда же работа с DOM. Если Fiber дерево компонента получается такое же как и текущее, то там ничего не будет происходить с DOM вообще. К тому же фаза рендеринга в React асинхронная и это не должно как либо отразиться на производительности веб приложения.
Если у вас логика рендеринга без каких либо сайд эффектов, как и рекомендует React команда, то ни на что не должно повлиять.
Так же React пишут, что memo это чисто оптимизация производительности и нужно на неё только опираться, если вы видите реальные тормоза. В том числе потому что использование memo так же не бесплатно.
You should only rely on memo as a performance optimization. If your code doesn’t work without it, find the underlying problem and fix it first. Then you may add memo to improve performance.
Optimizing with memo is only valuable when your component re-renders often with the same exact props, and its re-rendering logic is expensive. If there is no perceptible lag when your component re-renders, memo is unnecessary.
Так же они всё же когда-нибудь обещают выпустить React Forget, где это будет делаться автоматически.
Apache/Nginx + php-fpm !== Apache/Nginx (sendFile). Тут php-fpm выступает как более узкое горлышко. А если ещё и делаете какие-то IO операции из php - то естественно ситуация становится ещё хуже.
В любом случае отдача чистой статики средствами одного веб-сервера будет дешевле. И статику можно кешировать на клиенте, прокси, и т.д. Я конечно уже не помню в деталях, может что-то подобное связанное с кешированием для php-fpm тоже есть.
Это всё понятно. Обо всём этом вся статья. Я просто дополнил мнение автора статьи, почему SPA ещё так стали популярны.
Можете. Но статику фронта вы в любом случае скачаете со всеми преимуществами CDN. И туда даже может быть сразу встроен статический контент.
А отказоустойчивость api - это проблемы их архитектуры со своими решениями.
Кто хочет тупеть - пусть пользуется. Меня по старинке всё устраивает. Утки вперёд!
Ну можно же для бота сгенерять статику основных страниц, а где нужен более динамичный функционал - там уже делать SPA.
«Фу, перезагрузка страницы – это прошлый век!»
Мы просто трансформировали тонкого клиента в толстого. И в этом огромные преимущества для серверной инфраструктуры. Статический хостинг попробуй за DDOS-ить в отличие от Apache/Nginx + PhP-Fpm. Дак и к тому же накладные расходны гораздо меньше.
Я тоже непонимаю зачем возвращают серверный рендеринг. Идиотизм какой-то у них там в головах.
Много платят за рекламу Claude?
Бесконечные списки обычно исползуются в сценарии когда требуется подгружать n-ое кол-во строк с бека при движении прокрутки ближе к концу контейнера, т.е. заранее не известно кол-во строк."content-visibility" с таким справится?Вообще в действительности нужно действовать так:
Проверить резюме и стаж работы. Если по профилю работает давно, то спрашивать базу действительно смысла нет. Тогда переходим сразу к боевым задачам.
Если опыта мало, то все же надо убедиться что он хотя бы читал базу и понимает её суть, а уже потом переходить к боевым задачам.
Надо удалять всякие Snap-ы, Flatpack-и и стараться устанавливать софт только из официальных реп.
Если вы делаете что-то такое дикое в теле компонента, что при повторном вызове тела происходят тормоза, то в любом случае надо по разбираться, что там тормозит и использовать useMemo для тормозных вычислений.
Я опять повторюсь, что если ваша логика рендеринга чиста от сайд эффектов и все тормозные участки замемоизированы, тогда нет никакого преимущества от выноса логики в статическое хранилище, так как вы разницу визуально не заметите.
К тому же react разработчики сами пишут, что рендеринг компонента может запускаться и без вашего участия, поэтому стараться уменьшить кол-во перерендеров через такие стейт менеджеры лишено смысла.
React Compiler выпустят в OpenSource и тогда все эти стейт менеджеры у которых единственная глобальная цель оптимизировать рендеринг потеряют актуальность и вам всем потом захочется с таким же энтузиазмом переписывать всё на React state + reducer + context. Кстати в PR-ах в React репу можно найти видео, где разработчик добавил функцию отображения авто-мемоизированных компонентов и уже тестирует на каком-то коде.
Я считаю что чем меньше хлама затащим в проект, тем меньше потом работы будет чтобы выпиливать все это.
И кстати чем плох Redux в рамках RTK Query? Сейчас вместо Redux же предлагается использовать RTK и он вполне уже не так многословен, как оригинальный Redux. В состав входит Immer, можно мутировать стейт, если прям не нравится деструктуризация. useSelector вызывает рендеринг только если стейт, который он возвращает, поменялся. По идее так же точечно как и Effector, MobX будет обновлять компоненты.
Чем плох повторный рендеринг UsersTable? Повторный рендеринг - это не всегда же работа с DOM. Если Fiber дерево компонента получается такое же как и текущее, то там ничего не будет происходить с DOM вообще. К тому же фаза рендеринга в React асинхронная и это не должно как либо отразиться на производительности веб приложения.
Если у вас логика рендеринга без каких либо сайд эффектов, как и рекомендует React команда, то ни на что не должно повлиять.
Так же React пишут, что memo это чисто оптимизация производительности и нужно на неё только опираться, если вы видите реальные тормоза. В том числе потому что использование memo так же не бесплатно.
https://react.dev/reference/react/memo
Так же они всё же когда-нибудь обещают выпустить React Forget, где это будет делаться автоматически.