AJAX: новый уровень интерактивности Web-страниц

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

Муж сей – Аякс Теламонид великий, твердыня данаев...
Гомер. Илиада

О вреде ожидания

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

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

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

Одним словом, задержки, связанные с передачей информации по Сети, с годами не исчезли и в дальнейшем ситуация вряд ли принципиально улучшится. Чтобы найти выход или хотя бы определить, где его искать, надо прежде всего понять суть проблемы. Как ни странно, она состоит не в том, что активизация ссылки не приводит к немедленному получению результата. Гораздо хуже, что в течение времени, необходимого для загрузки, старая страница уже недоступна, а новая еще не получена, поэтому пользователю приходится прерывать работу и ждать. Как показали исследования, подобный режим существенно снижает производительность труда. Кроме того, часто бывает, что новый сайт отличается от старого лишь в мелочах. На месте остаются элементы навигации, колонтитулы, а заменяется лишь небольшой фрагмент текста или одно-два изображения. Возникает резонный вопрос: почему бы не копировать по Сети лишь ту часть документа, которую действительно нужно обновить, и нельзя ли на время загрузки дополнительной информации предоставить пользователю возможность продолжать работу с текущей страницей? Ответ на него дает новая концепция Ajax, объединяющая несколько давно известных технологий.

Запрос к серверу из сценария

До недавнего времени вся работа в Web строилась по принципу полной замены текущего документа. При активизации гипертекстовой ссылки или формы браузер передавал запрос серверу, который возвращал ответ в виде HTML-документа. Ситуация изменилась с появлением объекта XMLHttpRequest, доступного из JavaScript-сценариев.

Объект XMLHttpRequest берет на себя одну из функций браузера, а именно формирование и передачу запроса Web-серверу, и воспользоваться ею довольно просто. Сначала следует открыть запрос (метод open()), указав характеристики заголовка, а затем передать его (send()). Принципиальный вопрос – нужно ли теперь ждать ответа? Если бы дело обстояло так, то объект XMLHttpRequest был бы совершенно бесполезен. Согласитесь, пользователю ведь все равно, кто «отключит» интерактивные возможности документа – браузер или JavaScript-сценарий. К счастью, в методе open() предусмотрен специальный параметр – флаг асинхронного выполнения. Если его значение равно true, метод send() практически сразу же вернет управление сценарию, и в то время, пока запрос будет «путешествовать» по направлению к серверу, а затем ответ проходить тот же путь в обратном направлении, пользователь сможет продолжить работу с документом. Конечно, новая информация, которая должна поступить в ответе, будет некоторое время недоступна, но тут уж ничего не поделаешь – пауза неизбежна. Зато текущая страница останется в полном распоряжении пользователя.

Что же произойдет при получении ответа? Очевидно, управление должно перейти к функции обратного вызова (подобный подход не нов и вряд ли его стоит здесь обсуждать), задать которую позволяет свойство onready statechange того же объекта XMLHttpRequest. С помощью свойства readyState мы проверяем состояние процесса обработки запроса (значение 4 свидетельствует о его окончании) и при необходимости извлекаем данные из свойств responseText или responseXML.

Вспомним DOM

Итак, принципиально задача решена: нам удалось загрузить новые данные, не прерывая работу пользователя с текущей страницей. Однако для практического применения этого мало. Полученные данные нужно как-то включить в состав документа, уже отображающегося на экране. К счастью, это возможно, – подходящий механизм давно отработан и широко известен: надо воспользоваться структурой DOM. При этом от свойства responseText лучше отказаться, так как его применение потребует дополнительного синтаксического разбора. Гораздо полезнее responseXML, в котором информация изначально представляется в совместимом с DOM виде. Таким образом, в структуре текущего документа необходимо выбрать узел, в состав которого следует включить возвращенные данные, и вызвать метод replaceChild(), заменив старое и ненужное поддерево новым, прочитанным из responseXML объекта XMLHttpRequest.

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

Ajax – не только имя

