• Джон Постел был одним из инженеров, работавших на ARPANET, предшественнике Интернета. Он хотел быть уверенным, что пакеты, или «датаграммы», курсирующие по сети, передаются наиболее эффективным образом. Он осознал, что либеральное отношение к ошибкам было ключом для эффективной коммутации пакетов.



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

Будьте консервативны в том, что вы отправляете; будьте либеральны в том, что принимаете.

• Если это звучит знакомо, то потому, что именно так браузеры поступают с HTML и CSS. Даже если HTML и CSS, содержат ошибки, браузер все равно будет пытаться обработать информацию, игнорируя любые куски, которые он не может разобрать.

Декларация

• HTML и CSS являются примерами декларативных языков. Автор, пишущий на декларативном языке, описывает желаемый результат, не давая пошаговой инструкции обрабатывающему файл компьютеру. С помощью HTML, можно описать суть содержимого страницы — параграфы, заголовки, поля форм и тд. — без необходимости объяснять браузеру, что с ними делать. С помощью CSS, вы можете описать желаемый внешний вид страницы — цвета, размеры и тд. — без необходимости писать программу для применения этих стилей.
• Большинство языков программирования являются императивными, а не декларативными. Perl, Java, C++ — все это примеры императивных языков. Если вы пишете на одном из них, то должны дать компьютеру точные инструкции для интерпретации кода.
• Императивные языки дают вам больше возможностей и четкости, чем декларативные. Но у этого есть своя цена. Как правило, они сложнее в изучении. И к ним сложнее применить Закон Постела. Если вы сделаете хоть одну ошибку — пропустите запятую или точку с запятой — вся программа может полететь. Неправильно написанный HTML-тег или пропущенная фигурная скобка в CSS тоже могут вызвать головную боль, но императивные программы должны быть целиком безупречны, иначе они не смогут выполняться.
• Императивные языки, такие как PHP, Ruby, и Python можно найти на серверах, обслуживающих интернет. Они управляют базами данных, обрабатывают инпуты из веб-форм и обеспечивают работу комплексных алгоритмов. Для написания серверного кода подойдет абсолютно любой язык программирования. В отличие от ситуации неизвестности с браузером пользователя, серверные возможности легко контролировать.
• Если вы хотите писать императивный код, который бы работал в веб-браузере, то есть только один вариант: JavaScript.

Скрипты

• Идея выполнять программу изнутри веб-страницы стара как и сам веб. Вот один из ранних имейлов из форума, посвященного WWW:

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

• Создатель Всемирной паутины Тим Бернерс-Ли ответил так:

Отличный вопрос. Вся проблема в языке программирования. Нужно что-то мощное, но в то же время распространенное. Помните, что главный аспект веба — это универсальность. Не существует универсального интерпретируемого языка программирования.

• Это был 1992 год. Универсальный интерпретируемый язык наконец-таки появится в 1996. Он будет написан программистом компании Netscape Бренданом Эйхом за 10 дней.
• Название языка менялось несколько раз. Сперва его назвали Mocha. Затем он был официально запущен под именем LiveScript. А после того, как подключился отдел маркетинга, его переименовали в JavaScript, в надежде урвать волну славы появившегося в тот момент Java. На деле эти языки имеют мало общего — как «кот» и «котелок».

Паттерны прогресса

• JavaScript дал дизайнерам возможность вносить изменения в страницы даже после их загрузки. Вскоре появились два главных способа применения: интерактивные кнопки и валидация форм.
• Замена одного изображения кнопки на другое при наведении курсора может показаться не самым разумным применением нового языка, но в 90-е не было другого способа делать ховер-эффекты.
• До прихода JavaScript форму нужно было отправлять на сервер перед тем, как убедиться, что все обязательные поля заполнены или, что введенная информация соответствует ожидаемому формату.
• Оба юзкейса все еще существуют, но сейчас нет необходимости в JavaScript. Ховер-эффект можно создать, используя псевдо-класс :hover в CSS. А подтверждать данные формы можно с помощью атрибутов REQUIRED и TYPE в HTML.
• Этот паттерн повторяется снова и снова: решение создается с помощью императивного языка и, если оно пользуется спросом, со временем мигрирует в декларативный. С этого момента вариант решения, написанный с помощью декларативного языка, становится не только более простым, но и более надежным.
• Либеральное отношение к ошибкам в HTML и CSS подразумевает, что оплошности разработки и ограничения поддержки браузера будут изящно обходиться — браузер проигнорирует все непонятное без сбоев. Как правило, этого бывает достаточно. В то же время, если предоставить браузеру содержащий ошибки JavaScript или попытаться использовать неподдерживаемый синтаксис, программа не только выдаст ошибку, но и перестанет считывать скрипт с этого момента, отказываясь двигаться дальше.

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

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

