Реактивные сайты против композитных: что круче
Реактивные сайты сейчас — настоящий хайп и вершина технологий. Если всё сделать правильно (и использовать серверный рендеринг), то они будут и молниеносно загружаться и нравиться поисковым системам. Клиенты между тем спрашивают: а почему не сделать просто композитный сайт на Битриксе?
Пожалуйста, не сочтите за критику статьи. Направление логики в ней, как мне кажется, верное, но предпосылки можно пересмотреть.
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% покрытия» поржал, спасибо.