некоторые и стили хардкодят, вообще фронт полон таких решений, где-то сочиняют какой-нибудь бэм, который тоже наоборот относительно суммы класснеймов применяемой в любом CSS-фреймворке. Где-то на класснеймы мапят отдельные проперти со значениями типа "отступ 5 пт" хардкодя стили в верстку. Кто во что горазд получается. Только разработчики-потребители этих технологий ходят от проекта к проекту построенному вокруг таких решений набивать новые шишки.
там рендеринг это вызов функции, результат выполнения которых хранится закешированным, т.е. может содержать ссылки на созданные в процессе объекты. И если такая функция 10 раз все-таки отработала она 10и-кратно повысила нагрузку на ресурсы, это не считая каскадных вызовов по зависимостям. Поэтому там все заворачивается в useMemo и useCallback. А решение аплаить ли новую верстку на страницу принимается на основе диффа, что тоже вычисления. Использовать реакт составляющие в контексте обычного кода прямо запрещается его рантаймом, а без этого использовать классы вообще довольно малоэффективно и насколько я помню не рекомендуется. Снизить нагрузку можно было бы не занимаясь софтовым рендерингом за браузерный движок, но все эти концепции закладывались когда поиски и изменения на DOM-дереве в большинстве Интернет Эксплореров работали крайне медленно, поэтому такие архитектуры казались более оптимальными.
React это фреймворк наоборот, в нем тэги компонентов используют сильное зацепление в отличии от гибкого и расширяемого html. При этом с бизнес-логикой они обычно законекчены слабосвязными решениями. Вместо упорядоченного ООП структурирования API - кусочки хуков и колбеков с явным перечислением зависимостей и максимально усложненным переиспользованием. Вместо прозрачных декораторов - явный вызов оберток типа useMemo. Вместо DRY дублирование имен на входах и выходах. Вместо наследования при объявлении - локальное переопределение при деструктуризации. Вобщем, каждая единица реакт-мира построена на каких-то антипаттернах и ошибках проектирования.
перерисовки реакта т.е. повторный вызов кода скорее всего приводят к дрочеву памяти(а если есть утечки к быстрому ее исчерпанию) и логики, которая может быть написана в конструкторах
тормоза могут быть просто потому, что в свежаке отладочные данные не вырезают и оптимизаций не включают. Ещё всякие косвенные моменты влияют типа 2д и 3д производительности видеокарты. 2ой амарок был на плазме, в которой много всякого векторного и красивого
в процессах mysql-embedded, а не серверная и наверняка она в чем то лучше. Может быть, в аналитических запросах для предпочтений например или в хранении блобов обложек. Обычное использование субд в qt примерно одинаковое по сложности
XStream - это как раз пример общего решения, "простая система на сегодня" выковыривала бы данные поиском по подстроке или что-то в таком роде.
Если совсем пренебрегать DRY, SOLID, OOP и ориентироваться только на скорость деливеринга, такие системы очень быстро превращаются в очень сложные для разработчиков любого уровня и погруженности в систему и ее домен. Именно с этим в первую очередь связанно стремление оверинжинирить на будущее
html это верстка, которая производится от дизайна/макета и слишком много бизнесовых и конфигурационных атрибутов в ней ухудшает поддерживаемость кода, так что htmx выглядит как решение для одной формочки на сайте, доступное любому вебмастеру, но не более того
ни разу не видел, чтобы реакт использовали именно как библиотеку, да и его особенности, в частности, рендеринга не позволяют его сочетать с другими фреймворками. Все используют реакт чтобы создать SPA или что-то в таком роде. При этом выкидывают jquery и остальные технологии если они использовались, вместо них лепят свои велосипеды или берут реакт-аналоги. Например, свою реализацию слотов или инструмент для стилей. А если хотят у себя сделать "как в реакте" используют какой-нибудь клон его решений, например rx-сторы для ангуляра и вуе.
И реакт ничего из этого не делает, поэтому он и не является фреймворком.
прежде всего, он обязывает код организовывать вокруг его компонентной модели и жизненного цикла, не позволяет удобно использовать нативные эвенты, классы. Вы можете выбирать только между одними реакт-решениеми и другими.
это популярное клише, но на деле библиотека это код, который вы можете использовать в своем приложении для решения конкретной задачи, например работы с json/xml файлами. А фреймворк - каркас и инструменты для организации собственного бизнесового кода в приложение накладывающий определенные соглашения на его оформление.
но говорить, что он негибок и не даёт что-то сделать - максимально странно
React не использует ничего из общепринятых инструментов для понижения связности кода: отрицает DI/IoC, Инкапсуляцию через наследование(классов), Шаблоны поэтому любое изменение в нем требует модификации кода(часто массированной), явных решений, дублирования(когда вы перечисляете пропсы там и тут), что не позволяет засчитать ему высокий уровень гибкости. Вместо этого его подсистемы часто тащат свои решения которые градус хардкода только повышают. Например, сторы всегда требовалось биндить явно в компоннетах, а контекст вынуждает компоненты оборачивать в свои конструктции прямо в jsx.
React обладает одним из самых больших комьюнити в мире фронтенд-разработки. Огромное количество готовых решений, ответов на вопросы на форумах и найденных обходных решений могут быть найдены по первой ссылке запроса в Google.
решения React часто несовместимы друг с другом(не говоря уже про остальные фронтенд технологии) из-за постоянных изменений в инфраструктуре и отсутствия ее стандартизации. Если сомневаетесь попробуйте использовать компоненты из Antd вместе с Material или модули использующие разные решения для управления состоянием. В тоже время у Vaadin есть приличный репозиторий готовых компонентов, которые вы можете использовать в Jmix https://vaadin.com/directory/ и вообще можете прикручивать сторонние JavaScript библиотеки не боясь, что какой-нибудь перерендеринг как в React будет их ломать. Некоторые аддоны Jmix написаны обертками к JS-библиотекам и существует отработанная методология интеграции с любыми другими. Опять же в личной практике я видел как от использования библиотеки готовых компонентов разработчики на большом React-проекте переходили к переписыванию кода на собственных компонентах, потому что она внезапно комерциализировалась, была тяжелой и бажной. Готовые решения распространялись кусками через личку телеграма между "своими" и кочевали от проекта к проекту позволяя паразитировать на велосипедостроении
Во-вторых, мы находимся в Java. Получается, что сессия — Java-объект. Большой и объемный Java-объект, который имеет много ссылок на другие Java-объекты. Таким образом, размер сессии может спокойно достигать нескольких мегабайтов.
Задачи корпоративного приложения могут потребовать хранения большого количества сессионных параметров. Мне приходилось например видеть такие требования, что надо было обеспечивать полное восстановление состояния экрана(данных формы, фильтров и т.д.) при переходе назад или случайном закрытии окна. В случае если у вас нет такой интеграции вы будете пилить велосипеды реализующие то же самое и возможно даже в конце концов включите липкие сессии в рамках борьбы за консистентность данных и производительность.
В то же время типичное корпоративное приложение в отличии от публичного сервиса как VK имеет обычно вполне определенное количество пользователей, что позволяет оценить системные требования.
по-моему опыту React является одной из наименее гибких из фронтенд технологий и эта его сторона часто преподносится как достоинство хардкод решений, когда можно зарефакторить половину кодовой базы одним махом и быть в относительной уверенности, что она после исправлений за линтером не развалится. В Vaadin вы можете выполнить JavaScript код на любом элементе, кастомизировать его по общим правилам html стандартов и технологий таких как css, shadow dom, слоты, а в React вам будет доступен только локальный внутренний API компонента. Custom Elements не является подобием компонентов React, а реализует браузерный стандарт, который разрабатывался конечно с некоторой оглядкой на него(отсюда хуки componentDidMount), но несколько позднее и включает многие возможности современного HTML, таких как обзервабилити атрибутов, поддержка нативных браузерных событий, data-атрибутов.
я видел в районе 5и крупных проектов на React и гораздо больше мелких и не один из них не был похож на другой по архитектурным решениям, где-то использовались классы, где-то хуки, где-то контекст, где-то одна из реализаций сторов. Что бы вы не написали про эту технологию найдется тот, кто скажет, что сейчас так делать уже не принято
это такой оригинальный вариант SOSAL, простите?
от проблем не убежишь
некоторые и стили хардкодят, вообще фронт полон таких решений, где-то сочиняют какой-нибудь бэм, который тоже наоборот относительно суммы класснеймов применяемой в любом CSS-фреймворке. Где-то на класснеймы мапят отдельные проперти со значениями типа "отступ 5 пт" хардкодя стили в верстку. Кто во что горазд получается. Только разработчики-потребители этих технологий ходят от проекта к проекту построенному вокруг таких решений набивать новые шишки.
там рендеринг это вызов функции, результат выполнения которых хранится закешированным, т.е. может содержать ссылки на созданные в процессе объекты. И если такая функция 10 раз все-таки отработала она 10и-кратно повысила нагрузку на ресурсы, это не считая каскадных вызовов по зависимостям. Поэтому там все заворачивается в useMemo и useCallback. А решение аплаить ли новую верстку на страницу принимается на основе диффа, что тоже вычисления.
Использовать реакт составляющие в контексте обычного кода прямо запрещается его рантаймом, а без этого использовать классы вообще довольно малоэффективно и насколько я помню не рекомендуется.
Снизить нагрузку можно было бы не занимаясь софтовым рендерингом за браузерный движок, но все эти концепции закладывались когда поиски и изменения на DOM-дереве в большинстве Интернет Эксплореров работали крайне медленно, поэтому такие архитектуры казались более оптимальными.
React это фреймворк наоборот, в нем тэги компонентов используют сильное зацепление в отличии от гибкого и расширяемого html. При этом с бизнес-логикой они обычно законекчены слабосвязными решениями. Вместо упорядоченного ООП структурирования API - кусочки хуков и колбеков с явным перечислением зависимостей и максимально усложненным переиспользованием. Вместо прозрачных декораторов - явный вызов оберток типа useMemo. Вместо DRY дублирование имен на входах и выходах. Вместо наследования при объявлении - локальное переопределение при деструктуризации. Вобщем, каждая единица реакт-мира построена на каких-то антипаттернах и ошибках проектирования.
перерисовки реакта т.е. повторный вызов кода скорее всего приводят к дрочеву памяти(а если есть утечки к быстрому ее исчерпанию) и логики, которая может быть написана в конструкторах
навскидку вижу разнообразие аннотаций, в ее такое всегда любили
тормоза могут быть просто потому, что в свежаке отладочные данные не вырезают и оптимизаций не включают. Ещё всякие косвенные моменты влияют типа 2д и 3д производительности видеокарты. 2ой амарок был на плазме, в которой много всякого векторного и красивого
в процессах mysql-embedded, а не серверная и наверняка она в чем то лучше. Может быть, в аналитических запросах для предпочтений например или в хранении блобов обложек. Обычное использование субд в qt примерно одинаковое по сложности
вроде clementine как раз таким был
XStream - это как раз пример общего решения, "простая система на сегодня" выковыривала бы данные поиском по подстроке или что-то в таком роде.
Если совсем пренебрегать DRY, SOLID, OOP и ориентироваться только на скорость деливеринга, такие системы очень быстро превращаются в очень сложные для разработчиков любого уровня и погруженности в систему и ее домен. Именно с этим в первую очередь связанно стремление оверинжинирить на будущее
html это верстка, которая производится от дизайна/макета и слишком много бизнесовых и конфигурационных атрибутов в ней ухудшает поддерживаемость кода, так что htmx выглядит как решение для одной формочки на сайте, доступное любому вебмастеру, но не более того
ни разу не видел, чтобы реакт использовали именно как библиотеку, да и его особенности, в частности, рендеринга не позволяют его сочетать с другими фреймворками. Все используют реакт чтобы создать SPA или что-то в таком роде. При этом выкидывают jquery и остальные технологии если они использовались, вместо них лепят свои велосипеды или берут реакт-аналоги. Например, свою реализацию слотов или инструмент для стилей. А если хотят у себя сделать "как в реакте" используют какой-нибудь клон его решений, например rx-сторы для ангуляра и вуе.
прежде всего, он обязывает код организовывать вокруг его компонентной модели и жизненного цикла, не позволяет удобно использовать нативные эвенты, классы. Вы можете выбирать только между одними реакт-решениеми и другими.
это популярное клише, но на деле библиотека это код, который вы можете использовать в своем приложении для решения конкретной задачи, например работы с json/xml файлами. А фреймворк - каркас и инструменты для организации собственного бизнесового кода в приложение накладывающий определенные соглашения на его оформление.
React не использует ничего из общепринятых инструментов для понижения связности кода: отрицает DI/IoC, Инкапсуляцию через наследование(классов), Шаблоны поэтому любое изменение в нем требует модификации кода(часто массированной), явных решений, дублирования(когда вы перечисляете пропсы там и тут), что не позволяет засчитать ему высокий уровень гибкости. Вместо этого его подсистемы часто тащат свои решения которые градус хардкода только повышают. Например, сторы всегда требовалось биндить явно в компоннетах, а контекст вынуждает компоненты оборачивать в свои конструктции прямо в jsx.
решения React часто несовместимы друг с другом(не говоря уже про остальные фронтенд технологии) из-за постоянных изменений в инфраструктуре и отсутствия ее стандартизации. Если сомневаетесь попробуйте использовать компоненты из Antd вместе с Material или модули использующие разные решения для управления состоянием. В тоже время у Vaadin есть приличный репозиторий готовых компонентов, которые вы можете использовать в Jmix https://vaadin.com/directory/ и вообще можете прикручивать сторонние JavaScript библиотеки не боясь, что какой-нибудь перерендеринг как в React будет их ломать. Некоторые аддоны Jmix написаны обертками к JS-библиотекам и существует отработанная методология интеграции с любыми другими. Опять же в личной практике я видел как от использования библиотеки готовых компонентов разработчики на большом React-проекте переходили к переписыванию кода на собственных компонентах, потому что она внезапно комерциализировалась, была тяжелой и бажной. Готовые решения распространялись кусками через личку телеграма между "своими" и кочевали от проекта к проекту позволяя паразитировать на велосипедостроении
Задачи корпоративного приложения могут потребовать хранения большого количества сессионных параметров. Мне приходилось например видеть такие требования, что надо было обеспечивать полное восстановление состояния экрана(данных формы, фильтров и т.д.) при переходе назад или случайном закрытии окна. В случае если у вас нет такой интеграции вы будете пилить велосипеды реализующие то же самое и возможно даже в конце концов включите липкие сессии в рамках борьбы за консистентность данных и производительность.
В то же время типичное корпоративное приложение в отличии от публичного сервиса как VK имеет обычно вполне определенное количество пользователей, что позволяет оценить системные требования.
по-моему опыту React является одной из наименее гибких из фронтенд технологий и эта его сторона часто преподносится как достоинство хардкод решений, когда можно зарефакторить половину кодовой базы одним махом и быть в относительной уверенности, что она после исправлений за линтером не развалится. В Vaadin вы можете выполнить JavaScript код на любом элементе, кастомизировать его по общим правилам html стандартов и технологий таких как css, shadow dom, слоты, а в React вам будет доступен только локальный внутренний API компонента.
Custom Elements не является подобием компонентов React, а реализует браузерный стандарт, который разрабатывался конечно с некоторой оглядкой на него(отсюда хуки componentDidMount), но несколько позднее и включает многие возможности современного HTML, таких как обзервабилити атрибутов, поддержка нативных браузерных событий, data-атрибутов.
я видел в районе 5и крупных проектов на React и гораздо больше мелких и не один из них не был похож на другой по архитектурным решениям, где-то использовались классы, где-то хуки, где-то контекст, где-то одна из реализаций сторов. Что бы вы не написали про эту технологию найдется тот, кто скажет, что сейчас так делать уже не принято
периодически еще упоминается тезис "ничего не изменилось в спринге"
десять лет назад так же ныли, версия была тогда примерно 8ая