Комментарии 15
Насколько я понял, с сервера приходит огромный JSON, описывающий все элементы интерфейса. Загружается он долго, и вы решаете проблему так:
Парсинг JSONа по кусочкам по мере загрузки и немедленный рендер полученных элементов.
Создание низкоуровневых
ReactElementвручную, в обход стандартных механизмов Реакта.
Если первое еще как-то можно оправдать безальтернативным и неизменяемым бэкэндом, то второе вряд ли даст вам что-то, кроме потенциальных проблем.
ИМХО, целесообразнее
Разделить запросы на каркас и контент
Загружать каркас первым, потом то, что above the fold, показывать скелетоны вместо единого спиннера и т.д.
Юзать HTTP/2 Push, 103 Early Hints и т.п.
В статье рассматривается концепция BDUI. Безусловно, подход спорный, но на практике многие компании в той или иной форме применяют его, что позволяет им существенно бустить производительность разработки.
Понятно, что если у вас чистая PWA без нативного мобильного приложения, то BDUI, скорее всего, вам не нужен. Однако в мультиплатформенной среде он может дать ощутимую выгоду.
Теперь по поводу вашего комментария. Могли бы вы подробнее рассказать, каким образом вы планируете реализовать описанную вами логику в рамках BDUI? Допустим, у вас есть JSON, описывающий интерфейс. Как именно вы собираетесь разделить этот JSON на каркас (skeleton/layout) и остальную структуру?
Обратите внимание, что этот же JSON используется и нашей мобильной командой. Унификация данных между платформами помогает нам существенно ускорять внедрение новых фич и снижать дублирование логики.
А каким тут боком тэг Си++ тут стоит?
Нам, плюсовикам, немного чуждый ваш мир фронт-энда. Хотя, прочитав статью, нашёл нечто похожее, что делали в играл, которые на С/С++, чтобы грузить уровень не целиком, ожидая полминуты, а по ходу пьесы.
Настораживает, что в «стало» нет ни одного числа. А в «было» числа есть. Подозреваю, что не так хорошо получилось, как автор нам рассказывает.
На демо-стенде показало 30% прирост к скорости. Точных цифры могут варьироваться в зависимости от реальных условий и объёма данных на живом проекте. Плюс по перфоманс профайлу есть видимость, что сборщик мусора срабатывает реже, что тоже ускоряет загрузку.
Извините, но 30% это по сути ни о чем. Оно было так плохо, что нужен прирост скорости в 300% (уменьшение время отклика на 66%), (из 15с до 5с) чтобы стало «просто плохо». Чтобы стать «хорошо» время реакции нужно меньше чем 2с, а 1с – «прекрасно». А это уже 1500% ускорения.
Так что статью надо понимать как руководство как делать не надо.
.
Как я понял, вы ориентируетесь на замеры в локальной среде без сетевых ограничений. 15 секунд закладывается на загрузки с учётом условий мобильной сети у реальных пользователей. В таких условиях получить 1 секунду — невозможно. Указанные 30% — это показатели, снятые с мобильных устройств.
Обсуждать скорость загрузки в контексте статьи — всё равно что обсуждать сферического коня в вакууме. Всё, конечно, упирается в размер JSON и итогового JS-бандла: чем больше логики и кода, тем дольше загрузка.
Тем не менее, никого ни к чему не призываю и не пытаюсь переубедить. Было бы интересно узнать про ваш опыт с BDUI, если есть: какие цифры получались у вас и что для этого делали.
Для первой итерации я бы исходил из реальной потребности для первого рендера. Предполагаю что в большой JSONке есть ключи и при желании можно запрашивать с бэка нужный ключ, а не всю. А потрм можно сервис воркер подключить для префетча остального.
Куда мы катимся... Сотни килобайт ТЕКСТОВОГО содержимого, которое надо распарсить, а ещё js и прочее содержимое. Да-да, есть сайты ещё хуже, тянущие десятки и даже сотни мегабайт js-содержимого и это далеко не ноунеймы, я знаю, но... Эх, в какой момент всё стало настолько плохо? И люди, которые говорят, что загрузка страницы за 10 сек вместо 15 это хорошо - это как понимать? Вообще-то это катастрофа, знаете ли! Хотите обижайтесь, хотите нет, но не надо себе и нам пытаться втюхать, что это «нормально».
Как писал классик:
Если звёзды зажигаются — значит, это кому-нибудь нужно.
Вы не учли важный момент: инструменты всегда выбираются из контекста задачи.
Когда мы говорим о достаточно большом объёме JavaScript-кода, за такими решениями, как правило, стоят нетривиальные проблемы.
Давайте порассуждаем. Представим трейдинговую платформу с:
реалтайм-обновлениями через WebSocket,
REST API,
банковскими формами,
фича-флагами
и прочий «радостью».
Как вы собираетесь грузить такую систему с минимальным количеством кода?
И даже если каким-то чудом у вас получится — как вы будете масштабировать это решение на десяток продуктовых команд?
А теперь добавим унифицированную платформу, где вместе с вебом живёт и мобильная разработка. И разработчиков там ещё больше, потому что нужно поддерживать две кардинально разные платформы.
И тут появляется основной барьер для быстрой доставки кода — релизы.
В результате ваше «минималистичное» решение превращается в тот самый ужас, о котором вы и пишете. Вы можете с этим мириться, можете отрицать, но отрицание — это всего лишь одна из стадий принятия неизбежного.
Вопрос про BDUI в целом. Чем отправка виртуального дерева Реакта лучше отправки готового HTML? Асинхронный парсинг и отображение будут работать из коробки. Тем более, что Реакт предоставляет инструмент для преобразования виртуального дерева в HTML на сервере с дальнейшим «оживлением» на клиенте.
Как я понял, вы хотите реализовать SSR с парсингом JSON на сервере, а затем гидрировать это на клиенте? Если так, то такой подход довольно распространён.
Однако возникает вопрос: как в таком случае вы планируете обрабатывать динамические элементы интерфейса — такие как порталы, модалки и прочие компоненты, которые могут быть добавлены или удалены из DOM по мере взаимодействия?
Я встречал похожую реализацию, например, с BDUI на базе Next.js — так что почему бы и нет. Хотя стоит отметить, что тема SSR на Node достаточно холиварная и дискуссионная. Кому-то такой подход в принципе не подходит.
В случае с PWA мы, например, не стремимся выносить логику на сервер — зачем, если основная идея в том, что пользователь «устанавливает» приложение как аналог мобильного, а всё кешируется на уровне service worker’ов?
Как улучшить UX в PWA на React с помощью потокового Backend-Driven UI — личный опыт