Долгое время прогрессивное совершенствование (progressive enhancement, PE) и фронтенд-фреймворки JavaScript считались несовместимыми. Из-за этого создание современных веб-приложений, удовлетворяющих всем случаям использования, было реальной проблемой. Однако постепенное развитие фронтенд-технологий привело к появлению новых возможностей. Предлагаю оценить доступные шаблоны проектирования и сценарии использования с учетом их влияния на бизнес, чтобы вы могли выбрать наиболее приемлемый подход для своего проекта.
Какую проблему решает прогрессивное совершенствование?
Согласно общепринятому определению, PE обеспечивает пользователям высокий уровень надежности, поскольку гарантирует использование приложения только с помощью HTML — другие «слои», такие как шрифты, стили и JavaScript, рассматриваются как совершенствования. С этим определением можно поспорить, но в данной статье будем придерживаться именно его, поскольку оно отвечает ее целям.
Как отмечает Gov.uk, PE — попытка «предоставить всем пользователям максимальные шансы на успех». Это немаловажно, даже если количество посетителей, чей браузер не может загрузить JavaScript или загружает его некорректно, невелико. Тщательное тестирование, проведенное Gov.uk, выявило, что 1,1 % посетителей не могли пользоваться «JavaScript-совершенствованиями». Таким образом, постепенно улучшаемый сайт должен быть пригоден для использования почти 100 % пользователей.
Какие проблемы решают UI-фреймворки?
UI-фреймворки решают множество проблем, связанных с архитектурой и дизайном приложений. Они обеспечивают разработчикам четкое разделение проблем между UI, бизнес-логикой и данными, а также масштабируемую обработку сложных взаимодействий. Они позволяют осуществлять разработку на основе компонентов (CDD), что изменило подходы организаций к проектированию, разработке сопутствующего пользовательского интерфейса и управлению им. Языки шаблонов, такие как Handlebars, пытались решить эту проблему, но не предлагали такой мощности, структуры и гибкости, как UI-фреймворки.
Стандартные типы архитектуры
Рассмотрим основные доступные сегодня шаблоны.
Одностраничные приложения (Single Page App, SPA)
UI представляется и управляется с помощью скриптов на стороне клиента (JavaScript) и часто таких инструментов, как React или Angular.
Причины популярности SPA:
- удовлетворительный пользовательский (обновляются только части страниц);
- веб-интерфейс, чрезвычайно быстро реагирующий на действия пользователя;
- возможность у UI-разработчика использовать единый модульный способ создания GUI.
Отвечают ли SPA требованиям PE?
HTML не отображается на сервере, поэтому пользователь не может взаимодействовать с UI до того, как JavaScript загрузится, пройдет парсинг и выполнит свою работу. Это означает, что SPA не отвечают требованиям PE.
Прогрессивные веб-приложения (Progressive Web App, PWA)
PWA предоставляют пользователям нативные приложения, применяя веб-технологии. Хотя название этих приложений предполагает, что они построены с использованием прогрессивных совершенствований, это не всегда так. Тем не менее они используют локальное кэширование, которое рассматривает сеть как дополнение, что дает им потенциал быть более прогрессивными, чем любая другая форма веб-приложений.
Причины популярности PWA:
- нативность (возможность установки, возможность работы в автономном режиме, доступ к аппаратным функциям);
- кроссплатформенность (возможность собрать один раз, развернуть в любом месте).
Отвечают ли PWA требованиям PE?
Хотя PWA полагаются на функцию JavaScript под названием Service Worker, они предлагают разработчикам множество стратегий кэширования. Так что создание HTML-приложения, устанавливаемого и работающего в автономном режиме, безусловно, возможно. Однако необходимо подумать о том, как будет отображаться HTML. Некоторые PWA также являются SPA, где контент отображается с помощью JavaScript, и в этом случае они не будут соответствовать требованиям PE.
Приложения JAMStack
Приложения, созданные с использованием подхода JAMStack (JAM = JS + API + Markup (разметка), рендерят страницы через сервер сборки и генерируют HTML на основе изменений, обнаруженных в других программных компонентах, таких как CMS, PIM или кодовая база UI.
Причины популярности JAMStack-приложений:
- эффективное разделение задач;
- безопасность из-за малого пространства для атак;
- быстрота за счет того, что страницы отображаются заранее.
Отвечают ли JAMStack-приложения требованиям PE?
Веб-сайты JAMStack могут соответствовать требованиям PE, но, как и в случае с MPA (см. ниже), создание функционального, динамического, высокоперсонализированного UI может потребовать использования других шаблонов, что увеличит сложность и стоимость.
Многостраничные приложения (Multi-page app, MPA)
MPA — оригинальный шаблон сайта, в котором каждая «страница» загружается с сервера, когда пользователь переходит к новому документу.
Причины популярности MPA:
- простота разработки и сопровождения (при условии низкого уровня сложности UI);
- поддержка широким спектром платформ, таких как CMS, системами электронной коммерции и CRM.
Отвечают ли MPA требованиям PE?
Да, поскольку MPA ориентируются на предварительный рендеринг — либо посредством рендеринга на стороне сервера, либо через генерацию статического сайта. В обоих случаях каждая обслуживаемая страница представляет собой пользовательский интерфейс, наполненный контентом и собственными интерактивными элементами, по которым пользователь может перемещаться без JavaScript.
Субшаблоны (sub-patterns)
Стоит кратко остановиться на паре используемых субшаблонов:
- острова: часть страницы занимает клиентский скриптинг;
- потоковая передача: инкрементальный вывод UI-компонента на клиент.
В обоих случаях прогрессивное улучшение может быть достигнуто, но потребуются дополнительные усилия для создания резервного контента на сервере.
Соответствие архитектур сценариям использования
Лори Восс утверждает, что есть два сценария использования, для которых необходимо создавать приложения:
- многостраничное приложение, или «сайт» (статичный текст и изображения, используемые отдельными страницами, например блог);
- одностраничное веб-приложение, или «приложение» (интерактивный инструмент для выполнения задач или использования мультимедиа, например банковский портал).
Однако существует множество веб-приложений, которые должны удовлетворять комбинации этих сценариев использования (Джереми Кит называет ее «спектром»). Это означает, что во многих крупномасштабных онлайн-проектах используется комбинация различных архитектурных шаблонов:
- рендеринг на стороне сервера (SSR);
- генерация статических сайтов (SSG);
- рендеринг на стороне клиента (CSR).
В одном из недавних проектов, который я вел, публичный сайт был выполнен в виде статического сайта, чтобы соответствовать требованиям SEO, а частный сайт для членов клуба — в виде одностраничного приложения.
Соответствие архитектур нормативным требованиям
Для многих организаций PE — это выбор решения. Но если вы подпадаете под действие руководящих принципов таких структур, как CDDO (Central Digital and Data Office — Центральное управление цифровыми технологиями и обработкой данных) в Великобритании, то понять, где проходит грань между предоставлением «существенного контента» и позволением JS взять верх, непросто.
Команда разработчиков Gov.uk приводит интересный пример, показывающий, когда она делает исключения из чистого PE-подхода: «Недавно мы с помощью React создали прототип системы веб-чата. Трудно представить веб-чат базового уровня, не требующий JavaScript, но мы позаботимся о том, чтобы любая система веб-чата, которую мы разрабатываем, имела стандартную контактную форму в качестве основы».
В плане инклюзивности я полностью поддерживаю такой подход. Однако применительно к бизнесу это создание двух решений для решения одной проблемы. Стоит отметить, что зачастую затраты оправдывают вложения, поскольку вы удовлетворяете потребности всех своих пользователей. Например, для оживленного бизнеса электронной коммерции эти инвестиции могут окупиться уже через несколько недель после релиза.
Если вы окажетесь в ситуации, когда необходимо создать сервис, полностью похожий на приложение, но при этом поддерживающий PE, вам придется выбрать одно из следующих решений:
- создание нативного мобильного приложения, которое не будет подпадать под действие мандата PE, но может затруднить доступ пользователей из-за ограничений распространения мобильных приложений (по сравнению с веб-приложениями);
- создание веб-приложения и его альтернативы на основе HTML, если это возможно;
- создание веб-приложения и предоставление пользователям другого приемлемого способа использования сервиса (например, колл-центра);
- представление управляющему органу обоснования исключения из правил, исходя из сложности требуемой функциональности и сопутствующих затрат на создание двух решений.
Можно ли одновременно съесть и оставить торт?
Какие же новые шаблоны и инструменты предоставляют нам возможность создавать приложения, которые будут одновременно инклюзивными, увлекательными и удовлетворяющими ожиданиям пользователей?
В последние годы появился новый класс фреймворков, называемых рендеринг-фреймворками или мета-фреймворками. Созданные при поддержке крупных сообществ разработчиков UI-фреймворков, они отвечают потребностям организаций в несвязных фронтендах, которые могут рендериться различными способами, но при этом поддерживают компонентно-ориентированную разработку.
Наиболее известными мета-фреймворками являются Next.JS и Gatsby, которые некоторое время тесно конкурировали между собой. Next.js стал лидером рынка, завоевав доверие разработчиков, и получил значительные инвестиции от Vercel (бывший Zeit).
Хотя Next.js является относительно зрелым и, безусловно, популярным, у него есть несколько новых конкурентов, таких как Marko, Astro, Fresh, Rocket и Enhance. Каждый из них предлагает что-то свое, но в основном они сосредоточены на производительности и удобстве для разработчиков (DX).
Следует отметить, что успех этих мета-фреймворков зависит от успеха базовых UI-фреймворков, которые они поддерживают. Большинство из них поддерживают только один конкретный инструмент, как в случае с Next.js (React), Nuxt (Vue) и Sveltekit (Svelte, очевидно). Малое количество программ не зависит от UI-инструментария, в частности Astro.
Достойным внимания конкурентом, предоставляющим фреймворк для UI-разработки с масштабированием и поддержкой PE, является Remix. Это детище Майкла Джексона (не того самого) отвечает постулатам философии прогрессивного совершенствования, что найдет отклик у многих разработчиков. Недавно приобретенный компанией Shopify, Remix имеет все шансы занять лидирующие позиции на рынке.
Заключение
В этой статье мы рассмотрели некоторые ключевые шаблоны и инструменты, а также сценарии использования и бизнес-ограничения при создании (несвязных) пользовательских интерфейсов для веб-приложений.
Эта область переживает серьезный период роста и изменений в связи с предъявляемыми к ней требованиями, и бывает сложно выбрать правильный подход, не разорившись при этом. Хотя это здорово, когда есть большой выбор, мы все же сталкиваемся с серьезной проблемой, которая появилась с момента зарождения Web 2.0: многие из нас пытаются создавать нативные мобильные/десктопные приложения, используя веб-технологии, которые не подходят для этой цели. Комментарий блогера Дома к этой статье как нельзя лучше подытоживает ее:
«Нам нужен общий, общепринятый стандарт для распределенных приложений, не построенный на HTML, CSS и JS. Все, что у нас сейчас есть для HTML, было привязано к чему-то, что предназначалось для другого использования. Нам нужен целостный фреймворк для создания приложений с GUI... который поддерживается всеми операционными системами и платформами, но основан на бинарном коде».
Пока у нас нет единого, распространяемого бинарного файла для создания веб-интерфейсов, но в качестве потенциального решения появился webAssmebly (WASM). Он может решить основную проблему, которая заключается в том, что мы, вероятно, используем неправильную технологию для создания веб-приложений с широким функционалом. Хотя WebAssembly набирает обороты и бросает вызов традиционным приложениям на основе HTML, в настоящее время он должен загружаться через JavaScript и поэтому не отвечает требованиям PE.
А пока будем использовать имеющиеся у нас возможности и взвешивать соотношение затрат и выгод в каждом конкретном случае.
Читайте также:
- Функции call, apply и bind: использование и сравнение
- Rust против JavaScript: повышение производительности на 66 % с помощью WebAssembly
- Эта информация навсегда изменит ваше отношение к коду JavaScript
Читайте нас в Telegram, VK и Дзен
Перевод статьи Richard Bultitude: Progressive enhancement and JavaScript frameworks — a complicated relationship
