За несколько часов до торгового шоу JavaOne в мае 2006 в конференц-зале Adobe Systems собрались представители 29 компаний, пытающиеся определить будущее Ajax вообще, и их группы, известной как OpenAjax, в частности.

Группой были приняты несколько договорённостей, наиболее видимым для окружающих было решение назвать себя Open Ajax Alliance. Ещё они решили не заниматься формализацией стандартов и не создавать хостинговую организацию для ПО с открыты кодом, такую как Eclipse Foundation, а оставить всю организацию неформальной. Группа договорилась встречаться приблизительно раз в неделю посредством телеконференций.

Open Ajax Alliance фокусирует своё внимание на трёх областях: снижение риска захвата технологии AJAX путём повышения способности ко взаимодействию; слежение за соответствием решений AJAX открытым стандартам и использованием в них свободно распространяющихся технологий; и сохранение открытости Web-пространства.

Первая задача группы - наладка и поддержание способности ко взаимодействию между инструментами Ajax.

OpenAjax Alliance включает в себя 31 производителя технологий: IBM, Adobe, Eclipse Foundation, Google, Laszlo Systems, Oracle, Red Hat и Zend.



Несложно понять, что произошло дальше: в каждой новой версии Netscape и Internet Explorer стали появляться новые замечательные возможности, несовместимые с браузером-конкурентом. Делалось это для того, чтоб заставить Web-дизайнеров включать в свои страницы эти замечательные новые технологии, доступные только в одном из браузеров, поддерживающем соответствующий язык. Похож на эту ситуацию происходящий в то же время конфликт между Java и J++. Схватка между JavaScript и JScript ведётся за прибыли Netscape и Microsoft, а страдают в ней все остальные. Фактически, компании выкидывают деньги на то, чтоб создать несовместимый код.

Формальные попытки стандартизации начались в 1996 году, когда Netscape предоставил стандарты JavaScript на одобрение ECMA International; стандарты были приняты в июне 1997-го. Сейчас актуален стандарт (ECMAScript Edition 3, 1999) ECMA-262, соответствующий ISO/IEC 16262.

Однако на этом война не закончилась. Хотя JavaScript и JScript и совместимы с ECMAScript, между ними всё равно есть существенные различия, и у каждого из них есть свои надстройки. Их хозяева добиваются того, чтобы Web-разработчики сообщали пользователям, что данная страница отображается только в данном браузере, или хотя бы указывали, что данная страница "лучше" отображается в данном браузере.

Некоторые разработчики стали писать страницы, не обращая внимания на то, где и как они отображаются, иные же озаботились совместимостью. Реализовали они это, проверяя версию, указанную в отправляемой пользовательским браузером строке. К сожалению, многие разработчики для определения версий Netscape стали ориентироваться на ссылку на "Mozilla/X.0" в строке. Для тех, кто не использовал, многие опции были урезаны или отключены; из-за этого страницы во всех прочих браузерах страницы грузились неправильно, если грузились вообще. В результате Internet Explorer в отправляемой серверу строке начал указывать, что он на самом деле - Mozilla!
 

Прочие участники

В эту и без того запутанную ситуацию вмешались разработчики новых браузеров, таких как Opera, iCab, и Konqueror, заинтересованные в загрузке всех возможных страниц. Поскольку многие страницы в первую очередь смотрят на отправляемую серверу строку, начинающуюся с "Mozilla", то многие производители последовали примеру Internet Explorer. Многие современные браузеры отправляют серверу вводящие его в заблуждение строки, и даже позволяют пользователю выбрать, каким браузером им назваться. Виноват во всём этом рынок; новый браузер способен загрузить миллионы страниц, но только если он укажет правильную информацию в строке. Многие же сайты пытаются выявлять и блокировать определённые браузеры, для которых их отображение проблематично.

Хотя стандарты ECMAScript в первую очередь предназначены для браузеров, не только в браузерах они используются, и не только их версии важны. Некоторые версии Macromedia Flash используют ActionScript. Adobe Photoshop использует JavaScript. Отдельно стоит Konfabulator, использующий JavaScript и работающий под Windows и Mac OS X, который позволяет создавать всякие приспособления вроде графиков курсов акций и небольших видеоигр.

