Реактивные сайты сейчас — настоящий хайп и вершина технологий. Если всё сделать правильно (и использовать серверный рендеринг), то они будут и молниеносно загружаться и нравиться поисковым системам. Клиенты между тем спрашивают: а почему не сделать просто композитный сайт на Битриксе?
У меня ощущение от композитных сайтов, что они какие-то недоделанные. Что это просто маркетинговая фигня от Битрикса. Придумка интересного слова для давно избитой технологии, которую с горем-пополам смогли в нём реализовать. Сильный маркетинг и встроенный инструментарий Битрикса зомбирует, и на него есть хороший спрос. Это сейчас непобедимо — приходится подстраиваться. Хотя я вижу небольшую тенденцию в сторону фреймворков (особенно на нагруженных проектах). Реактивные проекты с бэкэндом на фреймворке выглядят гораздо бодрее, если уметь их готовить.
Итак, нам поступил вопрос — если клиент выбрал Битрикс, то что лучше: реактивные или композитные сайты. Мол, композитный тоже шустрее обычных, а Реакт и Битрикс такие разные, и для их совместной работы нужна довольно сложная архитектура. Разберёмся, что всё-таки лучше: сайты на React.js или композитные.
React.js — библиотека JavaScript и каркас для веб-приложений, созданный Фейсбуком. Постоянно развивается, имеет развитое сообщество. Ближайший сильный конкурент — Vue.js, тоже очень хорош и оправданно имеет массу поклонников.
SPA — Single-page application это веб-приложение или сайт, которые могут использовать единый HTML-документ как оболочку для всех страниц. Взаимодействие с пользователем происходит через динамически подгружаемые HTML, CSS, JavaScript.
SSR — Server Side Rendering — серверный рендеринг (о нём чуточку ниже).
Композитный сайт
Композитный сайт — технология Битрикса, когда страница разделяется на статическую и динамическую части, где статическая кэшируется и отображается мгновенно, а динамическая подгружается в фоновом режиме.
Плюсы технологии композитных сайтов
- ускоряет загрузку страниц;
- улучшает ранжирование в поисковиках (за счет быстрой загрузки сайта);
- косвенно улучшает конверсию (пользователи любят быстрые сайты).
Ограничения
- нужен сервер с запасом места на диске, чтобы хранить кэш (на самом деле, хватит 2-3 лишних Гб).
Композитные сайты годятся в случае, если динамического контента мало: на корпоративный сайтах, например.
В интернет-магазинах с композитом будут проблемы: например, на каждый вариант фильтра будет создаваться свой кэш — файлов кэша станет много, и сервер может «лечь». А актуальность этого создаваемого кэша может быть сомнительной — например, если сортировка зависит от остатков товара, файлы кэша будут создаваться заново каждый раз. Другая проблема: обычно у композита в каталоге на товарах стоят «заглушки» — если пользователю понадобится полная информация о товаре, он будет ждать её загрузки так же, как на обычном сайте.
React.js (SPA+SSR)
Реактивные сайты на React.js (или Vue.js) работают несколько по-другому: вместо отрисовки HTML-страниц, кода бизнес-логики и шаблонов пишется JavaScript. Зачастую при загрузке страницы сначала грузится пустой «контейнер» (HTML), а затем React рендерит в него содержимое страницы. Если какая-то часть страницы меняется — заново подгружаются только данные для этой части страницы (а не вся страница), а обновление и отрисовка нужных частей страницы осуществляется на стороне клиента. Это ускоряет загрузку и рендеринг, делает сайты очень отзывчивыми.
Использование подходов Redux и MobX позволяет динамически менять содержимое страниц в ответ на действия пользователей (поменяли что-то в одном месте — мгновенно изменения отразились на всех связанных местах, без перезагрузки страниц). Это позволяет строить мощные интерфейсы и хорошо работает в личных кабинетах, системах управления, CRM-системах и т.д.
Использование технологий PWA позволяет также кэшировать данные на стороне клиента, и не обращаться к ним на сервер при повторной необходимости. Но появляется проблема: для поисковиков страницы сайта кажутся пустыми (они видят только каркас страницы) — так в топ выдачи не попасть.
Чтобы решить эту проблему, есть серверный рендеринг: весь нужный HTML-код для загрузки страницы по запросу пользователя генерируется на сервере. Сайт отображается мгновенно, и поисковики довольны: видят всё содержимое сразу.
Плюсы React (SPA+SSR)
- контент загружается быстрее (особенно при плохом соединении и на медленных устройствах);
- улучшает ранжирование в поисковиках (поисковые боты будут видеть полностью отрендеренную страницу);
- бонусом: готовый REST-Api, на база которого легче впоследствии сделать мобильное приложение.
Ограничения
- трудоемкое программирование (вместо генерации всей HTML-страницы, на сервере делается Api (как правило, — REST), а вся отрисовка контента организуется на стороне JavaScript);
- высокий порог входа и дополнительная трудоемкость в поддержке/доработке и добавлении новых функций на проекте (или при редизайне). Вам нужны будут толковые и опытные программисты.
Эти плюсы есть и у других подобных библиотек — например, Vue.js. Здесь, скорее, дело в самом подходе, а не в конкретном инструменте. И да, необязательно пилить весь сайт на React.js — можно реализовать подобным образом только некоторые блоки.
По нашему опыту, проект на реактивных фреймворках потребует процентов на 30 больше ресурсов (хотя тут все очень сильно зависит от задачи). Стоит ли в это вкладываться ради отзывчивости интерфейсов?
Реактивные, обычные и композитные сайты: еще раз о разнице
Существует очень много нюансов, которые позволяют реализовать элементы реактивных или композитных сайтов на самых обычных проектах, и четкую грань провести довольно сложно. Все очень сильно зависит от задачи и опыта разработчика (кстати, догматичность разработчика — зачастую плохой симптом). Примерный расклад выглядит так.
React.js (SPA+SSR)
Реакция на действия пользователя: как только пользователь что-то поменял в одном месте сайта — изменения сразу же применятся ко всем связанным данным, которые есть на сайте (реактивная парадигма).
Наиболее популярная область применения: современные проекты, системы управления чем-либо (CRM, бизнесом) админки, личные кабинеты, калькуляторы.
Контент: весь контент виден сразу при загрузке (моментальная загрузка).
Ссылки: страницы, ссылки на которые находятся в области видимости, подгружаются фоном ещё до перехода на них (зависит от фреймворка, конечно, и применения PWA).
Загрузка страниц: все шаблоны страниц загружаются сразу, и из них страницы строятся на стороне JS.
Кэширование: страницы можно кэшировать на клиенте, поэтому повторный заход на страницу происходит моментально, т.к. нет запросов к серверу (актуально для контентных страниц, метрики могут давать небольшую задержку).
Загрузка данных: то, что уже загружено, повторно можно не запрашивать.
Обычные сайты
Реакция на действия пользователя: изменения от пользователей для применения требуют перезагрузку страниц.
Наиболее популярная область применения: корпоративный сегмент, блоги, e-commerce.
Контент: весь контент виден сразу, но грузится дольше.
Ссылки: клик на ссылку приводит к перезагрузке страницы.
Загрузка страниц: вся страница заново строится на сервере и отдается на клиент — как правило, целиком (включая те блоки страниц, которые не меняются — меню и т.д.).
Кэширование: страницы кэшируются на сервере (можно установить время жизни страницы — в этом случае браузер будет кэшировать статические данные).
Загрузка данных: каждый раз анализируется актуальность кэша.
Композитный сайт
Реакция на действия пользователя: изменения от пользователя, как правило, требуют перезагрузки страниц (и иногда — ожидания создания шаблона).
Наиболее популярная область применения: корпоративный сегмент, блоги, e-commerce.
Контент: сначала видны заглушки (например, вместо товаров — замыленные прямоугольники), потом подтягивается контент (почти как lazy loading для картинок, только для всего сайта).
Ссылки: при клике на ссылку придется ждать, пока страница загрузится — отклик принципиально дольше.
Загрузка страниц: при переходе между страницами загрузка шаблонов каждой новой страницы занимает время (потому что заново запускается весь цикл).
Кэширование: страницы кэшируются на сервере — это дольше (на сервере, как правило, кэшируется либо результат выборки и подготовки данных, либо уже результирующий HTML).
Загрузка данных: каждый раз анализируется кэш на наличие созданных шаблонов
Реактивные сайты сейчас на пике популярности технологий, но решать, конечно, только вам — мы лишь можем рассказать о тонкостях ;)
Заголовок - Реактивные сайты против композитных: что круче
Окончание - Реактивные сайты сейчас на пике популярности технологий, но решать, конечно, только вам — мы лишь можем рассказать о тонкостях ;)
Содержание - Вода
Пожалуйста, не сочтите за критику статьи. Направление логики в ней, как мне кажется, верное, но предпосылки можно пересмотреть.
SPA - ПЕРЕЖИТОК ПРОШЛОГО
React и подобные библиотеки просто не могли (не могут и едва ли уже смогут) обеспечить серверный рендеринг. React - это только клиентский код.
Если бы у них была возможность растащить логику по отдельным файлам, они бы это сделали. Но для этого требуется SSR, чего нет. Вместо этого изобретены велосипеды для асинхронной подгрузки кусочков огромного бандла.
REACT МЕДЛЕННЫЙ
Задолго до React был "unobtrusive JavaScript", придуманный для того, чтобы правильно связывать DOM-nodes с бизнес-логикой, реализованной на JS. Unobtrusive JS очень требователен к организации кода и архитектуре решения.
Чтобы упростить задачу, React скрывает от разработчика этот интерфейс, позволяя описать в одном месте представление данных и их обработку. Это месиво в React называют компонентами.
Стало гораздо удобнее вести разработку, но расплатой за это удобство стала низкая производительность.
У REACT НЕУДАЧНАЯ АРХИТЕКТУРА
React располагает к смешиванию в одном куске кода обработки данных и их отображения. Всё это густо замешано на ООП, который дополнительно отягощен его более чем условной реализацией на Javascript (привет, prototype).
На выходе получается медленный код, который дорого и больно поддерживать.
ВЫВОД
Мы отказались от React в пользу собственного frontend фреймворк nullFront. У нас из коробки идут инструменты, позволяющие фронту эффективно решать все задачи.
Некоторые из них:
1. Серверный рендеринг (SSR)
2. Максимальная производительность web-приложений
3. Возможность реализовать любую стратегию авторизации (без backend)
4. Backend mocking на заглушках (stubs)
5. Бесшовное переключение между stubs и реальным backend. Один раз написали фронт на заглушках, переключили на back и всё работает
6. Различные способы интеграции backend
7. Встроенные инструменты CI/CD
8. Возможность достигнуть 100% покрытия кода модульными текстами
Оправданием для комментария с упоминанием другого фреймворка может быть только то, что сама статья широко упоминает другой примелькавшийся фреймворк. Суета это все. Нет такого фреймворка, на котором нельзя написать плохого приложения, в этом смысле все они одинаковые.
Однако, медлительность React и его плохая архитектура — серьезный повод задуматься. Аргумент «ничего лучше пока нет» изотрется до обидного быстро.
С «Возможности достигнуть 100% покрытия» поржал, спасибо.
Всегда, пожалуйста :)
React провоцирует смешивать вместе обработку данных (бизнес-логику) и их view в кашу. Оттестировать такой замес, конечно, можно, но трудов на это уйдёт уйма.
Разрабатывая front-end на nullFront, мы следуем best practice, которые в свою очередь настаивают на отделении всего препроцессинга данных от отображения.
Отделив данные от отображения, мы получаем чистые функции, которые:
1. На вход получают какие-то данные (чаще всего из ответа сервер)
2. Каким-то образом преобразуют эти данные (та самая бизнес-логика)
3. На выход отдаются готовые для рендеринга данные
Несомненно, такие функции (они же чистые) легко покрываются модульными тестами.
Поэтому 100% покрытие - очень достижимая задача. Не только в теории
Отлично, спасибо. Если не остановиться на том, что в refactoring for testability каждый сам себе злобный Б... кузнец своего счастья, то это слишком даже для пятницы.
«1С нашли способ разогнать. Они разработали и запатентовали технологию композитного сайта, которая магическим образом:
ускоряет загрузку в 100 раз;
улучшает ранжирование в Гугле и Яндексе;
увеличивает конверсию; подходит для любого сайта на 1С-Битрикс;»
Ой все
Комментарий недоступен
В том-то и беда, что React не сильно-то очень хорошо масштабируется.
Был на митапе, где спикер рассказывал, как можно повышать производительность реакт-приложений. Там много разных уловок и ухватов было представлено, но в конечном итоге всё было сведено к тому, что
1. реализовали свой маленький Redux
2. сами обработали события
3. сами ручками вызывали рендер.
Это сделали, чтобы React не обрабатывал все события, потому что их обработка тянула за собой ререндеринг 10 000 узлов DOM. И по-другому было никак: структура компонента не позволяля.
И почему никто не говорит по ангуляр?Порог входа в Angular гораздо выше React. Что соответствующим образом отражается на стоимость владения приложением. А все хотят дешевле