Выполнив упомянутые выше действия, мы получим не что иное, как Ajax-приложение. Несмотря на предельную простоту оно, тем не менее, отражает все особенности, характерные для инфраструктуры Ajax. Во-первых, и это самое главное, запрос передается серверу в асинхронном режиме (отсюда первая буква в имени Ajax: «a» – asynchronous). Во-вторых, инициатором запроса выступает JavaScript-сценарий («ja» – JavaScript). Теперь совсем не обязательно размещать на странице гипертекстовые ссылки. Запрос может быть сформирован в ответ на попадание курсора мыши в некоторую область или по истечении заданного времени (в общем, его можно «привязать» к любому событию). И, в-третьих, серверу совсем не обязательно передавать в ответ на запрос целый документ. Достаточно, если браузер получит лишь фрагмент, в котором пользователь в данный момент нуждается. Посредством DOM мы включаем его в состав текущей страницы и формируем внешний вид с помощью правил CSS. Ну а чтобы не нарушалась структура, например, чтобы не встречались открывающие дескрипторы без закрывающих (как известно, существующие браузеры очень лояльны к подобным ошибкам), целесообразно вообще отказаться от HTML – гораздо большего доверия заслуживает формат XML (отсюда и последняя буква: «x» – XML). К сожалению, имени античного героя не хватило для обозначения структуры DOM и каскадных таблиц стилей, но очевидно, что без них не обойтись. Ведь полученные данные надо как-то включить в состав документа, и удобнее всего сделать это именно средствами DOM. Кроме того, в отличие от HTML для элементов XML не предусмотрены правила отображения по умолчанию, и придать им требуемый внешний вид можно только посредством стилей (CSS или же XSL).

А что же нового?

Традиционно новый подход к созданию приложений и инструмент, позволяющий реализовать его на практике, появляются практически одновременно и идут рука об руку. Какой же инструмент претворяет идею Ajax в жизнь? Объект XMLHttpRequest был разработан задолго до Ajax. Язык JavaScript не намного моложе HTML. XML и CSS также широко известны.

Как ни странно, ни одну базовую технологию для Ajax создавать не пришлось, но именно эта особенность и является одним из главных преимуществ данной концепции. Платформу для выполнения Ajax-приложений можно собрать из готовых компонентов, необходимо лишь, чтобы браузер, применяемый для просмотра документов, поддерживал объект XMLHttpRequest. Но это уже забота пользователя – если речь идет не о корпоративной, а о Всемирной Сети, разработчики Web-приложений никак не могут влиять на выбор клиентских программ.

Что получает пользователь

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

Однако предоставляя пользователю новые возможности, клиентская программа не может не измениться сама. Если раньше в «классических» Web-приложениях вся обработка осуществлялась на стороне сервера, то в Ajax такой подход неприемлем. Если каждое решение будет приниматься на сервере, то практически безразлично, в каком режиме передаются запросы: асинхронном или синхронном, в любом случае до получения ответа придется приостановить работу. Выход заключается в повышении «уровня интеллекта» клиентской программы, которая должна обеспечивать интерактивное взаимодействие с пользователем, лишь изредка обращаясь к серверу. А это неминуемо приведет к увеличению объема клиентского кода – JavaScript-сценарии в составе документа становятся все сложнее, и для их создания приходится затрачивать больше времени и усилий.

Существует еще одна особенность Ajax-приложений. Поскольку с сервера загружаются не целые документы, а их фрагменты, динамически отображаемые посредством DOM, время работы пользователя с одной страницей многократно возрастает. Это хорошо видно даже на примере простого приложения, основные этапы создания которого были рассмотрены выше. И если при классическом Web-взаимодействии незначительные ошибки бывают некритичны (все равно через несколько минут пользователь запросит новую страницу), то в Ajax-приложении требования к качеству документов существенно повышаются. Как всегда, чтобы обеспечить пользователям комфортные условия, программистам приходится работать интенсивнее и брать на себя дополнительную ответственность.

Сервер остается сервером

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

Поработать с Ajax? Нет ничего проще!

Несмотря на относительную новизну Ajax как концепции, примеры успешных проектов уже доступны в Глобальной Сети. Например, в службе GMail реализовано автоматическое обновление информации о поступивших письмах независимо от действий, которые в этот момент выполняет пользователь. На основе Ajax созданы также Google Suggest и Google Maps. Нетрудно заметить, что именно Google на сегодняшний день является бесспорным лидером по применению Ajax и главным апологетом этой концепции, однако и другие компании стараются идти в ногу со временем. В частности, примеру Google уже в ближайшем будущем собираются последовать mail.ru и еще ряд онлайновых служб.

Так что же ожидает Ajax? Разделит ли данная концепция участь многих модных новинок, попадающих в поле зрения программистов лишь для того, чтобы вскоре оказаться навсегда забытыми? Ответ, видимо, должен быть отрицательным. И пользователи, и разработчики осознают недостатки классических Web-приложений и будут приветствовать любое решение, способное их устранить. Если же Ajax и уступит место, то только той технологии, которая позволит достичь еще большей эффективности. А пока многие ведущие специалисты, коллективы и известные компании взяли курс на Ajax и в обозримом будущем свернуть с него вряд ли захотят.

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365