HTML, CSS и JavaScript или React: что выбрать для сайта

01

HTML или React: выбирать нужно по сценарию сайта

Вопрос «HTML или React» некорректно ставить как выбор между старым и новым. HTML остаётся основой любой страницы: он задаёт структуру, заголовки, ссылки, форму и содержание для браузера и поискового робота. CSS отвечает за внешний вид, а JavaScript добавляет поведение. React — библиотека JavaScript, которая помогает собирать интерфейс из компонентов и синхронизировать его с данными. Поэтому реальный выбор выглядит так: оставить интерфейс на обычном JavaScript или строить его как React-приложение.

Для маркетингового сайта оценивайте не название технологии в смете, а путь пользователя. Открыл рекламу с UTM-метками, прочитал предложение, выбрал услугу, отправил форму — это короткий сценарий с несколькими действиями. Здесь приоритетны адаптивность, скорость первой загрузки, корректные метатеги, отправка полей в CRM и удобство редактора 1С-Битрикс. В большинстве таких случаев качественная HTML-вёрстка с небольшими JavaScript-модулями будет проще, дешевле в поддержке и надёжнее.

Другая ситуация — пользователь несколько минут работает внутри интерфейса: меняет фильтры, добавляет позиции, видит пересчёт цены, получает статусы заказа, загружает документы. Количество состояний растёт, данные приходят из API, а части экрана обновляются независимо. Если такую логику собирать разрозненными обработчиками на обычном JavaScript, изменения становятся рискованными. React помогает явно описать состояние экрана и повторно использовать компоненты.

На сайте на 1С-Битрикс эти подходы нередко сочетаются. Контентные страницы и SEO-разделы выводятся штатными компонентами и шаблонами, а интерактивный блок кабинета, расчёта или поиска подключается отдельным React-приложением. Не нужно переводить весь сайт на React ради одного калькулятора.

03

Лендинг: обычная вёрстка почти всегда практичнее

Лендинг продаёт один продукт, услугу или кампанию. Его основная работа происходит до клика: быстро показать смысл предложения, обеспечить понятную структуру, пройти проверку мобильной версии и не потерять заявку. Типовой набор интерактива — меню, слайдер, аккордеон FAQ, маска телефона, форма и несколько событий аналитики. Для этого не требуется хранить сложное состояние приложения: достаточно HTML, CSS и аккуратного JavaScript.

Такой подход особенно удобен в 1С-Битрикс. Контент-менеджер меняет текст и изображения через инфоблоки, разработчик настраивает шаблон компонента, а форма передаёт в CRM имя, телефон, email, страницу, источник и UTM. Серверная обработка должна валидировать данные: клиентский JavaScript улучшает опыт, но не является единственной защитой от пустых и некорректных отправок.

React на лендинге создаёт дополнительные задачи: нужно собрать и подключить бандл, контролировать его вес, продумать рендеринг для SEO и обеспечить корректную работу при ошибке загрузки скрипта. Это допустимая цена для сложного интерактива, но лишняя для первого экрана и простой формы. Для проверки разметки и производительности используйте рекомендации из документации 1С-Битрикс по композитному сайту.

04

Каталог: граница проходит по фильтрам и данным

Каталог сам по себе не повод внедрять React. Если посетитель открывает раздел, выбирает товар, переходит в карточку и добавляет его в корзину, серверный вывод 1С-Битрикс хорошо решает задачу. Страница имеет понятный URL, поисковик видит текст и товары, а фильтр может работать с перезагрузкой. Это предсказуемо для SEO и проще при обновлении цен, остатков и торговых предложений.

React или обычный JavaScript стоит обсуждать, когда фильтрация должна менять выдачу мгновенно, без потери выбранных параметров, а покупатель сравнивает варианты в одной сессии. Важно не ограничиться визуальной частью. Для каждого состояния фильтра определите, какие параметры попадают в URL, можно ли открыть ссылку повторно, как обрабатывается пустая выдача и не создаются ли тысячи бесполезных страниц для индексации.

Отдельный риск — два независимых источника данных. Например, сервер отдал остаток товара, а React после загрузки получил из API другой остаток. Пользователь увидит «в наличии», затем кнопку «нет в наличии». До разработки нужно назначить источник истины, частоту обновления и сценарий ошибки API.

05

Личный кабинет: React окупается при сложной работе пользователя

Личный кабинет отличается от публичного сайта не цветом кнопок, а количеством правил. У пользователя есть роль, организация, права на документы, история операций и статусы. Он может создать обращение, изменить профиль, скачать акт, повторить заказ или согласовать действие. Экран зависит от данных, а данные зависят от предыдущих действий. Здесь компонентный интерфейс снижает стоимость дальнейших изменений.