Это я написал код для рекламы в новом окне. Каюсь

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

2.0

• В 2005 году взлет JavaScript спровоцировала статья Джеймса Гэрретта Ajax: новый подход к веб-приложениям Статья дала имя набиравшей популярность технологии. С помощью определенных ухищрений JavaScript позволял избежать перезагрузки всей страницы при отправке и получении браузером данных от сервера. Сайты, использующие такой прием, подняли планку пользовательского опыта на новую высоту.
• Термин Ajax был введен в то же самое время, когда набирал популярность еще один неологизм. Тим О’Райли использовал выражение «Веб 2.0» для описания волны новых веб-продуктов и веб-сервисов. В отличие от Ajax, «Веб 2.0» не поддавался точному определению. Для бизнеса «Веб 2.0» означал новые бизнес-модели. Для дизайнеров — закругленные углы и градиенты. Для разработчиков — JavaScript и Ajax.
• Что бы это ни значило на самом деле, термин «Веб 2.0» запечатлел настроение и ощущение момента. «Теперь все будет иначе» говорил он. Прежние подходы к веб-строительству отправлялись в отставку. Веб больше не воспринимался как бесконечная подшивка перелинкованных документов. Наступала эпоха веб-приложений.

Эйфория

• В судебном деле «Джейкобеллис против Огайо» 1964 года судья Поттер Стюарт дал следующее определение непристойности:

Я это понимаю, когда я это вижу.

• То же самое можно сказать про «Веб 2.0» или про термин «веб-приложение». Мы все можем привести примеры веб-приложений, но дать определение гораздо сложнее. Они позволяют создавать, редактировать и удалять контент. Но подобные задачи были распространены задолго до веб-приложений. Люди могли заполнять формы и отправлять их для обработки веб-сервером. Ajax позволил обойтись без ненужного челночного бега до сервера.
• Возможно определение веб-приложения требует такой круговой аргументации:
• JavaScript необходим для веб-приложения
• а веб-приложение является веб-сайтом, которому для работы необходим JavaScript.
• Получается, создание веб-приложений зиждется на фундаментальном допущении: JavaScript должен быть доступен и должен быть надежен. Но ввиду своей императивной природы, он более капризен, чем HTML. и другие декларативные языки. Полностью полагаться на JavaScript довольно рискованно.

Непрощенные

• Снисходительное отношение к ошибкам позволило HTML со временем стать еще мощнее. Это же обстоятельство делало HTML простым в освоении. Даже если вы допускали ошибку, браузер, согласно Закону Постела, все равно гарантировал вам результат. Как ни странно, была и попытка лишить HTML его суперспособности.
• После стандартизации четвертой версии HTML в 1999 году Консорциум Всемирной паутины W3C выпустил XHTML 1.0. Это был HTML, переформулированный в соответствии с требованиями формата данных XML. В то время как HTML позволяет писать теги и атрибуты заглавными и строчными символами, XTML требует использовать только строчные. Были и другие различия: все атрибуты должны быть в кавычках, а все самостоятельные элементы типа IMG или BR должны иметь закрывающий слеш.
• XHTML 1.0 не добавил языку новых возможностей. Это был просто более строгий способ написания разметки. XHTML 2.0 же предлагал совершенно иное. Он не только исключал устоявшиеся элементы типа IMG, но и внедрял драконовскую модель обработки ошибок XML. Если в XML-документе присутствует ошибка — атрибут не заключен в кавычки или пропущен закрывающий слеш — парсер немедленно прекращает работу и отказывается отображать что-либо.
• XHTML 2.0 погиб на корню. Его теоретическая чистота была всецело отвергнута людьми, зарабатывавшими созданием веб-сайтов. Дизайнеры вполне обоснованно отказывались публиковаться в формате, который полностью выйдет из строя, вместо того, чтобы попытаться обойти ошибку.
• Странно, что годами позже, веб-дизайнеры начали запросто создавать целые сайты с помощью JavaScript, языка, разделявшего не прощающую ошибок модель XML. Они даже не называли их веб-сайтами. Они называли их веб-приложениями. Это разграничение было слабым утешением для тех, кто не смог воспользоваться сайтом из-за того, что он был полностью завязан на JavaScript.
• Несмотря на хрупкую модель обработки ошибок в JavaScript, веб-дизайнеры со временем стали доверять ему все больше. В 2015 году NASA перезапустили свой веб-сайт в формате веб-приложения. Если вы хотели ознакомиться с последними достижениями агентства в области освоения космоса, сначала вам приходилось смотреть на черную страницу в ожидании, пока загрузятся и выполнятся 3 мегабайта JavaScript-кода. Этот контент — изображения и текст — мог быть представлен и с помощью HTML, но разработчики решили использовать Ajax для запроса данных. Возможно это было сделано специально для демонстрации бескрайней пустоты и одиночества космоса.



