Мягкая деградация предполагает, что в старых браузерах и устройствах с меньшими возможностями работа будет хуже. Для решения потенциальных проблем разработчикам рекомендуется предпринять шаги, чтобы избежать ошибок — JavaScript или иных — для своих пользователей. В соответствии с этой философией разработчик может использовать ряд подходов, начиная от обеспечения идеальной работы в браузерах более низкого уровня и заканчивая устранением вопиющих ошибок или даже блокировкой определенных браузеров от доступа к контенту, если известно, что у них есть проблемы. Мы часто встречали этот последний подход на сайтах, поддерживающих только Flash, но им он не ограничивался. Я использовал этот пример «блокпоста с Kodak.com» в моей книге:
В целом, изящная деградация связана с избеганием риска. Проблема заключалась в том, что это создало атмосферу в сети, в которой мы, как разработчики, смирились с идеей отказа в доступе к службам (например, к банковским счетам людей), потому что мы считали конкретный браузер (или браузеры) слишком сложными для работы. Или, во многих случаях, у нас просто не было ни времени, ни бюджета (или и того, и другого) для работы с самым большим количеством браузеров. Трудно совместить проблему кросс-браузерной разработки в 2003 году с тем, с чем мы сталкиваемся сегодня, поскольку тогда мы действительно имели дело только с 2–3 браузерами, но вы должны помнить, что поддержка стандартов в то время была намного хуже. .
Так что же такое прогрессивное улучшение?
В своем выступлении Стив перевернул общепринятое мнение о том, что старые браузеры заслуживают худшего опыта, потому что они менее технически совершенны. Он попросил нас выйти за рамки браузеров и используемых технологий и сосредоточиться на пользовательском опыте, поставив перед нами задачу разработать инклюзивный опыт, который будет работать в самых широких сценариях. Он попросил, чтобы мы сосредоточились на содержании и основных задачах в данном интерфейсе, а затем улучшали опыт, когда это возможно. Мы достигаем этого, накладывая опыт друг на друга, отсюда и «прогрессивное улучшение».
Что особенно интересно в этом подходе, так это то, что с технической точки зрения это по-прежнему изящная деградация, потому что все интерфейсы изящно возвращаются в пригодное для использования состояние. Но это изящная деградация в лучшем виде, направленная на то, чтобы доставить всем удовольствие. Никаких оправданий.
В качестве простого примера рассмотрим поле формы для ввода адреса электронной почты. Если бы мы разметили это так
<input type="email" name="email" id="email">
Я автоматически создаю слои опыта без дополнительных усилий:
- Браузеры, которые не понимают «email» как допустимый тип ввода, будут рассматривать текст «email» как опечатку в моем HTML (например, когда вы вводите «rdio» вместо «радио»… или, может быть, я единственный тот, кто так делает). В результате они вернутся к типу ввода по умолчанию «текст», который можно использовать в каждом браузере, поддерживающем HTML2 и выше.
- Браузеры, которые считают «электронную почту» допустимым типом ввода, предоставят один (или несколько) из многих потенциальных расширенных возможностей:
- В контексте виртуальной клавиатуры браузер может представить клавиатуру, предназначенную для быстрого ввода адресов электронной почты.
- В браузере, который поддерживает автодополнение, он может использовать это как подсказку, чтобы предложить ввести обычно вводимый адрес электронной почты или тот, который был сохранен в профиле пользователя.
- В браузере, который поддерживает проверку HTML5, браузер может проверить это поле на правильность форматирования электронной почты, когда пользователь пытается отправить форму.
- В браузере, который не поддерживает проверку HTML5 (или который не блокирует активную отправку при ошибках проверки — например, Safari) — программа JavaScript, предоставленная разработчиком, может использовать атрибут type в качестве сигнала о том, что она должна проверить поле для правильного адреса электронной почты. форматирование адреса.
Это означает, что существует от 5 до 13 потенциальных переживаний (учитывая все различные возможные комбинации этих слоев) в этом одном-единственном элементе… это просто ошеломляет, правда? И решающим фактором здесь является то, что любой из этих опытов может быть хорошим опытом. Черт возьми, за почти 15 лет существования Интернета простой текстовый ввод был единственным способом ввода адреса электронной почты. Все, что лучше этого, — соус.
Прогрессивное улучшение охватывает идею опыта как континуума, а не какого-то единственного идеала. Он признает, что все люди разные, и у всех нас есть особые требования к доступу в Интернет. Некоторые могут зависеть от нашего браузера, устройства, на котором мы работаем, и сети, которую мы используем. Другие могут быть результатом ограничения, с которым мы сталкиваемся с рождения, с которым временно имеем дело в результате травмы или инцидента, или просто фактором нашей текущей ситуации. Мы все воспринимаем мир по-разному, и прогрессивное улучшение не только учитывает это, но и принимает эту изменчивость.
Как оно работает? Прогрессивное улучшение использует отказоустойчивую природу HTML и CSS. Он также использует собственную способность JavaScript тестировать функции браузера, чтобы адаптировать программные усовершенствования к данному устройству и ситуации. Правильно: прогрессивное улучшение и JavaScript идут рука об руку.
Почему так много любителей JavaScript враждебно относятся к прогрессивному улучшению?
Как член сообщества JavaScript уже более десяти лет, у меня есть теория, почему многие разработчики JavaScript так враждебно относятся к прогрессивному улучшению. Частично это связано с историей, а частично с культурой программирования. Займемся сначала историей.
Когда впервые было предложено прогрессивное улучшение, Интернет становился все более стандартизированным, но все еще оставался некоторый беспорядок… особенно в мире JavaScript. Многие программы на JavaScript были плохо написаны, содержали много кода, специфичного для браузера, и, как правило, были недружелюбны ко всем, кто выходил за рамки относительно узкого диапазона «нормального» использования Интернета… например, к пользователям программ чтения с экрана. Впрочем, это неудивительно: в то время в моде была изящная деградация.
Поскольку программы JavaScript создавали барьеры для пользователей, которые просто хотели читать новостные статьи, получать доступ к общественным службам и проверять свои банковские счета, многие сторонники доступности рекомендовали этим людям отключить JavaScript в своих браузерах. Согласно теории, отключив JavaScript, пользователи получат чистый и четкий доступ к контенту и задачам, для которых они используют Интернет. Конечно, это было еще до «Аякса», но я отвлекся.
Эта рекомендация послужила тревожным звонком для многих разработчиков JavaScript, которые не рассматривали возможность альтернативного просмотра. Некоторые предпочли списать это со счетов и продолжили заниматься своими делами. Другие, однако, приняли вызов сделать JavaScript более удобным для людей, которые полагались на вспомогательные технологии (AT). Многие даже продолжали писать код, который действительно улучшал работу специально для людей, зависимых от AT. Dojo и YUI, хотя и не пользующиеся популярностью в наши дни, были двумя огромными библиотеками, в которых приоритетом была доступность. На самом деле, я бы даже сказал, что они положили начало периоду согласования JavaScript и доступности.
Несмотря на то, что JavaScript и доступность больше не противоречат друг другу (и действительно не противоречили в течение большей части десятилетия), все еще есть люди, которые верят, что это не так. Люди регулярно натыкаются на старые статьи, в которых говорится о недоступности JavaScript, и они разворачиваются и несправедливо демонизируют разработчиков JavaScript как несимпатичных по отношению к людям, которые полагаются на программы чтения с экрана или другие AT. Неудивительно, что некоторые разработчики JavaScript сразу же занимают оборонительную позицию, когда речь заходит о доступности… особенно если это не то, с чем они все хорошо знакомы.
Я также упомянул, что культура программирования играет роль в антагонистических отношениях между сторонниками прогрессивного улучшения и сообществом JavaScript. Если вы хоть какое-то время работали программистом, вы, вероятно, были свидетелями постоянных обвинений, умаления и высокомерия, когда речь шла о языках, которые мы выбираем для программирования, или об инструментах, которые мы для этого используем.
Как программист, вы получаете почти постоянный шквал комментариев по поводу вашего выбора… часто без запроса. Вы используете PHP? Так это 1996 год! Вы все еще используете TextMate?! Вы все еще используете jQuery? Как странно! Я точно не знаю, с чего все это началось, но это нездорово и заставляет многих программистов немедленно защищаться, когда кто-то оспаривает их язык или процесс. И эта враждебно-оборонительная среда очень затрудняет конструктивный разговор о передовом опыте.
Прогрессивное улучшение не следует рассматривать как вызов для JavaScript в большей степени, чем такие концепции, как пространство имен, разработка через тестирование или конкатенация и минимизация файлов; это просто еще один способ улучшить ваш код. Тем не менее, прогрессивное совершенствование создает недостаток, с которым многие хардкорные программисты на JavaScript, похоже, не хотят смириться: JavaScript хрупок. По крайней мере, со стороны клиента, разработка JavaScript требует гораздо большего усердия, когда речь идет об обработке ошибок и откатах, чем традиционное программирование, потому что, в отличие от традиционной разработки программного обеспечения, мы не контролируем среду выполнения.
Дуглас Крокфорд (известно) объявил Интернет самой враждебной средой разработки программного обеспечения, какую только можно себе представить, и он не ошибся. Многое должно быть сделано правильно, чтобы наш код дошел до наших пользователей именно так, как мы задумали. Вот лишь некоторые из этих требований:
- Наш код не должен содержать ошибок;
- Включенный сторонний код не должен содержать ошибок и не должен мешать нашему коду;
- Посредники — интернет-провайдеры, маршрутизаторы и т. д. — не должны внедрять код, а если и внедряют, то он должен быть без ошибок и не мешать нашему коду;
- Плагины браузера не должны мешать нашему коду;
- Браузер должен поддерживать каждую языковую функцию и API, которые мы хотим использовать; и
- Устройство должно иметь достаточно оперативной памяти и достаточно быстрый процессор для запуска нашего кода.
Некоторые из них можно решить с помощью защитного программирования с использованием разработки через тестирование, автоматического тестирования качества, обнаружения функций и обнаружения разметки. Не гарантируется, что они поймают все — разметка может измениться после запуска теста, но до выполнения остального кода, объекты JavaScript изменяемы, что означает, что функции могут случайно исчезнуть и т. д. — но они невероятно полезны для создания надежного JavaScript. программы. Вы также можете запускать свои проекты под HTTPS, чтобы избежать манипуляций посредников с вашим кодом, хотя это тоже не надежно.
Сами устройства мы не контролируем. Мы не можем отправить новое устройство каждому пользователю (или потенциальному пользователю), который у нас есть, только для того, чтобы убедиться, что у них есть соответствующие требования к оборудованию и программному обеспечению для использования нашего продукта». Вместо этого нам нужно писать программы на JavaScript, которые хорошо играть во множестве сценариев (в том числе с ограниченными ресурсами).
И, конечно же, ничто из этого не касается доступности сети. Во многих случаях сетевое подключение пользователя оказывает наибольшее влияние на его работу с нашими продуктами. Если соединение медленное (или ресурсы страницы исключительно велики), процесс загрузки страницы может быть мучительно болезненным. Если соединение обрывается и зависимости не соблюдаются, опыт может казаться бессвязным или полностью нарушенным. Использование Service Worker и хранилища на стороне клиента (indexedDB и Web Storage) определенно может помочь смягчить эти проблемы при повторных посещениях, но они мало помогают при начальной загрузке. Они также вообще не работают, если ваша программа JavaScript не запускается. Что подводит меня к моему последнему пункту.
Когда вы любите такой язык, как JavaScript (как я), вам может быть трудно распознать (или даже признать) его недостатки, но распознавание их является частью того, чтобы стать лучшим программистом. Интернет постоянно развивается, и наше понимание языков, которые мы используем для его создания, расширяется так же быстро, а часто и быстрее, чем их возможности. Таким образом, мы должны оставаться открытыми для новых и различных способов ведения дел. Перемены могут быть пугающими, но они также могут быть и хорошими. Просьба принять во внимание не-JavaScript-опыт не должна рассматриваться как оскорбление JavaScript, а скорее вызов для создания более надежного опыта. В конце концов, наша последняя линия защиты в обеспечении хорошего пользовательского опыта — это обеспечение наименьшего количества зависимостей. Это то, что прогрессивные улучшения требуют от нас.
JavaScript и PE целуются на дереве?
Все это говорит о том, что я не думаю, что JavaScript и прогрессивное улучшение диаметрально противоположны, и я не думаю, что люди, которые любят язык JavaScript или рекламируют философию прогрессивного улучшения, должны быть такими же. Вместе они могут сделать Интернет максимально эффективным.
Фокус прогрессивного улучшения на предоставлении базового опыта, который не делает предположений о функциях браузера, обеспечит надежную основу для любого проекта. Это также помогает нам быть более разумными в отношении того, как мы применяем такие технологии, как HTML, CSS, JavaScript и ARIA, предлагая нам рассмотреть, что происходит, когда эти зависимости не соблюдаются.
JavaScript абсолютно делает пользовательский опыт лучше для всех, кто может извлечь из этого пользу. Это может сделать интерфейсы более доступными. Это может помочь смягчить проблемы с сетью. Это может обеспечить более плавный и беспроблемный опыт для наших пользователей. И это может уменьшить трение, связанное с выполнением большинства задач в Интернете. JavaScript — неотъемлемая часть современного Интернета.
Однако для того, чтобы собраться вместе, людям нужно перестать демонизировать и отвергать друг друга. Вместо этого нам нужно объединиться, чтобы сделать Интернет лучше. Но прежде чем мы сможем это сделать, нам нужно начать с общего понимания природы JavaScript. Лагерь прогрессивных улучшений должен признать, что весь JavaScript не является злом или даже плохим — JavaScript может быть силой добра, и у него действительно солидная поддержка. Сторонники JavaScript должны признать, что, несмотря на его повсеместное распространение и почти всеобщую поддержку, мы никогда не можем быть абсолютно уверены в том, что наши программы на JavaScript будут работать.
Я полностью верю, что мы можем залечить этот разрыв, но, вероятно, это займет некоторое время. Я полностью намерен внести свой вклад, и я надеюсь, что вы сделаете то же самое.
- Полное раскрытие: мы оба работаем в Microsoft, но в разных командах. ↩
- Стоит отметить, что одна компания, NursingJobs, действительно сделала это. ↩
Эта запись изначально появилась в моем блоге.