React полезен, когда одни и те же элементы повторяются в разных разделах: таблица, фильтр, карточка статуса, модальное окно, форма с валидацией. Вместо копирования логики команда использует общие компоненты. Однако React не заменяет бэкенд. Проверка прав, расчёт цены, изменение статуса и запись в базу должны происходить на сервере. Браузер отвечает за удобное отображение, но не за бизнес-правила.

Для сайта на 1С-Битрикс заранее согласуйте контракт API: метод, обязательные поля, типы ошибок и авторизацию. Например, ответ на запрос списка заказов должен содержать не только позиции, но и pagination, допустимые действия и понятный код ошибки. Без этого фронтенд будет угадывать бизнес-логику по текстам уведомлений.

06

Как принять работу: проверка без погружения в код

Маркетологу или руководителю не нужно оценивать архитектуру по названию фреймворка. Проверяйте наблюдаемый результат и заранее подготовленные сценарии. Откройте сайт в новом браузере, перейдите по рекламной ссылке с UTM, пройдите путь до заявки или заказа и сравните результат с тем, что видит менеджер в CRM. Это покажет больше, чем демонстрация на компьютере разработчика.

Для React-интерфейса отдельно проверяйте состояния: загрузку, пустой список, ошибку сети, отсутствие прав и повторную отправку формы. Пользователь не должен видеть бесконечный индикатор или техническое сообщение. Для обычной вёрстки критичны адаптивность, доступность кнопок без JavaScript там, где это возможно, и отсутствие прыжков страницы после загрузки скриптов.

На проектах ICONICA такую проверку фиксируют как набор приёмочных сценариев. Если нужны примеры состава интерфейсных работ, можно ориентироваться на опубликованные кейсы в портфолио ICONICA, а не на условные скриншоты.

1. 1

   Проверьте первый рендер. Откройте публичную страницу при отключённом кеше: заголовок, основной текст и кнопка должны появиться без заметной задержки.

2. 2

   Пройдите путь с UTM. Откройте ссылку с utm_source и utm_campaign, отправьте форму и сверьте значения в CRM или журнале интеграции.

3. 3

   Смените состояния. В каталоге примените и сбросьте фильтр, обновите страницу, откройте сохранённый URL и проверьте тот же результат.

4. 4

   Сымитируйте ошибку. В кабинете проверьте текст и действие при недоступном API, истёкшей сессии и отсутствии нужных прав.

5. 5

   Сверьте данные на сервере. Итоговая цена, статус и права должны подтверждаться бэкендом, а не только меняться в браузере.

07

Ошибки выбора технологий и их последствия

Самая частая ошибка — заказать React как универсальное решение, не описав сценарии. В итоге простой сайт получает тяжёлую клиентскую сборку, контент сложнее редактировать, а разработка любой новой секции требует фронтендера. Обратная ошибка — пытаться собрать кабинет из десятков независимых скриптов. Первые релизы кажутся быстрыми, но затем изменения одного фильтра ломают корзину или таблицу статусов.

Не менее опасно переносить бизнес-логику в браузер. Скрытая кнопка не является ограничением доступа. Если API позволяет сменить статус заказа без серверной проверки роли, пользователь может вызвать запрос напрямую. Для финансовых действий, документов и персональных данных права, журналирование и валидация обязательны на бэкенде.

Наконец, не забывайте о сопровождении. Зафиксируйте версии зависимостей, способ сборки, репозиторий, доступы и порядок выпуска. Иначе через год даже небольшая правка превращается в поиск исходников и человека, который понимает старую сборку.

09

Какое решение принять для вашего сайта

Если сайт в первую очередь рассказывает о компании, услугах и товарах, начинайте с качественной HTML-вёрстки, CSS и небольших JavaScript-модулей. Это не компромисс, а рациональная архитектура для страниц, где важны скорость, SEO, редактирование в 1С-Битрикс и надёжная передача заявок. Сначала проверьте структуру контента, форму, мобильную версию и аналитику — они обычно влияют на результат сильнее, чем выбор библиотеки.

React стоит выбирать для частей продукта, где пользователь долго работает с данными: личного кабинета, конфигуратора, сложного поиска, таблиц с фильтрами, статусов и многослойных прав. Зафиксируйте до старта API, источник истины, сценарии ошибок, требования к URL и серверную проверку операций. Так React станет управляемым инструментом, а не дополнительным слоем сложности.

Если каталог или кабинет уже существует и команда спорит о переписывании, не начинайте с полной замены. Соберите список проблемных сценариев, оцените ошибки, время изменения и влияние на конверсию. Подрядчика стоит подключать, когда нужны прототип, техническая декомпозиция, интеграция с API или безопасная поэтапная миграция без остановки сайта.