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

Одно из первых злоупотреблений JavaScript произошло (что неудивительно) в рекламной индустрии – бизнесе, смысл существования которого часто противоречит целям людей, пытающихся решить задачу как можно быстрее. JavaScript позволяет создавать новые окна браузера, что раньше мог делать только пользователь. Молодой разработчик по имени Итан Цукерман понял, что он может создавать новое окно с рекламой в нем. Это позволило рекламодателям разместить свое сообщение перед посетителями сайта. Мало того, JavaScript можно было использовать для создания нескольких окон, некоторые из которых были видимыми, а некоторые – скрытыми за текущим окном. Это было чудовищное решение.

Двадцать лет спустя Цукерман написал:

«Я написал код для запуска окна и запуска рекламы в нем. Мне очень жаль.»

Всплывающие (и не всплывающие) окна стали настолько невыносимыми, что браузеры должны были предоставить людям возможность блокировать их.

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

Веб-дизайнерам стоит помнить то, что рекламная индустрия предпочитает игнорировать: в Интернете последнее слово остается за пользователем.

Приложение

В деле "Якобеллис против Огайо", рассмотренном Верховным судом в 1964 году, судья Поттер Стюарт дал такое определение непристойности:

«Я знаю это, когда вижу.»

То же самое можно сказать о Веб 2.0 или о термине "веб-приложение". Мы все можем привести примеры веб-приложений, но дать определение этому термину гораздо сложнее. Веб-приложения позволяют людям создавать, редактировать и удалять контент. Но эти задачи были распространены задолго до появления веб-приложений. Люди могли заполнять формы и отправлять их на веб-сервер для обработки. Ajax устранил необходимость в таком путешествии на сервер.

Возможно, определение веб-приложения требует некоторых круговых рассуждений:

JavaScript – это требование для веб-приложения, а

веб-приложение – это веб-сайт, для работы которого требуется JavaScript.

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

2.0

Рост JavaScript ускорился в 2005 году, когда Джесси Джеймс Гарретт опубликовал статью под названием Ajax: Новый подход к веб-приложениям. Статья дала название технике, которая набирала популярность. Используя определенный набор JavaScript, веб-браузер мог отправлять и получать данные с веб-сервера без обновления всей страницы. В результате пользователи получили более широкий доступ к информации.

Термин Ajax был придуман в то же время, когда на подъеме находился другой неологизм. Тим О'Рейли использовал фразу Web 2.0 для описания новой волны веб-продуктов и услуг. В отличие от Ajax, было трудно дать определение Web 2.0. Для бизнесменов это означало новые бизнес-модели. Для графических дизайнеров он означал закругленные углы и градиенты. Для разработчиков это означало JavaScript и Ajax.

Каким бы ни было его точное значение, термин Web 2.0 отражает настроение и чувство. Теперь все должно было стать по-другому. Старые способы мышления о создании веб-сайтов можно было отбросить. Рассматривать веб как безграничную коллекцию документов с гиперссылками было устаревшим. Наступила эра веб-приложений.

Не прощать

Свободная обработка ошибок в HTML позволила ему со временем набрать силу. Это также обеспечило простоту изучения языка. Даже если вы допустили ошибку, реализация браузером закона Постеля гарантировала, что вы все равно получите результат. Удивительно, но была попытка удалить эту суперспособность из HTML.

После стандартизации HTML версии 4 в 1999 году Консорциум Всемирной паутины опубликовал XHTML 1.0. В нем HTML был переформулирован в соответствии с правилами формата данных XML. В то время как в HTML имена тегов и атрибутов могут быть прописными или строчными, XML требует, чтобы они были полностью строчными. Были и другие различия: все атрибуты должны быть заключены в кавычки, а отдельные элементы, такие как IMG или BR, требуют закрывающей косой черты.

XHTML 1.0 не добавил в язык никаких новых возможностей. Это был просто более строгий способ написания разметки. XHTML 2.0 был совсем другим предложением. Он не только удалял такие устоявшиеся элементы, как IMG, но и внедрял драконовскую модель обработки ошибок XML. Если в XML-документе есть хоть одна ошибка – один атрибут без кавычек или пропущенная закрывающая косая черта – то синтаксический анализатор должен немедленно остановиться и отказаться что-либо отображать.

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

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

Несмотря на хрупкую модель обработки ошибок JavaScript, веб-дизайнеры со временем все больше полагались на JavaScript. В 2015 году NASA перезапустило свой веб-сайт как веб-приложение. Если вы хотели прочитать последние новости о работе агентства по освоению космоса, вам сначала нужно было загрузить и выполнить три мегабайта JavaScript. Это содержимое – текст и изображения – могло быть передано в HTML, но разработчики решили использовать Ajax для получения этих данных. Пока весь этот JavaScript не был загружен, разобран и выполнен, посетители сайта смотрели на черный фон. Возможно, это было задумано как демонстрация огромной одинокой пустоты космоса.

Версия сайта nasa.gov 2015 года с неполным JavaScript.

Это подчеркивает еще одно различие между HTML и JavaScript. В то время как HTML можно просматривать по частям по мере загрузки, файл JavaScript должен быть загружен полностью, прежде чем его содержимое будет разобрано. Хотя очень заманчиво думать, что лишь небольшое меньшинство посетителей сайта пропустит JavaScript, правда заключается в том, что все являются пользователями без JavaScript до тех пор, пока JavaScript не закончит загрузку… если JavaScript закончит загрузку. Нестабильные соединения, вмешательство операторов сети и непредсказуемое программное обеспечение, блокирующее рекламу, могут разрушить предположение о том, что JavaScript всегда будет доступен.

