Что такое «высокопроизводительное веб-приложение» или «интерфейс»?

После заката эры Internet Explorer экосистема JavaScript становится все более мощной, а термин «интерфейс» стал синонимом высокопроизводительных современных веб-клиентов. В основе этого мира «интерфейса» лежит React. На самом деле, отказ от использования React при фронтенд-разработке часто заставляет вас выглядеть изгоем.

Но так же, как не каждая игра является AAA, мы должны тщательно учитывать, что мы подразумеваем под «высокой производительностью», когда обсуждаем веб-приложения. Это различие имеет решающее значение для обсуждаемой сегодня темы.

1. Область применения высокопроизводительных веб-приложений

В большинстве случаев термин «высокопроизводительное веб-приложение» относится к интерактивному динамическому веб-клиенту, созданному с использованием фреймворков на основе JavaScript, таких как React, Vue или Angular. Эти приложения обычно отличаются быстрой загрузкой и маршрутизацией на стороне клиента, а виртуальный DOM React играет важную роль в повышении скорости рендеринга.

Однако существуют веб-приложения, которые используют все 4 ГБ ограничения памяти модуля WASM, созданы с учетом систематического управления памятью и нацелены на производительность на уровне собственных программ, таких как Blender или 3Ds Max. Эти приложения больше соответствуют концепции «программ», которые используют каждый ресурс вкладки браузера, а не традиционным «веб-страницам», оптимизированным для SEO.

Хотя нынешние браузерные среды все еще могут с трудом обеспечивать производительность, подобную нативной, из-за ограничений памяти и дополнительных затрат, цели таких приложений фундаментально различны. Они обрабатывают большие наборы данных и стремятся использовать все 2–4 ГБ памяти, обеспечивая при этом максимальную скорость рендеринга.

Учитывая, что проблемы, с которыми сталкиваются эти типы веб-приложений, отличаются от проблем, с которыми сталкиваются типичные «высокопроизводительные» приложения, направления, которые они преследуют, также расходятся.

Упомянутое в начале «высокопроизводительное веб-приложение» и то, которое я описываю здесь, принципиально отличаются по своим направлениям. Объединить их в один термин было бы проблематично. Нам нужна другая терминология, чтобы отразить эти различия.

Вот почему я предлагаю перестать называть последнее «высокопроизводительным веб-приложением» или «интерфейсом» и вместо этого использовать следующие термины:

• Высокопроизводительная платформа разработки на основе браузера (BBHPFE)
• (На основе браузера) Разработка высокопроизводительных систем (HPSE)

Я считаю, что эти термины четко определяют разницу в требованиях между интерфейсом и HPSE. Не каждый браузерный клиент является интерфейсом; некоторые из них являются HPSE. Рассмотрим следующий пример, чтобы понять, почему это различие важно:

[Разговор 1]

О: «Я разрабатываю интерфейсное приложение, но не использую React».
Б: «Фронтенд-приложение без React? React занимает более 60% рынка фронтенда! Почему бы вам не использовать его?»

[Разговор 2]

О: «Я разрабатываю приложение для HPSE, но не использую React».
Б: «Это имеет смысл для HPSE. Игровые компании часто широко настраивают свои движки, но внутренние функции React и конвейер рендеринга не могут быть изменены. Он никогда не предназначался для этой цели».

Теперь давайте обсудим основные компоненты, которыми должен обладать HPSE.

2-1. Управление памятью
Нельзя говорить о высокопроизводительных программах без обращения к памяти. Независимо от того, используете ли вы сборщик мусора или освобождаете динамически выделенную память вручную, неиспользуемая память всегда должна быть освобождена.

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

Если ссылки на старые данные не будут освобождены должным образом, использование памяти будет расти с каждым переходом карты. Как только он достигнет примерно 2 ГБ, вы можете столкнуться с ошибкой «Недостаточно памяти», и браузер выйдет из строя.

Это правда, что JavaScript не был разработан для низкоуровневого управления памятью — ни язык, ни философия его разработчиков не ставят его в приоритет. Я не говорю, что управление памятью всегда имеет решающее значение, но, как говорится, «бесплатных обедов не бывает». Если управление памятью необходимо, это необходимо сделать.

2-2. Гибкость в удовлетворении требований
Однажды я услышал, как кто-то сказал: «К тому времени, когда вы перейдете от младшего разработчика к среднему разработчику, вы сможете создать все, что от вас попросят».

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

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

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

Например, вы когда-нибудь слышали, что Lost Ark был построен на Unreal Engine 3? Unreal Engine 5 уже вышел, но они по-прежнему используют Unreal Engine 3, созданный в 2004 году. Чтобы поддерживать проект до сих пор, им пришлось внести значительные изменения в движок — практически полную переработку. Из-за особенностей игры им приходилось постоянно настраивать конвейер и цикл рендеринга с помощью таких методов, как отложенный рендеринг, создание экземпляров, отбраковка и отражение экранного пространства, чтобы удовлетворить требования к производительности и эстетике.

Возможность изменять исходный код движка имела решающее значение. Если бы движок был закрыт или слишком тесно связан, чтобы можно было вносить модификации, Lost Ark, возможно, никогда бы не был разработан.

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

2-3. Неизбежный объектно-ориентированный подход
При работе с крупномасштабными программами одно становится неизбежным: объектно-ориентированное программирование (ООП).

JavaScript — это мультипарадигмальный язык, и функциональное программирование (FP) широко используется. Однако FP, хотя и подходит для веб-клиентов, редко используется в крупномасштабных программах, где несколько объектов взаимодействуют сложным образом, поскольку экземпляры FP не имеют внутренних состояний.

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

Хотя ООП не всегда является лучшим выбором, трудно придумать лучшую альтернативу, учитывая индивидуальные потребности разработки HPSE. Многие крупномасштабные программы, включая операционные системы и игры, построены с использованием принципов ООП. Даже самые популярные исходные коды движка объектно-ориентированные с небольшими вариациями в методологии.

Разработчики, участвовавшие в крупных проектах, наверняка знакомы с ООП. Это делает разработку на основе ООП благоприятной для совместной работы.

Тем не менее, нет необходимости сбрасывать со счетов сильные стороны JavaScript. Поскольку JavaScript поддерживает функции и объявления констант, простые функции модуля, не требующие экземпляров, могут быть определены как литералы объектов с использованием констант или функций. Это может повысить производительность и воспользоваться универсальностью JavaScript.

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