Фреймворк не нужен: почему разработчики возвращаются к чистому HTML

Недавно я прочёл статью разработчика Джоэла Дэйра о том, почему он снова пишет сайты на чистом HTML и CSS. Без React, сборщика и небольшого посёлка из npm-пакетов.

Первая реакция была предсказуемой: ну да, очередной текст про то, что раньше интернет был быстрее, деревья выше, а для запуска сайта хватало файла index.html.

Но чем дальше я читал, тем меньше это походило на ностальгию.

Скорее, автор задаёт довольно неудобный вопрос: почему мы используем архитектуру сложного приложения для страниц, которым она вообще не нужна?

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

В теории это несколько HTML-страниц, стили и немного JavaScript.

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

Проходит пара дней, а формы обратной связи всё ещё нет. Зато уже можно долго обсуждать структуру компонентов.

Я не против фреймворков. Сам по себе React ни в чём не виноват. Проблема начинается, когда технология выбирается автоматически, ещё до того, как команда разобралась в задаче.

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

За последние годы возможности браузеров заметно выросли.

Диалоговые окна можно создавать через

, раскрывающиеся блоки — через , базовая проверка форм работает без дополнительных библиотек. Grid и Flexbox давно закрывают большую часть задач с раскладкой.

Это не значит, что JavaScript больше не нужен. Просто иногда мы подключаем его раньше, чем возникает реальная необходимость.

Мне кажется, правильный вопрос сегодня звучит не так:

Какой фреймворк выбрать для сайта?

А примерно так:

Что в этом проекте нельзя нормально сделать средствами браузера?

Если таких задач много, берём подходящий фреймворк. Если их почти нет, возможно, он только увеличит стоимость разработки и поддержки.

Современный фронтенд умеет быть очень удобным. Установил пакет, импортировал компонент — и готово.

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

Самое забавное начинается через пару лет.

Сайт почти не изменился. Тексты те же, услуги те же, форма по-прежнему отправляет имя и телефон. Но проект уже не собирается, потому что изменилась версия среды, устарел плагин или две библиотеки больше не хотят работать вместе.

И команда тратит время не на улучшение продукта, а на восстановление технического окружения.

Чистый HTML тоже приходится поддерживать. Но там меньше движущихся частей. Файл, созданный несколько лет назад, скорее всего, по-прежнему откроется в браузере. Для старого проекта на фреймворке такой уверенности уже нет.

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

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

Но важнее другое: бизнесу обычно не нужен фреймворк как таковой.

Бизнесу нужен результат. Чтобы сайт открывался, заявки отправлялись, страницы находились в поиске, а небольшое изменение не превращалось в отдельный спринт.

Разумеется, экономия должна быть разумной. Написать собственную систему компонентов вместо использования готового решения — это не простота. Это просто другая разновидность сложности.

После подобных статей легко решить, что индустрия наконец признала ошибку и теперь все вернутся к HTML-файлам.

Не думаю.

Фреймворки отлично подходят для сложных веб-приложений: CRM, редакторов, личных кабинетов, сервисов совместной работы и интерфейсов, где данные постоянно меняются без перезагрузки страницы.

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

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

Иногда страница является просто страницей. И в этом нет ничего плохого.

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

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

Если такой проблемы нет, фреймворк сам рискует стать проблемой.

В Paladin Engineering нам близок именно такой подход: сначала разобраться, что действительно требуется продукту, и только потом выбирать стек. Иногда правильным решением будет полноценное веб-приложение. А иногда — быстрый и понятный сайт без лишней архитектуры.

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