Результаты конфликта стандартов

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

Эти скрипты - результат не только конфликта стандартов; и без этого страницам необходимо было бы определять, на какую версию стандарти рассчитан браузер. Всё равно ранние версии были крайне несовместимы и в этом плане, очень часто никак было нельзя узнать, какая версия чего используется. Недостаточно было просто спросить о версии; Netscape и Internet Explorer сообщить о ней по-разному! Разумеется, многие обходные пути появились из-за замешательства разработчиков, а не из-за принципиальной невозможности проверить версию. Например, одна такая программа в сетевом магазине использовала гигантский скрипт дабы определить, используете ли вы Mac или Windows (другие варианты не поддерживались), чтобы отправить вам файл zip или архив StuffIt, при том, что сама загружаемая программа была платформо-зависимой. Весь скрипт получился бесполезным, и мне пришлось убить полчаса на построение статичной страницы, чтобы получить правильный адрес загрузки - после того как скрипт не смог сработать в моём браузере.

Во многих вариантах кода считается, что присутствие определённых расширений определяет браузер. Например, некоторые разработчики ищут (document.layers) и найдя, решают, что имеют дело с Netscape 4, после чего начинают использовать все возможности Netscape, или хотя бы те возможности, которые не используются широко вне данной версии Netscape. Не делайте так! Возникнут проблемы, когда вы столкнётесь с браузером, реализующим одну возможность и не реализующим другую. Используйте стандартные возможности. ( Те, кто работают с Mozilla, предлагают великолепный пример хорошо написанного проверяющего кода, определяющего версию JavaScript; поищите в Ресурсах).

Хотя порождаемый всем вышеуказанным траффик незначителен по сравнению с общим сетевым траффиком, было бы интересно прикинуть, сколько миллиардов раз с целью обмануть наивные скрипты им была отправлена строка "Mozilla". Если бы в JavaScript изначально была простая возможность проверять версии и возможности, и разработчики это бы использовали, то вся эта работа не потребовалась бы.

Прочие вариации

В последние несколько лет произошли существенные изменения - а именно, появились браузеры с существенными, намеренными и хорошо документированными недоработками в реализации JavaScript. Я имею в виду, естественно, блокировку всплывающих окон. Оригинальные стандарты JavaScript позволяли выполнять потенциально назойливые действия. Назойливые - даже слишком мягко сказано, многие скрипты могли делать такое, что более пристало вирусам, а не Web-страницам (например, окна, использующие метод onUnload для открытия новых окон при своём закрытии!)

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

Конфликт накалился ещё сильнее, когда сайты стали искать новые пути для показа сообщений при помощи JavaScript, а производители браузеров продолжили искать пути подавления нежелательных сообщений. На некоторых сайтах их основные возможности были реализованы теми же методами, при помощи которых отображалась и реклама, так чтобы пользователи не могли пользоваться сайтом, не подставившись под поток рекламных объявлений.

Тенденции развития

Всё ещё продолжается стандартизация ECMAScript. Грядущий стандарт JavaScript 2.0 будет тем же языком, что и ECMAScript Edition 4, однако в JavaScript будут некоторые дополнительные возможности. На странице JavaScript 2.0 сказано, что "JavaScript 2.0 будет включать некоторые новые возможности, которые перед стандартизацией необходимо проверить, и получить отзывы."

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

Одним из будущих направлений, вызывающим дискуссию в Ajax, является "Asynchronous JavaScript + XML". Идея в том, чтобы скрипты на странице проделывали некоторую работу, при этом не перезагружая её. Теоретически, если скрипты будут один раз загружать большие куски страниц, а потом просто обновлять и подгружать маленькие кусочки, пропускная способность сайтов сильно увеличится. Это не станет новым стандартом, однако эта способность языков ECMAScript потребует большей стандартизации браузеров и некоторого расширения их возможностей. Чем сложнее скрипт и чем больше от него зависит, тем важнее для разработчиков его стабильность и гибкость. Надеюсь, при будущих изменениях стандартов не будут забыты и нынешние проблемы с безопасностью, пусть при этом и будет потеряна какая-то часть функциональных возможностей.