Прогрессивное улучшение по сравнению с одностраничными приложениями

33

Я только что вернулся с конференции в Бостоне под названием An Event Apart .

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

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

Джереми Кит дал особенно проницательный разговор об этом.

Но как насчет одностраничных веб-приложений, таких как Backbone и Angular? Весь дизайн этих фреймворков, похоже, подталкивает разработчика к перемещению контента из HTML в нечто вроде JSON API.

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

— SeanPlusPlus
источник

У них есть два разных варианта использования. Да, есть совпадение, когда сервер выполняет тяжелую работу.

— BobDalgleish

5

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

— Роберт Харви

3

Вы должны попросить Джереми Кейта привести пример из реальной жизни, когда прогрессивное улучшение действительно стоит хлопот с удовольствием 1-10% интернет-пользователей, и спросите данные других 90% пользователей, действительно ли они заинтересованы в прогрессивном улучшении или они счастливы если они могут посетить веб-сайт с IE 5.0 или без JavaScript

— Кири

1

Если тип людей, которые отключают JS / images / и т. Д., Не входит в вашу базовую целевую демографическую группу, то у вас нет веских коммерческих оснований стремиться к прогрессивному улучшению.

— Грэм

1

Поддержка «устройств в сети с низкой пропускной способностью» фактически является аргументом в пользу SPA, а не против него! В SPA вы делаете только один большой запрос, где без JS он у вас есть каждый раз!

— Дмитрий Зайцев

21

Мне кажется, что одностраничные приложения проводят черту в песке прогрессивного улучшения. Если раньше мы могли попытаться обойти тот факт, что реализации и функции различаются в разных браузерах на протяжении десятилетий, SPA предполагают, что существует определенная базовая линия, с которой мы можем разумно согласиться, что большинство посетителей данного сайта встретятся. Я не думаю, что два противоречат. Вы можете продолжать постепенно улучшать после запуска SPA, например, начиная с <video>тега, а затем накладывая на него свой многофункциональный проигрыватель.

Затем есть посетители с отключенными сценариями, но они знают, во что они ввязываются. Я не понимаю, почему разработчики должны отклоняться назад для этих посетителей, кроме примечания «Вам нужны сценарии для этого сайта». Если мы это допустим, почему бы не обслуживать посетителей с отключенным CSS? Как насчет изображений отключен? Это основные веб-технологии. Они не должны ожидать, что у них будет полностью функциональный веб-опыт, когда они будут собирать и выбирать предметы.

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

— Коллин Аллен
источник

3

I don't see why developers should bend over backwards for those visitors, Если в вашем контракте указано, что вам необходимо предоставить доступную версию вашего веб-сайта, использование SPA может оказаться более сложным. И как насчет SEO?

— Саймон Бергот

7

@Simon: Вы также можете сделать SPA доступным (см., Например, stackoverflow.com/questions/15318661/… ). Аналогично для SEO (если SEO имеет значение, что будет зависеть от приложения).

— слеске

2

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

— Роберт Харви

1

Правда, отключение сценариев имеет преимущества для безопасности. Но для большинства посетителей дополнительная безопасность, обеспечиваемая таким выбором, не стоит. Без сценариев Facebook отказывается работать, перерывы в LinkedIn, перерывы в Pinterest, Instagram загружают пустые страницы и т. Д. Если это требуется крупным игрокам, ваш SPA тоже может.

— Коллин Аллен

Только зная FB и LinkedIn, у этих сайтов нет веских причин для разрыва без JS, кроме как для того, чтобы успокоить разработчиков, которые не хотят прилагать усилия для создания приемлемо функционирующего веб-сайта (или чтобы заставить пользователей принять менее безопасные методы просмотра, которые может принести пользу их нижней строке). Если бы они были полнофункциональными веб-приложениями, такими как Plunker, у вас могло бы быть мнение, но большинство «веб-приложений» являются всего лишь «приложениями» в том смысле, что они построены на некоторой платформе. С точки зрения использования, они просто веб-сайты с большим количеством наворотов, чем раньше.

— Диссидентская ярость

6

SPA наиболее полезен, если вы создаете приложение, которое не соответствует классической модели страниц запросов / ответов. В последнее время наблюдается тенденция, когда обычные веб-сайты пишутся как SPA, даже если они прекрасно вписываются в цикл запросов / ответов в Интернете. ИМХО то, что они делают, - это глупые попытки. То, что делают подобные веб-сайты, плохо реализует веб-браузер с большим количеством ошибок и меньшими возможностями.

Идея прогрессивного улучшения и SPA не является взаимоисключающей для этих глупых одностраничных приложений. Вам просто нужен javascript для согласования содержимого (т. Е. Заголовок Accept), чтобы они получали ресурс JSON, который Javascript на SPA может отображать самостоятельно, а не предварительно отображаемые HTML-страницы. Проблемы с такого рода SPA сайтов очевидны, вам нужно дублировать реализацию рендеринга сайта как на сервере, так и на клиенте.

