Содержание


Знакомимся с ECMAscript

Поиск стабильности в войне за совместимость языков

Comments

У ECMAscript (известного в народе как JavaScript) довольно интересная история, ведь появился он как отступление от стандартов. Кроме того, ECMAScript - это тот же язык, что и JavaScript и Jscript, которые, соревнуясь, используют соответственно Netscape и Microsoft.

Поначалу эта технология называлась Mocha, потом была переименована в LiveScript, и уже в 1996 году была официально представлена как JavaScript. Однако он не имеет никакого отношения к языку Java™; похожесть названий здесь просто маркетинговый ход. Само собой, в пресс-релизах упоминается о некоей связи между серверным Java и клиентским JavaScript (смотрите Ресурсы); фактически же никакой связи там нет.

Из-за доминирования Netscape на рынке в Internet Explorer пришлось включить поддержку совместимого языка, точнее, по большей части совместимого. В Internet Explorer был включён JScript, почти совместимый с JavaScript.

Войны стандартов

Несложно понять, что произошло дальше: в каждой новой версии 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 потребует большей стандартизации браузеров и некоторого расширения их возможностей. Чем сложнее скрипт и чем больше от него зависит, тем важнее для разработчиков его стабильность и гибкость. Надеюсь, при будущих изменениях стандартов не будут забыты и нынешние проблемы с безопасностью, пусть при этом и будет потеряна какая-то часть функциональных возможностей.

Эффективное и безопасное использование скриптов

Что же это значит для вас как разработчика? Во-первых, необходимо минимизировать бессмысленную зависимость от технологий. На многих страницах для открытия новых окон используется скрипт onclick, меняющий все URL на странице на "#". Это раздражает. Не делайте так.

Разрабатывая скрипт, учитывайте что произойдёт, если ему не дадут сработать. Web-страница одного из крупнейших производителей ПО на протяжении нескольких лет при отключённых скриптах не открывалась вообще - хотя скрипты нужны были исключительно для того, чтоб определить, поддерживает ли ваш браузер Flash-анимацию. (Обновлённая версия демонстрирует сообщение, что для функционирования сайта, в частности для навигации, вам необходим JavaScript. Это ненамного лучше.) Если скрипты вам необходимы, то держите их под контролем; кроме всего прочего, во многих браузерах для людей с инвалидностью функциональность скриптов ограничена.

Создавая скрипт думайте о том, на каких браузерах ему придётся работать. Исключив старые браузеры (или дав им возможность работать без скриптов), вы невероятно упростите свой код. Простейшие скрипты могут быть портабельными; остальные придётся делать по-разному, с отдельными реализациями для каждой версии стандартов. Определить основные версии JavaScript вы можете довольно простым и универсальным путём (смотрите в Ресурсах). Старайтесь изолировать платформо-зависимый код. Не заблуждайтесь, считая что все пользуются Internet Explorer; многие используют нестандартные браузеры (на мобильных телефонах и КПК) или предпочитают Firefox.

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

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


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Web-архитектура, Технология Java
ArticleID=230521
ArticleTitle=Знакомимся с ECMAscript
publish-date=06132007