Проблема не в том, что люди намеренно отключают JavaScript в своих браузерах. Хотя такой вариант использования стоит рассмотреть, это не самая распространенная причина ошибок JavaScript. Стюарт Лэнгридж составил список всех потенциальных точек отказа под заголовком "У всех есть JavaScript, верно?

«Пользователь запрашивает ваше веб-приложение. Загрузилась ли страница? Успешен ли HTTP-запрос для JavaScript? Завершился ли HTTP-запрос для JavaScript? Блокирует ли корпоративный брандмауэр JavaScript? Не препятствует ли провайдер или оператор мобильной связи загрузке JavaScript? Отключили ли они JavaScript? Установлены ли у них дополнения или плагины, которые внедряют сценарий или изменяют DOM таким образом, как вы не ожидали? Работает ли сеть доставки контента? Поддерживает ли их браузер написанный вами JavaScript?»

Многие из этих проблем также могут повлиять на файлы HTML и CSS, но благодаря закону Постеля они могут изящно восстановиться.

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

Платформа

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

Заманчиво применить знания и уроки, полученные в другой среде, к вебу. Но структурно честнее раскрыть уникальные сильные и слабые стороны Интернета.

Язык, который мы используем, может тонко влиять на наше мышление. В своей книге "Метафоры, которыми мы живем" Джордж Лакофф подчеркивает опасность политического языка. Очевидными примерами являются "дружественный огонь" и "сопутствующий ущерб", но более коварным примером является "облегчение налогового бремени" – еще до начала дебатов налогообложение было представлено как нечто, требующее облегчения.

На первый взгляд, термин "веб-платформа" кажется безобидным. Описание веба как платформы ставит его в один ряд с другими программными средами. Flash был платформой. Android – это платформа. iOS – это платформа. Но веб – это не платформа. Вся идея веба в том, что он кроссплатформенный.

Платформа обеспечивает контролируемую среду выполнения для программного обеспечения. Пока у пользователя есть эта среда выполнения, вы можете быть уверены, что он получит именно то, что вы задумали. Если вы создаете приложение для iOS и у кого-то есть устройство iOS, вы знаете, что он получит 100% вашего программного обеспечения. Но если вы создадите приложение для iOS, а у кого-то будет устройство Android, он получит 0% вашего программного обеспечения. Вы не можете установить приложение iOS на устройство Android. Все или ничего.

Веб не так бинарен. Если вы создаете что-то с использованием веб-технологий, а кто-то заходит на сайт с помощью веб-браузера, вы не можете быть уверены, сколько веб-технологий будет поддерживаться. Скорее всего, это будет не 100%. Но также маловероятно, что это будет 0%. Некоторые люди будут посещать сайт с устройств iOS. Другие будут посещать сайт с устройств Android. Некоторые люди получат 80% или 90% того, что вы разработали. Другие получат только 20%, 30% или 50%. Интернет – это не платформа. Это континуум.

Думать о вебе как о платформе – это ошибка. Такие платформы, как Flash, iOS или Android, обеспечивают стабильность и определенность, но только при очень специфическом наборе обстоятельств – доступ к вашему программному обеспечению должен осуществляться с помощью соответствующей среды выполнения, специфичной для данной платформы. Интернет не дает такой уверенности, но он также не ограничивает возможные среды выполнения.

Платформы контролируемы и предсказуемы. Всемирная паутина хаотична и непредсказуема. В Интернете царит полный беспорядок.

Глава 5: Слои

В своей классической книге

"Как здания учатся" Стюарт Брэнд освещает идею британского архитектора Фрэнка Даффи:

«Правильно задуманное здание имеет несколько слоев долговечности.»

Даффи называл эти срезающие слои. Каждый из них движется в разных временных масштабах. Бренд развил идею, предложив шесть аллитеративных слоев:

Место – физическое расположение здания меняется только в геологическом масштабе.

Структура – само здание может стоять веками.

Внешняя отделка – внешняя поверхность здания обновляется каждые несколько десятилетий.

Обслуживание – водопровод и электропроводка нуждаются в обновлении каждые десять лет или около того.

План помещения – расположение стен и дверей может периодически меняться.

Вещи – расположение мебели в комнате может меняться ежедневно.

Разделение слоев.

Идею срезания слоев можно применить и к нашим творениям в Интернете. Наши доменные имена – это геологические объекты, на которых мы строим. На другом конце временной шкалы контент в Интернете – "материал" – может добавляться и обновляться ежечасно, ежеминутно или даже посекундно. Между ними находятся слои структуры, представления и поведения: HTML, CSS и JavaScript.

Эти слои могут быть слабо связаны друг с другом, но они не являются полностью независимыми. Как в здании не может быть мебели без комнат и стен, так и таблица стилей нуждается в разметке, чтобы действовать на ее основе. Связь между структурой и представлением осуществляется с помощью селекторов в CSS: селекторов элементов, селекторов классов и т. д. В JavaScript связь осуществляется через словарь объектной модели документа, или DOM (Document Object Model).

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

Аналогичным образом, выразительность CSS и JavaScript возможна только на основе HTML, который сам по себе требует URL для доступа, который, в свою очередь, зависит от протокола передачи гипертекста, лежащего на фундаменте TCP/IP.

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

Пред.1 ...3 456 7 8 След.

Устойчивый веб-дизайн

Ответственность

Приложение

2.0

Не прощать

Платформа

Рекомендации

Глава 5: Слои

С этой книгой читают