Для настоящих веб-приложений, то есть тех, которые действительно должны быть SPA, поскольку они не вписываются в стандартный шаблон запроса / ответа; Прогрессивное улучшение намного сложнее для настоящих приложений, потому что они на самом деле просто используют браузер в качестве технологической платформы для переноса приложения. Язык сценариев является неотъемлемой частью настоящего веб-приложения, а не только тем, который может быть дополнен для улучшений. Некоторые методы прогрессивного улучшения все еще могут работать (например, замена флэш-видео / аудио на <video>/ <audio>tag), но для настоящих веб-приложений в качестве базового уровня потребуется javascript.

— Ли Райан
источник

+1, но не всегда легко решить, требует ли что-то «действительно» SPA. Например, бизнес-приложения, которые в основном вводят данные, с широким диапазоном сложности в формах. Если большинство форм просты, SPA не "действительно" требуется, поэтому все еще существует напряжение между решениями SPA и не-SPA.

— Синелав

@sinelaw: Большинство бизнес-приложений обычно не должны быть SPA. Есть несколько исключений, например, Электронная таблица, Обработка текстов, но это нечетные. Признаки того, что вам нужен SPA: если вам нужно передать данные с сервера клиенту, не только для одного или двух уведомлений, но и как важнейший элемент приложения, например, игры, отслеживания акций, приложения чата; если ваше приложение не имеет разумного понятия «страница» или понятие «страница» полностью искажено в приложении, например приложения Office. Бизнес-приложения, которые в основном работают с формами, лучше не использовать в качестве SPA.

— Ли Райан

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

— Синелав,

@sinelaw: Создание SPA практически никогда не обходится дешевле, чем создание многостраничных сайтов; особенно если вы все равно не пользуетесь старыми браузерами.

— Ли Райан

Если ваша команда состоит из экспертов SPA с небольшим опытом работы в серверных проектах, это будет дешевле.

— Синелав

2

Я считаю, что одностраничные веб-приложения и прогрессивные улучшения - это почти антагонисты. Если html вычисляется на клиенте по данным, полученным из API-интерфейса json, он вряд ли может ухудшиться изящно. Однако он может предложить более богатый и приятный пользовательский интерфейс.

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

Вы делаете веб-приложение для управления персоналом для конкретной компании? Вам не нужна постепенная деградация, и SPA может быть проще построить. Компания может навязать использование определенного браузера, поэтому у вас может быть меньше тестов.

Вы делаете публичный веб-сайт для ассоциации с требованиями доступности и потребностями видимости поисковой системы? Затем подумайте о создании HTML на вашем сервере. Или создание SPA со статической версией, в зависимости от вашего бюджета.

— Саймон Бергот
источник

1

Я думаю, это зависит от того, насколько далеко вы хотите зайти с Progressive Enhancement - это скорее парадигма дизайна, а не жесткий и быстрый набор правил.

Если вы используете инфраструктуру SPA, я думаю, что разрешить Javascript - это само собой разумеющееся. Однако Javascript, который вы пишете для улучшения своей страницы, должен быть достаточно умным, чтобы иметь дело с любым HTML, который может создать фреймворк.

Вы также можете воспользоваться другими технологиями PE, такими как использование новейших функций CSS для последней версии браузера или ухудшение HTML5 до HTML4.

— philicomus
источник

1

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

— Алан Шутко

@AlanShutko Возможно с фреймами. Несколько страниц, но технически URL не меняется ...;)

— Izkata

1

Да, я думаю, что я больше думал о HTML 5 против HTML 4 и о таких вещах, как CSS для браузера (например, вы можете захотеть использовать совсем недавно реализованную функцию, доступную только в последней версии Chrome, но которая ухудшается до более примитивное управление в старых браузерах). Обойтись без javascript было бы непросто в SPA, но это только одна часть концепции прогрессивного улучшения.

— philicomus

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

— Даниэль Литтл

1

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

Отказоустойчивость в ситуациях, когда файл HTML загружается полностью, но ссылки на скрипты не загружаются полностью благодаря сетевому подключению, которое включается и выключается (возможно в мобильных сетях)
Потенциал для улучшения воспринимаемой производительности при начальной загрузке страницы (за счет сокращения времени начала рендеринга)

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

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

На момент написания статьи, React.js и Ember (с выходом FastBoot), о которых я знаю, имеют или пытаются сделать серверную визуализацию первоклассным гражданином; отображаемая на стороне сервера страница все еще остается работающей SPA, когда она анализируется в клиентском браузере.

— Элиот Сайкс
источник

0

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

Я не думаю, что это требует двух вещей:

1) настройте все ваши ссылки в качестве стандартных ссылок для запросов / ответов при начальной загрузке, и пусть ваша инфраструктура / библиотека SPA затем заменит их обновленной (интерактивной) версией, как только браузер загрузится и механизм JS определит, что поддержка SPA доступна. Это действительно прогрессивное улучшение; JS загружается поверх существующего html-сайта, и это лучше для поисковых систем, вспомогательных технологий и старых браузеров.

а также

2) Сервер должен реагировать на такие маршруты, как / foo / bar / json и foo / bar, обслуживая правильный формат; Реально, если вы оборачиваете все в макеты и партиалы, чтобы получить первую страницу, вы должны иметь возможность получить все через макеты и партиалы также для 2-й и последующих страниц.

Здесь есть немало работы; по общему признанию, но если у вас есть контроль над полным стеком, это уравновешивает две технологии.

— Криспен Смит
источник