• Это подчеркивает еще одно различие между HTML и JavaScript. Если HTML может начать отображаться по мере подгрузки, то JavaScript должен быть загружен полностью, перед тем как быть выполненным. Может показаться, что лишь у малой доли посетителей сайта отключен JavaScript, но по факту он «отключен» у всех, пока не загрузится …если загрузится вообще. Нестабильность соединений, вмешательства провайдеров и непредсказуемость программ-блокировщиков только повышают вероятность недоступности JavaScript.
• Проблема не в том, что пользователи умышленно блокируют JavaScript у себя в браузере. Хотя данный юзкейс и не стоит списывать со счетов, это не самая распространенная причина сбоев JavaScript. Стюарт Лэнгридж собрал в один список все возможные причины под заголовком «У всех есть JavaScript, так ведь?»

Пользователь запрашивает ваше веб-приложение. Страница уже загрузилась? HTTP-запрос для JavaScript отправлен? HTTP-запрос для JavaScript завершен? Их корпоративный файрвол не блокирует JavaScript? Их провайдер или мобильный оператор не мешают загрузке JavaScript? Они не отключили JavaScript? У них нет установленных расширений и плагинов, внедряющих свои скрипты или изменяющих DOM непредвиденным для вас образом? Не упала ли сеть доставки контента (CDN)? Поддерживает ли их браузер написанный вами JavaScript?

• Такие же проблемы могут возникнуть с файлами HTML и CSS. Но благодаря Закону Постела они с легкостью обходятся.
• Это не значит, что веб-дизайнеры не должны использовать JavaScript. Но это значит, что они не должны полагаться на него, когда есть более простые решения.

Платформа

• Дизайнеры, проигнорировавшие месседж Джона Элсоппа в «Дао веб-дизайна», допустили ошибку, отнесясь к вебу как к печати. История печати предлагает богатое наследие — иерархия, типографика, теория цвета — но веб принципиально иное медиа. История развития программного обеспечения также скопила ценный багаж — архитектура, тестирование, процессы — но опять же, веб остается отдельной стихией.
• Велик соблазн применить знания и наработки из других сфер к вебу. Но с точки зрения структуры, более честно будет раскрыть его собственные сильные и слабые стороны.
• Используемый нами язык может подспудно влиять на наш образ мыслей. В своей книге «Метафоры, по которым мы живем» Джордж Лакофф обращает внимание на угрозу политического языка. Одни из очевидных примеров — это «дружественный огонь» и «побочный ущерб», но, пожалуй, самым коварным стало «налоговое послабление» — еще до того, как начались дебаты, налогооблажение было обозначено как что-то, чему нужно послабление.
• На первый взгляд понятие «веб-платформа» вполне безобидно. Описание веба как платформы приравнивает его к любой другой программной среде. Flash был платформой. Android — это платформа. iOS — тоже платформа. Но веб — не платформа. Вся суть веба в кросс-платформенности.
• Платформа предоставляет контролируемую рабочую среду для программного обеспечения. Пока у пользователя есть эта рабочая среда, вы можете быть уверены, что он увидит именно то, что вы создали. Если вы разработали приложение для iOS и кто-то использует iOS-устройство, будьте уверены, что он получит 100% вашего продукта. Но если вы разработали приложение для iOS, а кто-то использует устройство с Android, он получит 0%. Вы не можете установить iOS на Android-устройство. Тут уж либо все, либо ничего.
• В этом отношении веб не такой бинарный. Если вы создали что-то, используя определенные веб-технологии, вы не можете знать, какая часть этих технологий будет поддерживаться тем браузером, на котором откроют ваш сайт. Скорее всего, это не будет 100%. Но точно и не 0%. Кто-то зайдет с iOS. Кто-то с Android. Кто-то увидит 80% или 90% от задуманного вами. Другие лишь 20%, 30%, или 50%. Веб — не платформа. Это континуум.
• Считать веб платформой — ошибка категоризации. Такие платформы как Flash, iOS и Android обеспечивают надежность и уверенность, но в рамках четко определенных условий — ваша программа должна запускаться на совместимом с платформой устройстве. Веб не дает никаких гарантий, но вместе с тем и не ограничивает круг потенциальных устройств.
• Платформы поддаются контролю и предсказуемы. Всемирная паутина хаотична и непредсказуема.
• Веб — настоящий бедлам.

Ссылки:

• RFC 761:Transmission Control Protocol

  Джон Постел

• «Программные ссылки в WWW»

  Тим Бернерс-Ли

• «Первородный грех Интернета»

  Итан Цукерман

• «Ajax: новый подход к веб-приложениям»

  Джесси Джеймс Гарретт

• «У всех есть JavaScript, так ведь?»

  Стюарт Лэнгридж