Серверный рендеринг — это истина Тиля

Недавно я обдумывал, как бы я ответил Питер Тиль вопрос на собеседовании, если бы мой ответ касался программного обеспечения:

В какой важной истине с вами согласны очень немногие люди?

Мой ответ: рендеринг на стороне сервера — лучший выбор для многих приложений:

1. это дешевле реализовать
2. легче исправить
3. часто он такой же быстрый, или его ТТХ другие, но приемлемые.
4. пользователи предпочли бы ваше приложение в качестве веб-сайта

Вам это кажется бесспорным? Я рад, но спросите себя: как часто вы сталкиваетесь с «приложениями» React, состоящими из пары форм? Ссылки, которые нельзя открыть в новой вкладке? Загружать счетчики до отображения глубокой ссылки на сайте электронной коммерции? Похоже, что на практике отрасль не согласна с этим.

Рендеринг на стороне клиента процветал за десять лет, что я работаю в этой отрасли (а я много работал на стороне клиента). Люди, новички в отрасли, возможно, никогда не создавали приложения, отображаемые на стороне сервера, поэтому для них это не открытый вопрос. В результате для большинства клиентов рендеринг является, бесспорно, «правильным» способом создания программного обеспечения.

Я думаю, они ошибаются: рендеринг на стороне сервера чаще всего является лучшим выбором.

Почему?

Более дешевый

В любом случае вам понадобится бэкэнд. Ему необходимо будет предоставить данные пользователям. Представить его в виде HTML не сложнее, чем сделать это через JSON или GraphQL. Преобразование данных в HTML по-прежнему требуется при рендеринге на стороне клиента, поэтому на стороне клиента не экономится работа, но возникают свои собственные затраты.

Исправить проще

Вы избегаете сложных проблем, характерных для рендеринга на стороне клиента. На вашей клиентской стороне будет свое собственное состояние, которое нужно учитывать поверх состояния вашего бэкэнда, а именно состояние усложняет программирование. Это долгоживущее состояние (по сравнению с обработчиком HTTP-запросов), поэтому утечки ресурсов и несогласованность будут представлять большую проблему. Вы пишете распределенную систему: состояние клиента и сервера не синхронизировано волшебным образом.

Чем меньше все это кажется вам пугающим, тем менее сложной является ваша клиентская часть и, следовательно, тем меньше оправданий для рендеринга на стороне клиента.

Так же быстро или быстрее

Клиентские приложения представляют собой наборы Javascript, которые необходимо загрузить и проанализировать, прежде чем они смогут загрузить и проанализировать JSON, который затем можно будет преобразовать в HTML. Точно ничего в этом нет оптимально для браузеров и сетей. Многие приложения используются нечасто, а кэш браузера не является волшебством (и я не согласен с вами по поводу того, насколько важно ваше приложение), поэтому утверждать, что «каждый пользователь должен загрузить его только один раз», — чушь собачья.

Если ваше приложение не используется часто и в течение приличного периода времени, с большим количеством взаимодействий с малой задержкой (формы не в счет: например, редактирование, итерация), оно, безусловно, будет быстрее отображаться на стороне сервера.

Люди не хотят устанавливать ваше приложение

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

Выводы

Рендеринг на стороне клиента (очевидно) необходимый для поддержки сложных взаимодействий с чрезвычайно низкой задержкой: Figma или Google Docs могут быть только клиентскими приложениями.

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

Это вредный для приложений только для чтения или приложений, предназначенных преимущественно для чтения. Вредно для разработчиков, поскольку требует ненужных затрат, вредно для пользователей, поскольку оно, вероятно, медленнее, с меньшей вероятностью правильно использует веб-платформу и менее доступно. Ненадлежащее использование рендеринга на стороне клиента — вот почему, чтобы узнать свой счет за электроэнергию, мне приходится ждать около 10 секунд, пока большое приложение React загружается, а затем обращается к 5 конечным точкам REST.

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

PS не верите, что это может быть быстро? Быстро побродите по D-Форум – это во много-много раз быстрее, чем большинство приложений, отображаемых на стороне клиента, которые я использую. О, и GitHub (источник: я работал там) в подавляющем большинстве случаев визуализируется на стороне сервера (с помощью Rails, ох) и как и StackOverflow. Удивительно, что это истина Тиля.

---

Благодаря Энди Эпплтон для рассмотрения и предложений.