Эти гибриды обозначаются термином RIA (Rich Internet Applications, "богатые" интернетприложения; а раньше Smart Client, "умный клиент"). Так уже много лет называют гипотетические приложения, более удобные, чем обычные сайты-сервисы, и более Интернето-центричные, чем обычные приложения. Неизвестно, что тому виной — рост ли пропускной способности сетей, приход ли "нового веба", или что иное, но лишь в последние года полтора-два эти гипотетические приложения стали стремительно становиться реальностью. Как и почему — выясним?
Введение в ria в вопросах и ответах
Чем плох браузер?
Да всем хорош. В своей роли: программыпросмотрщика гипертекстовых документов. Равно как язык разметки HTML — отличный язык для разметки гипертекстовых документов[Ну, про его "отличность" есть и альтернативные мнения — как у практиков (разработчиков браузеров и веб-дизайнеров), так и у теоретиков (радетелей Семантической Сети). Но все же.]. Да вот беда: ни то ни другое к созданию приложений не имеет ни малейшего отношения — by design, то есть по определению. И сам HTML как язык разметки, базовыми элементами которого являются абзацы, списки, таблицы, предполагает "поток текста с форматированием", а вовсе не пользовательский интерфейс произвольной формы. И динамическое взаимодействие с HTML-приложениями ограничено "переходом на другую страницу" (ссылка) да "отправлением заполненной анкеты на сервер" (форма). И ограниченность (точнее, отсутствие) связи с пользовательским окружением мешает развернуться — ни иконку информационную в трей не запихнуть, ни вложение в письмо в подходящей программе сходу не открыть. И необходимость для обработки каждого малейшего действия пользователя связываться с сервером мешает в средах с нестабильным подключением (например, мобильных).
А чем тогда плохи обычные приложения?
Здесь достаточно сказать одно слово: платформа.
При всех своих недостатках (см. выше) приложение-вбраузере или его аналоги имеют и массу достоинств: простота доставки пользователю, установки и обновления (в том смысле, что никого не приходится просить "пожалуйста, скачайте новую версию Gmail" — она просто есть), естественность взаимодействия с сервером, лучшее обеспечение безопасности пользователя (неизвестное приложение имеет немного возможностей проникнуть в его систему), работа приложения под всеми распространенными настольными ОС — был бы браузер современный. Да и сами веб-технологии (клиентская часть — HTML/CSS/JavaScript), с технической точки зрения, — штука простая, высокоуровневая и работающая: с сервера по простому протоколу передаются простые текстовые описания пользовательского интерфейса (которые могут быть сгенерированы мириадами способов и технологий), а умный и эффективный клиент-браузер их отображает.
Может показаться, что все достоинства вебприложений есть обратные стороны их же недостатков (техническое удобство HTML-интерфейсов против семантического неудобства; недостаточная интеграция приложения с рабочим столом против высокой степени безопасности; необходимость за каждым чихом соединяться с сервером против отсутствия необходимости доставки-установки). Однако некоторые технологические новинки последнего времени, которым, собственно, и посвящена эта статья, показали, что кое-какие "плодотворные сдвиги" в этой области вполне возможны.
Ну, допустим. А что нужно-то? В какую сторону должен происходить "сдвиг"?
Ответ на этот вопрос органически вытекает из ответа на предыдущие. Нужно средство создания богатых, нетривиальных, динамичных интерфейсов — но позволяющее описывать их на достаточно лаконичном языке (который можно было бы передавать с сервера на клиент как простой текст). Нужна возможность интеграции с пользовательской операционной средой (каждое веб-приложение имеет отдельное окно без "стандартных элементов браузера", может встраиваться в трей, вешать панели на рабочий стол и т. п.) — но контролируемая, с не слишком большими уступами со стороны безопасности. Нужна возможность хранения на клиентском компьютере рабочих данных (актуальных настроек, уже полученных писем и т. п.) и самого интерфейса приложения — чтобы иметь возожность работать в среде с нестабильным интернетподключением и минимизировать трафик — забирать с сервера только обновившуюся информацию[Еще раз подчеркнем — это требование обосновано скорее не потребностями "бедных домашних" пользователей с dial-up’ом, а "богатых мобильных" пользователей с WiFi’ем.].
К этим главным требованиям добавляются и веяния времени — пользовательский интерфейс должен быть "богатым" не только с точки зрения эффективного представления информации и удобного управления, но и в самом приземленном смысле: переливающиеся кнопочки, плавно выплывающие менюшечки — то есть динамические графические эффекты.
Личное мнение: вообще говоря, тот факт, что мощнейшие наработки современной графики — возможности железа и библиотек — используются в основном для украшения кнопок, а не для более эффективного представления информации, автор склонен считать признаком упадка нравов и победы потребительской цивилизации.
И что, есть решения, удовлетворяющие этим требованиям?
Полноценного и стопроцентного — кажется, еще нет ["Кажется" — потому что в этой горячей области все меняется чуть ли не ежедневно. Например, Adobe AIR уже существует, но возможности его полностью еще не распробованы.].
Но шаги в нужном направлении — и какие шаги! — делают многие, от гранд-монстров до еще вчера никомуне ведомых героев open source. Если разобраться в этих шагах и аккуратно их разложить, то и в фейерверке технологий, заявленном в первом абзаце, разобраться немудрено.
Рассказ об интерфейсах "богатых интернет-при ложений" (Rich Internet Applications) нельзя не начать с Gmaiclass="underline" роль этого сервиса в мэйнстримовом понимании "как можно делать веб-приложения" переоценить трудно. При этом, заметим, технологии использовались "старые": HTML/CSS/JavaScript. "Весь секрет" был лишь в довольно большом объеме кода на JavaScript (некогда созданного для простых однострочных инструкций типа "показать это окошко, когда нажмут ту кнопку") и использовании недооцененной возможности JavaScript по отправке запросов на удаленный сервер и получению ответов. Свершение Gmail было идеологическим, а не технологическим: он как бы сказал всем "вот эти (давно существующие) технологии можно использовать и так". Надо заметить, что у новаторского подхода были довольно существенные недостатки: во-первых, проблема переносимости по операционным системам сменилась проблемой переносимости по браузерам (очень немногие из которых оказались готовы к использованию возможностей JavaScript "на пределе", да и готовые исполняли его по-разному); вовторых, программирование сложных элементов интерфейса и аккуратного обновления их с сервера — работа довольно-таки нетривиальная.
Проблема адаптации к разным браузерам хоть и не решена полностью по сию пору, но стала в некоторой степени проблемой производителей браузеров, а не разработчиков веб-приложений. Здесь тоже большую роль сыграл масштаб шума вокруг гугловских сервисов, поставив вопрос ребром: "А в вашем браузере Google Maps работает?".
А вот для того, чтобы справиться со сложностью самой разработки, за истекшие годы было создано несколько решений разного толка. Одни из них — удобные библиотеки для эффективного изменения содержимого веб-страницы (например, jQuery, Prototype) — своим существованием обязаны гибкости и изяществу самого языка JavaScript, ранее недооцененного. Другие — Dojo, mooTools, Yahoo! UI Library или приложения к тем же jQuery и Prototype — это большие подборки готовых, профессионально разработанных и отлаженных элементов пользовательского интерфейса и вспомогательных объектов. Третьи, например Google Web Toolkit[Занятно, что для создания Gmail и Google Maps эта библиотека не использовалась. ], вообще предпочитают использовать веб-технологии как "высокоуровневый ассемблер" — приложения при помощи GWT пишутся на Java, а потом пользовательский интерфейс "компилируется" в HTML/JavaScript. Перечисленные средства, как правило, берут на себя не только построение динамичного интерфейса и обновление его с сервера, но и "красивости" (плавное выпадение меню, полупрозрачные окошки и пр.) и некоторую часть несовместимостей между браузерами.