В недавней теме Луи на форуме, находимся ли мы в реакции на зависимость от сценариев? он прокомментировал:
Я думаю, что в некотором смысле мы испытываем некоторую обратную реакцию зависимости от сценариев, и это, вероятно, хорошо.
TL; DR
- Я согласен. То же самое делают и другие, включая веб-гуру PPK ( проблема с Angular ), Джереми Кейта ( угловой момент ) и Джейка Арчибальда ( прогрессивное улучшение по-прежнему важно ).
- Относительно немногие веб-приложения подходят для сред JavaScript, несмотря на их стремительный рост.
- Прогрессивное улучшение остается лучшим вариантом для решения проблем веб-разработки, таких как широкая поддержка браузеров, поддержка и поддержка вашего приложения на будущее.
Давайте определим термины, которые мы обсуждаем …
Что такое JavaScript-зависимость?
Там был рост использования клиентских платформ. Они предоставляют шаблоны кодирования на стороне сервера, такие как MVC, представления шаблонов, повторно используемые компоненты, проверка формы и многое другое. AngularJS , пожалуй, самый известный и популярный, но это не единственное решение.
В отличие от серверных сред, альтернативы на стороне клиента должны выполняться в современном браузере с поддержкой JavaScript. Без JavaScript они терпят неудачу. TIDAL — типичный случай; если JavaScript недоступен, пользователь видит пустую страницу. Нет контента, нет ошибок и нет формы регистрации.
Хотя для показа сообщения нет небольшого оправдания, есть хорошие варианты использования для JavaScript-зависимых приложений:
- Прототипы
Моделирование сайтов и приложений выполняется быстро, потому что клиентские инфраструктуры предоставляют богатые компоненты и ярлыки. - Клиентские приложения
Если ваше приложение простое и не требует взаимодействия с сервером, кроме начальной загрузки, среда JavaScript может подойти (если вы можете удалить ненужные вещи). - Внутренние корпоративные приложения
Применение JavaScript не является проблемой, если вы знаете свою аудиторию и устройства, которые они используют. Изначально Angular был разработан для корпоративных приложений. - Сложные интерфейсы
Подумайте об экшенах, Google Картах и Документах Разработка альтернатив без JavaScript бесполезна. Google создал базовую HTML-версию Карт, но в действительности это было другое приложение, которое было удалено в 2010 году.
Есть и другие случаи, но большинство общедоступных веб-сайтов и приложений не подпадают под эти категории. Никто не остановит вас, используя клиентскую среду, но когда у вас есть молоток, все выглядит как гвоздь. Процитирую Луи снова:
Похоже, что разработчики используют яркие инструменты только ради этого, а не потому, что они решают актуальную проблему.
Что такое прогрессивное улучшение?
Прогрессивное улучшение (PE) — это не технология, а подход к развитию. Я написал несколько учебных пособий и примеров в 2009 году, но эта концепция обсуждалась с 2003 года.
Вы устанавливаете базовый уровень взаимодействия с пользователем, а затем добавляете расширенные функциональные возможности, когда браузер поддерживает его. Взятие PE в логическую крайность:
- Вы создаете приложение только для HTML, где вся важная обработка выполняется на стороне сервера. Это будет работать в любом браузере; мобильные устройства, Lynx, IE1.0 или все, что вы бросаете на это.
- Вы улучшаете макет с помощью CSS. CSS готов к PE, потому что браузеры игнорируют свойства, которые они не понимают. Вы можете улучшить его, используя такие параметры, как медиа-запросы или правила @supports . Приложение по-прежнему работает везде, но предлагает улучшенные возможности для браузеров с современными возможностями CSS.
- Вы расширяете функциональность с помощью JavaScript. JavaScript является наиболее изменчивым уровнем, поскольку поддержка языка и API варьируется от браузера к браузеру. Предполагая, что он работает, вы тестируете средства перед их использованием. Например, вы можете превратить таблицу данных в симпатичную диаграмму, если поддерживается
canvasSVG
Каждый браузер получает лучшее приложение, которое он может обработать. Вполне возможно, что нет двух браузеров, предлагающих одинаковый опыт. Адаптивный для мобильных устройств дизайн и менее часто используемые офлайн- примеры являются примерами методов прогрессивного улучшения.
Давайте рассмотрим критику PE.
МИФ: никто не отключает JavaScript
Мало кто знает, что такое JavaScript. Немногие браузеры позволяют (легко) отключать JavaScript.
Это абсолютно верно.
Затем критики PE делают вывод:
те, у кого нет JavaScript, получают то, что заслуживают
Опасно полагать, что JavaScript будет доступен всем, везде, каждый раз, когда того требует ваше приложение. У всех есть JavaScript, верно? иллюстрирует суть.
Прогрессивное улучшение не предназначено для тех, кто отключает JavaScript. Речь идет об улучшении опыта, когда доступны определенные функции JavaScript. Приложение может предложить ужасный интерфейс, когда JavaScript отключен, но пользователь все еще что-то получает.
МИФ: никто не использует старые браузеры
Что мы подразумеваем под «старым» ? Для большинства разработчиков это любой браузер, выпущенный более двенадцати месяцев назад. Не каждый может использовать новейшие и лучшие приложения:
- крупные организации и правительственные ведомства
- люди с ограниченными возможностями
- люди в развивающихся странах
- менее богатые слои общества
- любой с iPhone 5.0 или Android 4.0 и ниже.
Эти сектора могут быть не важны для вас. Но они никогда не будут важны?
Прогрессивное улучшение не делает никаких предположений о вашей аудитории. Это не верно для клиентских платформ. Те, кто не может использовать ваше приложение, исчезнут из журналов сервера. Это быстро становится самоисполняющимся пророчеством: «никто не использует наше приложение в старом браузере, поэтому мы можем продолжать работу как есть…»
МИФ: прогрессивное улучшение — это анти-JavaScript
Прогрессивное улучшение охватывает фундаментальные преимущества сети. Можно разработать сайт или приложение, которое работает на любом веб-совместимом устройстве в любой точке мира. Чем лучше это устройство, тем лучше пользовательский опыт.
Клиентские платформы делают JavaScript абсолютной зависимостью. Вы больше не программируете для Интернета. Ваше приложение использует Интернет в качестве механизма доставки для конкретных механизмов выполнения. Браузер — это ваша операционная система, и обновление может сломать ваше приложение.
МИФ: Прогрессивное улучшение делает предположения о пользователях и устройствах
PE — это НЕ делать предположений. Вы ничего не предполагаете — это основная предпосылка техники.
Фреймворки JavaScript заставляют вас думать, что каждый использует мощный браузер на мощном устройстве. Мы сделали эти предположения раньше. Разве это отличается от предположения, что все на широкополосной связи? Или у каждого есть 17 ″ экран шириной не менее 960 пикселей? Или что каждый будет использовать IE6 сейчас и навсегда?
МИФ: прогрессивное улучшение означает поддержку архаичных браузеров
Критики Progressive Enhancement предполагают, что вы потратите все свое время на работу со старыми браузерами. На самом деле все наоборот: вам никогда не нужно иметь дело со старыми браузерами, потому что есть соответствующие запасные варианты.
Поддержка старых браузеров — это преимущество PE, а не цель . Вы можете поддерживать самые низкие браузеры, но вы можете установить любой базовый уровень, который вам нравится .
Например, в настоящее время я работаю над приложением, в котором addEventListener Поэтому IE8 и ниже не смогут показать функциональные улучшения. Я мог бы это исправить, но это не стоит вложений, поскольку это корпоративное приложение без пользователей oldIE. Тем не менее, пользователи IE8 все еще могут использовать систему, и она может быть улучшена в случае необходимости.
МИФ: приложения JavaScript Framework круче
Вы можете создать идентично выглядящее приложение, используя методы PE. Путаница возникает из-за того, что большинство JavaScript-фреймворков предоставляют ряд привлекательных предварительно разработанных виджетов. Те же самые виджеты можно было бы использовать в прогрессивно улучшенном приложении, но без JS они бы отступили к базовым альтернативам HTML.
PE также позволяет использовать современные API HTML, CSS и JavaScript, которые еще не появились ни в одном браузере. Рассмотрим Fetch API — современную замену XMLHttpRequest. Он имеет минимальную поддержку, но я мог бы использовать его без проблем, потому что я могу либо откатиться на XMLHttpRequest, либо на запросы к серверу.
Фреймворки JavaScript прочно застряли в настоящем, а не в будущем.
МИФ: прогрессивное улучшение сдерживает сеть
Или, более конкретно, клиентские структуры находятся на переднем крае и продвигают сеть вперед.
Извините, но это иллюзия. AngularJS-подобные фреймворки реализуют волшебные функции, но, копаясь под поверхностью, вы все еще используете HTML, CSS, JavaScript и DOM-манипуляции. В лучшем случае это абстракция. В худшем случае это отвлечение.
Ваш клиентский фреймворк хорош только для браузеров, для которых он был разработан. AngularJS 2.0 — это полное переписывание, потому что такие функции, как Object.observe() и веб-компоненты, не были широко доступны, когда был выпущен AngularJS 1.x. Фреймворк заставляет вас использовать старые технологии, но скрывает реализацию от вас.
PE позволяет использовать любой современный API, не ломая ваше приложение. Удачи в обновлении от Angular 1…
МИФ: Фреймворки JavaScript делают разработку проще
Это отчасти верно, но только когда вы начинаете создавать приложение. У вас есть доступ к ряду элементов управления, которые сокращают начальное время разработки. Но тогда вы застряли в рамках этой структуры, и это может привести к проблемам позже.
Предположим, ваше приложение работает некоторое время, и клиент требует поддержки BrowserX . Он используется крупным клиентом и не особенно стар; браузер Blackberry, iPhone 4, Android 3.3 и т. д. Вероятно, они ожидают разработки в течение нескольких дней, но это может быть невозможно, если ваш JavaScript-фреймворк несовместим.
Вопрос может никогда не возникнуть для приложения, разработанного с использованием методов PE; возможно, вы уже поддерживаете этот браузер. Дальнейшие улучшения могут быть добавлены без серьезного переписывания.
МИФ: прогрессивное улучшение — в два раза больше
Это любимая цитата критиков. Единственные люди, которые говорят, что PE — это слишком много усилий, — это те, кто никогда не пробовал или как-то потерпел неудачу в попытке.
PE займет только вдвое больше времени, если вы не учли это с самого начала. Попытка встроить PE в существующее приложение обречено — это особенно верно для того, что зависит от JavaScript.
Давайте рассмотрим простой пример, такой как постраничный список результатов поискового запроса. Первая загрузка страницы возвращает весь HTML. Это быстро, и JavaScript ничего не может сделать. За кулисами мы используем запрос к базе данных и помещаем результаты в шаблон HTML. Вы можете быстро адаптировать тот же сервис для возврата результатов в виде данных JSON или HTML результатов без заголовка и нижнего колонтитула. Когда пользователь нажимает «страница 2», отображается вторая страница результатов:
- С помощью JavaScript мы можем перехватить щелчок и использовать методы Ajax для извлечения этой страницы результатов. Данные HTML могут быть вставлены в страницу с помощью
innerHTMLВ качестве альтернативы, мы могли бы использовать страницу 1 в качестве шаблона для возвращаемых данных JSON. - Если JavaScript, XMLHttpRequest или Fetch недоступны — или вызов Ajax не выполняется — мы можем запросить вторую полную страницу HTML.
Это немного больше работы, но это, конечно, не вдвое больше усилий. У нас есть кросс-браузерное отказоустойчивое решение.
МИФ: прогрессивное улучшение не имеет смысла — сайты развиваются или умирают
Логика этого аргумента заключается в том, что веб-сайты в конечном итоге устаревают. Следовательно, вы можете использовать платформу, которая нацелена на конкретные технологии в определенный момент времени.
Хотел бы я. Если ваш код хорош, он будет использоваться гораздо дольше, чем вы ожидали. Плохой код живет дольше, потому что никто не хочет его трогать.
Но опять же, используйте Progressive Enhancement, и вы не будете делать никаких предположений, кроме того, что веб-сайт будет продолжать работать как система на основе клиента / сервера HTML. Для того чтобы ваше приложение перестало работать, веб-сайт должен кардинально измениться — он больше не будет веб-сайтом!
МИФ: Прогрессивное улучшение — старая техника, рекомендуемая старыми таймерами
Распространение клиентских JavaScript-фреймворков ставит вас в меньшинство вместе с остальными «старыми таймерами».
Да спасибо!
Обратная реакция JavaScript вызвана людьми, которые разрабатывали для сети в течение значительного периода. Неужели мы все луддиты не можем идти в ногу со временем? Может быть. Или, может быть, это потому, что мы узнали что-то из наших многочисленных исторических ошибок?
Фреймворки JavaScript поднимают знакомые проблемы:
- Некоторые смешивают HTML и функциональность, как мы привыкли делать с обработчиками
onclick
<form ng-submit="doSomething()"> - Они ориентированы на конкретные браузеры. Возникли сообщения «лучше всего просматривать в…» и теги
<noscript> - Они делают предположения о сегодняшней сети — например, JavaScript работает везде и 2 МБ на страницу вполне разумно.
- Они не планируют на будущее.
Фреймворки JavaScript в основном приносят пользу разработчику, а не пользователям . Они могут предложить кратковременную выгоду, но стоимость посетителей меньше и болезненное долгосрочное обслуживание.
И давайте не будем забывать SEO. Google индексирует страницы JavaScript, но следовать каждой ветке логики не обязательно будет возможно. Также может быть сложно сослаться на конкретный URL, если вы не написали код тщательно.
Прогрессивное улучшение дополняет сильные стороны Интернета:
- он разделяет контент, макет и функциональность для удобства обслуживания
- вы пишете защитный, отказоустойчивый, независимый от устройства код для Интернета, а не браузеры
- Вы можете поддерживать широкий спектр устройств
- ваша нагрузка на тестирование снижается, потому что ваше приложение остается работоспособным при сбое
- SEO и доступность запечены (или требуют меньше усилий)
- сайты и приложения будут работать в браузерах, выпущенных сегодня, вчера и завтра
- никто не опроверг преимущества Progressive Enhancement или не предложил лучшую технику.
Есть только один недостаток: очевидно, что многие разработчики до сих пор не доверяют или не понимают Progressive Enhancement.
Да здравствует отрицательная реакция JavaScript-зависимости!