Ajax: Новый подход к веб-приложениям
Если и можно назвать "гламурным" что-то в современном проектировании интерфейсов, то это создание веб-приложений. В конце концов, когда в последний раз вы слышали чтобы кто-то восхищался интерфейсом продукта не размещённого в Интернете? ( Ладно, кроме iPod.) Все самые свежие и новаторские работы находятся в сети.
Несмотря на это, разработчики веб-интерфейсов не могут ничего поделать с завистью к своим коллегам, которые создают desktop-приложения. Обычные программы имеют всю ту силу и быстроту отклика, которые, кажутся недоступными для веб-приложений. Та же простота, которая способствовала быстрому распространению всемирной сети теперь создаёт разрыв между тем пользовательским взаимодействием, которое можем предоставить мы, и взаимодействием пользователей с настольными приложениями.
Этот разрыв сокращается. Взгляните на Google Suggest. Посмотрите, предполагаемые предложения почти непрерывно обновляются по мере того как вы вводите текст. Теперь зайдите на Google Maps. Увеличьте масштаб. Захватите курсором карту и подвигайте её туда-сюда. Опять же, всё происходит почти мгновенно, без всякого ожидания перезагрузки страницы. Google Suggest и Google Maps - вот два примера нового подхода к проектированию веб-приложений, который мы в компании Adaptive Path называем Ajax. Это понятие образовано как сокращение от и представляет собой фундаментальный прорыв наших представлений о возможностях веба.
Что такое Ajax
Ajax - не технология. На самом деле это несколько технологий преуспевающих каждая в своей области, собранных в новое сильное направление. Ajax объединяет:
- стандартизованное представление с использованием XHTML и CSS;
- динамическое отображение и взаимодействие при помощи Document Object Model;
- обмен и управление данными через XML и XSLT;
- асинхронные получение данных с использованием XMLHttpRequest;
- и JavaScript, связывающий всё это воедино.
Классическая модель веб-приложения действует следующим образом: большинство действий пользователя отправляют обратно на сервер HTTP-запрос. Сервер производит необходимую обработку - получает данные, обрабатывает числа, взаимодействует с различными унаследованными системами и затем выдаёт HTML страницу клиенту. Эта модель заимствована из первоначального применения веба как гипертекстовой среды, но те кто читали книгу
Рисунок 1: Сравнение традиционной модели веб-приложений (слева) с моделью Ajax (справа).
В этом подходе много технического смысла, но им не достигается хорошее взаимодействие с пользователем. Пока сервер делает свою работу, чем занимается пользователь? Правильно, ждёт. И с каждым следующим шагом пользователь ждёт ещё и ещё.
Очевидно, если бы мы создавали веб с нуля, то не стали бы заставлять пользователей всё время ждать. Если уж страница загружена, почему взаимодействие с пользователем должно останавливаться каждый раз, когда программе нужно что-то от сервера? В самом деле, зачем пользователю вообще видеть что приложение соединяется с сервером?
В чём отличие Ajax
Приложение Ajax исключает взаимодействие типа старт-стоп-старт-стоп путём введения механизма Ajax как промежуточного слоя между пользователем и сервером. Может показаться что добавляя новый уровень в приложение можно только замедлить его реакцию, но в действительности наоборот.
Вместо того чтобы загружать страницу в начале пользовательской сессии браузер загружает движок Ajax, написанный на JavaScript и обычно спрятанный в скрытый фрейм. Этот движок отвечает за формирование пользовательского интерфейса и взаимодействие с сервером от имени пользователя. Движок Ajax позволяет производить взаимодействие с пользователем асинхронно, то есть независимо от взаимодействия с сервером. Таким образом пользователю больше не нужно наблюдать пустое окно браузера и курсор в виде песочных часов в ожидании действий сервера.
Рисунок 2: Сравнение диаграмм взаимодействия традиционного веб-приложения (сверху) и асинхронного приложения Ajax (снизу).
Каждое действие пользователя, которое обычно производит HTTP-запрос, теперь вместо этого принимает форму JavaScript-вызова движка Ajax. Каждый ответ на действие пользователя, не требующее обращения к серверу, как то простая проверка данных, редактирование данных в памяти, и даже некоторая навигация, выполняется движком самостоятельно. Если же для ответа требуется информация с сервера, например загрузка дополнительного интерфейсного кода, передача данных для обработки, или получение новых данных, то движок производит необходимые запросы асинхронно, обычно при помощи XML, не прерывая взаимодействия пользователя с приложением.
Кто использует Ajax
Огромные инвестиции в разработку подхода Ajax делает Google. Все самые крупные продукты анонсированные за последний год - Orkut, Gmail, последние бета-версии Google Groups, Google Suggest, и Google Maps - приложения Ajax. (За техническими подробностями реализации Ajax обратитесь к отличным исследованиям Gmail, Google Suggest и Google Maps.) Остальные не отстают: многие любимые всеми свойства сервиса Flickr полагаются на Ajax, а механизмы поиска A9.com от Amazon используют похожую технологию.
Эти проекты демонстрируют, что Ajax работает не только в теории, но и на практике для реальных приложений. Это не очередная лабораторная теория. Приложения Ajax могут принимать любой масштаб от простого и с состоящего из одной функции Google Suggest до очень сложного и замысловатого Google Maps.
Работая с Ajax последние несколько месяцев, мы в Adaptive Path поняли, что открыли только верхушку айсберга того богатства взаимодействия и скорости отклика, которые предоставляют приложения Ajax. Сейчас это важное направление развития веб-приложений, и его важность будет только расти. И учитывая большое количество разработчиков, которые уже умеют использовать эти технологии, мы ожидаем увидеть как всё больше организаций последуют примеру Google и используют конкурентные выгоды, которые предлагает Ajax.
Что дальше
Основная задача создания приложений Ajax не техническая. Ведь основополагающие технологии Ajax выдержаны временем, стабильны и хорошо изучены. Наоборот, задача для разработчиков этих приложений заключается в том, чтобы забыть о своих представлениях об ограничениях веб-приложений и начать думать шире, большим спектром возможностей.
Будет интересно.
Вопросы и ответы.
13 марта 2005: После публикации эссе Джесси мы получили громадное количество писем от читателей с вопросами об Ajax. Здесь Джесси отвечает на некоторые наиболее общие вопросы.
Вопрос. Изобрела ли Ajax компания Adaptive Path или это сделала Google? Участвовала ли компания Adaptive Path в создании Ajax-приложений Google?
Ответ. Ни Adaptive Path ни Google не изобретали Ajax. Последние работы Google просто лучшие примеры приложений Ajax. Adaptive Path не была вовлечена в разработку Ajax-приложений Google, но мы делали это для других своих клиентов.
Вопрос. Продаёт ли Adaptive Path компоненты Ajax или является владельцем зарегистрированного товарного знака? Где их можно скачать?
Ответ. Ajax это не то, что можно скачать. Это подход, то есть способ представлений об архитектуре веб-приложения использующего определённые технологии. Ни подход, ни само название Ajax не являются собственностью Adaptive Path.
Вопрос. Является ли Ajax ещё одним названием для XMLHttpRequest?
Ответ. Нет. XMLHttpRequest только часть уравнения Ajax. XMLHttpRequest - это технический компонент, который делает возможными асинхронные взаимодействия с сервером; Ajax мы называем общий подход описанный в статье, который основывается не только на XMLHttpRequest, но также на CSS, DOM, и других технологиях.
Вопрос. Для чего нужно было давать всему этому название?
Ответ. Нужно было что-то более короткое чем для обсуждения этого подхода с клиентами.
Вопрос. Способы асинхронного взаимодействия с сервером существуют уже много лет. В чём же новизна подхода Ajax?
Ответ. Новизна в выдающемся использовании этих способов для изменения фундаментальной модели взаимодействия в реальных веб-приложениях. Ajax закрепляется только сейчас потому, что требовалось время для развития этих технологий и представлений о том как наилучшим образом их применять.
Вопрос. Ajax это технологическая платформа или всего лишь стиль проектирования?
Ответ. И то и другое. Ajax это набор технологий используемых вместе определённым образом.
Вопрос. Для приложений какого типа больше всего подходит Ajax?
Ответ. Пока мы этого не знаем. Из-за относительной новизны данного подхода наши представления о том где он лучше всего применяется всё ещё на начальной стадии развития. Иногда и традиционная модель веб-приложения подходит как наилучшее решение задачи.
Вопрос. Означает ли это что Adaptive Path это анти-Flash?
Ответ. Совсем нет. Macromedia является клиентом Adaptive Path, и мы долгое время поддерживали Flash-технологию. Как специалисты в Ajax мы ожидаем что иногда для каких-то конкретных задач именно Ajax станет наиболее проходящим решением, а иногда лучшим решением будет Flash. Также мы заинтересованы в изучении способов комбинирования этих технологий (как в случае с Flickr, который использует и то и другое).
Вопрос. Есть ли у Ajax значительные ограничения доступности или совместимости с браузерами? Отключают ли приложения Ajax кнопку ? Совместим ли Ajax с REST? Существуют ли мнения о безопасности разработки в Ajax? Могут ли быть разработаны Ajax-приложения для работы при выключенном JavaScript?
Ответ. На все эти вопросы можно ответить только . Многие разработчики уже работают в этом отношении. Мы считаем что нужно ещё потрудиться чтобы выявить все ограничения Ajax, и предполагаем что на своём пути сообщество разработчиков встретит ещё много подобных вопросов.
Вопрос. Некоторые из приведённых вами примеров Google не используют XML вообще. Должен ли я использовать XML и/или XSLT в приложении Ajax?
Ответ. Нет. XML это один из наиболее развитых способов ввода и вывода данных из клиентской части Ajax, но ничто не мешает вам достигнуть того же эффекта при помощи таких технологий структурирования данных для обмена как JavaScript Object Notation или тому подобных.
Вопрос. Проще ли разработать приложение Ajax по сравнению с традиционным веб-приложением?
Ответ. Не обязательно. Ajax приложение неизбежно приводит к запуску сложного кода JavaScript на стороне клиента. Не так то легко сделать этот сложный код эффективным и свободным от ошибок, и для успеха в этом потребуются лучшие структуры и инструменты разработки.
Вопрос. Всегда ли приложение Ajax представляет лучшее взаимодействие с пользователем, чем традиционно веб-приложение?
Ответ. Не обязательно. Ajax более гибок для проектировщиков интерфейса. Однако, чем большую мощь мы имеем, тем более внимательно нужно с ней обращаться. Надо быть осторожными в использовании Ajax, чтобы улучшить удобство использования приложений, а не ухудшить его.