Почему такой радикальный выбор?
Вот. Цитата:
We’ve tried and failed a couple of times
...
We determined that google was indexing our sites well enough for our needs without server rendering, so we dropped it in favor of code-splitting + service worker caching.
Вольный перевод:
Мы пытались подружить сервер-рендеринг и ленивую загрузку и ничего не вышло....
Мы плюнули на это так как Гугл норм индексирует наши сайты и без сервер-рендеринга. И из двух этих трудноуживающихся между собой штук выбрали разделение кода с кэшированием.
Особенности российских реалий - большая часть трафика с Яндекса - и некоторые другие соображения не дают мне отказаться от сервер-рендеринга. Но я могу отказаться от универсальности кода, при этом даже сохранив большую часть общих для сервера и фронта шаблонов на Реакте.
Но не могу решить решить что большее зло:
1) Использовать "изоморфность" и заставить пользователя один раз загрузить огромный JS-бандл со всем приложением:
+ Бандл закэшируется и в дальнейшем либо вообще не будет грузиться, либо подгрузится из кэша браузера
+ "Изоморфный" код не будет рендерить весь интерфейс при инициализации, а просто свяжет виртуальный DOM и реальный
- Пользователю придется загрузить ОЧЕНЬ большой бандл с модулями, который, вероятно, ему вообще не понадобятся
2) Отказаться от "изоморфности", просто рендерить код на сервере, а потом заменять его на фронте кодом приложения:
+ Можно разделить бандл на много мелких модулей и подгружать только те, который нужны пользователю в данный момент
- Отрендеренную на сервере разметку будет подменять Реакт на фронте после загрузки, правда, один раз, потом он подключает свой роутинг и работает без участия сервера
В обоих случаях благодаря серверному рендерингу пользователь будет видеть интерфейс во время загрузки и даже сможет взаимодействовать с ним в режиме no-javascript.
Хотелось бы услышать мнения и доводы, возможно, альтернативные решения.
Простой
