Бабушкин наряд

Если в стандартном веб-приложении обработкой всей информации занимается сервер, тогда как браузер отвечает только за взаимодействие с пользователем, передачу запросов и вывод поступившего HTML, то в AJAX-приложении между пользователем и сервером появляется еще один посредник — движок AJAX. Он определяет, какие запросы можно обработать «на месте», а за какими необходимо обращаться на сервер. Поведение сервера тоже изменилось — если раньше на каждый запрос сервер выдавал новую страницу, то теперь он отсылает лишь те данные, которые нужны клиенту, а страницу из них формирует движок AJAX, отдающий браузеру понятный HTML. Асинхронность проявляется в том, что далеко не каждый клик пользователя доходит до сервера, причем обратное тоже справедливо — далеко не каждая реакция сервера обусловлена запросом пользователя (большую часть запросов формирует движок AJAX, причем его можно написать так, что он будет загружать информацию превентивно, предугадывая действия пользователя). Понятно, что с такой схемой работы качественная нагрузка на сервер меняется — если раньше запросов было мало, но каждый из них требовал значительных ресурсов (серверу нужно вытащить информацию из БД, сформировать из нее веб-страницу и отдать браузеру), то теперь задача сервера упрощается (формировать веб-страницы не нужно, да и объем передаваемых данных меньше), но запросов обрабатывать приходится больше.

Что из этого получится

AJAX появился совсем недавно. Один из первых реально работающих проектов появился в 2004 году (Gmail). Саму аббревиатуру изобрели только в начале этого года. Однако все ключевые технологии, необходимые для создания AJAX-приложений, были известны давным-давно[Было бы интересно поднять подшивки компьютерных изданий того времени. Наверняка только ленивый не пинал Microsoft за игнорирование общепринятых стандартов и продвижение собственных технологий. А прошло несколько лет, и оказалось, что вполне проприетарный XMLHttpRequest может оказаться весьма полезным, а кто его создал и почему — это уже вопрос десятый]. Теоретически AJAX-приложения можно было создавать еще лет семь назад. Все необходимые составляющие к тому времени на рынке уже были. Однако вместо того, чтобы штурмом завоевать веб, AJAX в лучшем случае использовался в интранет-приложениях или для решения специфических подзадач. Представить себе приложение, сопоставимое по уровню сложности с Gmail, в 1998 году невозможно. Собственно, приложение такого уровня вообще было трудно представить до тех пор, пока программисты Google его не написали.

Среди причин, помешавших AJAX сразу занять заслуженное место под солнцем, можно назвать неготовность индустрии (в 1997 году возможности привычных технологий были еще далеко не исчерпаны, и множество программистов с удовольствием игрались с Perl или PHP, не помышляя о смене архитектуры). Кроме того, заставить один и тот же код работать на всех браузерах в то время было невозможно — сейчас это сделать гораздо проще, хотя до сих пор некоторое шаманство требуется. Ну и наконец, клиентские машинки стали помощнее, и если в 1997 году для многих интернетчиков Javascript был назойливой примочкой, только замедляющей работу, то сегодня вполне можно передавать клиенту код из нескольких тысяч строк — если у пользователя нормальное подключение, то на передачу кода времени уйдет немного, а выполняться он будет без задержек на любой современной машине.

Проблемы AJAX

С 1997 года много воды утекло, но до сих пор AJAX нельзя назвать совместимым с разноликим парком клиентских браузеров. На многих браузерах AJAX-приложения просто не работают (хотя последние версии IE, Firefox и даже Opera — начиная с восьмой версии — нормально его поддерживают). Кроме того, сейчас на AJAX возлагаются определенные надежды (по крайней мере, компанией Adaptive Path, которая придумала саму аббревиатуру и усиленно пиарит этот подход к созданию веб-приложений), и очень вероятно, что AJAX их оправдает не в полной мере.

Дело в том, что AJAX — не универсальная технология. Радость «первооткрывателей» сродни восторгу модницы, обнаружившей в сундуке отличное бабушкино платье, в котором очень прикольно появиться на вечеринке. Однако всю жизнь в этом платье не походишь. Даже если отвлечься от совместимости, сама архитектура AJAX предполагает совершенно иной подход к созданию приложений, иной подход к созданию интерфейсов и, очевидно, годится далеко не для всех задач. Почему «очевидно», скептики объяснить не могут, но добавление в архитектуру приложения «посредника» между пользователем и хранилищем данных накладывает определенные, хотя и не совсем ясные пока ограничения. В любом случае, информация об ограничениях такого рода может быть добыта только методом проб и ошибок. Пройдет немного времени, разорится несколько компаний, канет в Лету десяток веб-проектов — и ограничения AJAX получат более или менее видимые очертания.

Есть и еще одно соображение. Добрый десяток лет веб-интерфейсы развивались в соответствии с установкой на ожидание ответа: каждый разработчик знал, что пользователю, нажавшему на любой элемент управления, придется ждать ответа сервера, и как-то старался уменьшить количество таких запросов, чтобы не заставлять пользователя тратить половину своего времени на ожидание загрузки страницы. С AJAX необходимость в таких реверансах пусть и не исчезла совсем, но актуальность, по большому счету, потеряла. Более того, можно попытаться предположить, какое действие пользователь может сделать дальше — и подгрузить на всякий случай необходимые данные. Все эти предположения практически повторяют анализ Роберта Морриса из IBM, который еще три года назад заявил, что важнейшие инновации в программном обеспечении лежат не в технологиях, а в изменениях пользовательского интерфейса.

С AJAX проблема заключается в том, что писать такие приложения — задача трудоемкая. Нужно написать и отладить на JavaScript движок из десяти или двадцати тысяч строк кода плюс реализовать серверную часть. Причем копировать удачные решения практически не у кого: по большому счету, действительно масштабными AJAX-проектами пока может похвастаться только Google, но у них проекты довольно специфические — Google Suggest (сервис, подсказывающий наиболее популярные запросы), Gmail и Google Maps. Наиболее основательной переработке программисты Google подвергли почтовый интерфейс, тогда как Google Suggest и Google Maps удивляют не столько новизной подхода, сколько качеством реализации. Впрочем, не исключено, что дальнейшее расширение функциональности Google Maps частично будет осуществлено вне гугловского кампуса. Уже есть несколько проектов, заметно расширяющих функциональность Google Maps. Самый известный проект такого рода создал Пол Рэйдмэйчер (Paul Rademacher), объединивший в одном интерфейсе карты Google Maps и объявления о сдаче жилья в наем (www.housingmaps.com). На подходе и конкурентная служба от Microsoft: Virtual Earth. Помимо привычных спутниковых снимков местности (эта функциональность в Google Maps уже включена) Virtual Earth предложит пользователям буквально прогуляться по городу[См. «КТ» #592. Правда, все описания Virtual Earth базируются на графических материалах, распространяемых Microsoft. Не исключено, что эти материалы выдают желаемое за действительное, а во время реального использования все будет выглядеть не так красиво].

Что это было?

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