И все же браузерные несовместимости и несколько насильственное использование не предназначенных для того технологий дают о себе знать. Каждое мелкое отличие в отображении HTML, каждая неоптимальная реализация возможностей JavaScript не слишком критичны для отображения документов, но способны разрушить или сделать малоприменимым интерфейс приложения.
И тут возникает идея использования схожих, но изначально "под интерфейсы заточенных" технологий: язык описания, подобный HTML, но более удачный; движок отображения встраивается в браузер, но более быстр, во всех браузерах работает одинаково и предоставляет больше специфических возможностей; скриптовый язык, подобный JavaScript (или он сам). Этим путем идут Adobe Flex [Чтобы не запутаться: Flash и Flex — две смежные технологии от одной корпорации Macromedia/Adobe: Flash — средство создания и отображения интерактивной анимации; Flex — технология создания пользовательских интерфейсов, основанная на Flash и использующая его для отображения этих интерфейсов. Сточки зрения клиента, и то и другое — Flash-ролик; но с точки зрения разработчика разница есть] — язык описания MXML, отображается Flash Player’ом; скриптовый язык ActionScript; Microsoft Silverlight — язык описания XAML, отображается Silverlight-плагином (который представляет собой легковесную часть более общей технологии Windows Presentation Foundation); скриптовый язык JavaScript (с версии 2.0 — и другие, в том числе компилируемые); OpenLaszlo [На этой платформе работает, например, pandora.com.] — язык описания LZX, отображается Flash Player’ом или как Java-апплет; скриптовый язык JavaScript; Curl (свои языки и плагины для всего). А в браузерный движок Gecko (Mozilla Firefox), например, без всяких плагинов встроен язык описания интерфейсов XUL — на нем-то и описан интерфейс и браузера, и плагинов. Кстати, и Sun, со своими Java-апплетами полезшая в эту область слишком рано и набившая все шишки, которые только возможно, теперь пытается войти в ту же реку второй раз с технологией JavaFX (и не только с ней — Sun поддерживает несколько фреймворков для создания веб-приложений).
Чтобы превратить "сайт" в "программу", то есть чтобы "веб-приложение" воспринималось пользователем более как "приложение", нежели "веб", требуется выполнить немало телодвижений. Приложение не должно быть "одной из вкладок браузера", ему нужно свое, отдельное окно. Неплохо бы и иметь возможность запускать приложение со своего диска (если у меня вообще нет доступа в Интернет, чтобы загрузить основной интерфейс Gmail, то как мне посмотреть свою старую переписку, даже если она хранится у меня на компьютере?) — а значит, "упаковывать" приложения и "устанавливать". При этом неплохо бы задуматься и о безопасности: не то "козел"-приложение, пущенный в "огород"-систему без присмотра, дорого обойдется пользователю.
Решений, в той или иной мере включающих в себя описанные возможности, существует несколько, все они следуют примерно одной и той же модели: пользователь единожды устанавливает у себя "запускалку", то есть платформу, и впоследствии может скачивать или запускать прямо с Веба сами приложения. В "скачиваемом" виде они, как правило, представляют собой архив со специальным расширением (например, webapp) и специальным набором файлов внутри. При запуске такого как-бы-приложения "запускалка" создает отдельное окно: оно, по сути, является окном браузера, но без привычных элементов и с иконкой запущенного приложения; кроме того, "запускалка" может предоставлять приложению дополнительные сервисы (скажем, JavaScript-функции для помещения иконки в трей) и, в идеале, должна контролировать уровень безопасности — скажем, требовать от всех запущенных приложений цифрового сертификата и/или спрашивать у пользователя разрешения на доступ к файловой системе, системным настройкам и рабочему столу.
Несколько примеров. Adobe AIR — это решение на основе браузерного движка WebKit (используется в Safari), "внутри" себя позволяет запускать air приложения, состоящие из HTML и Flash/Flex файлов, собранных в одно приложение с помощью бесплатного AIR SDK. Если на пользовательском компьютере установлен AIR, то air-приложения устанавливаются "совсем как настоящие" (меню "Пуск", "Установка и удаление программ" и т. п.) и, будучи запущены, выглядят как обычные приложения — и к трею доступ имеют, и обновляться (и даже запускаться) могут с Веба… Правда, модель безопасности в них достаточно простая — либо приложение подписано сертификатом, выданным Adobe, либо "Хотите ли вы запустить это неподписанное приложение?".
А вот Mozilla Prism (на движке Firefox’а, естественно) позволяет уже существующие веб-сервисы запускать как "совсем настоящие приложения". Для этого нужен специальный файл с расширением webapp — просто zip-архив, внутри которого лежит ini-файл, описывающий, какой сайт да с какой иконкой запускать. Впрочем, этим возможности Prism не ограничиваются — в том же webapp-архиве могут лежать и дополнительные js файлы, которые используют возможности интеграции в пользовательскую среду, предоставляемые Prism (например, раз в секунду проверять, поменялась ли строка, отображающая количество писем в загруженном Gmail приложении, и если да — отображать иконку-конвертик все в том же трее). Правда вот, с безопасностью и контролем у Prism пока совсем никак — но бета, бета ведь.
Из перечисленных ранее "производственных необходимостей" на пути к богатому интернет-приложению осталась необходимость хранения данных на клиенте:полученных писем, пользовательских настроек, уже загружавшихся частей карты, да мало ли чего. Наименее заметный для клиента (и оттого комфортный) способ предлагает библиотека Dojo.storage (часть огромного фреймворка Dojo, упоминавшегося выше как популярное средство построения HTML-интерфейсов).
Решение Dojo.storage иначе как хаком не назовешь библиотека позволяет использовать уже существующие на клиенте, но имеющие другое предназначение "хранилища": например, возможность браузера хранить информацию в cookies или скрытый Flash-объект (Flash-плагин имеет встроенную возможность сохранять небольшое количество информации на клиенте).
Как всякий хак, такое решение довольно уязвимо: и объем хранимого ограничен, и полностью рассчитывать на то, что в каждый следующий раз удастся записать/ прочитать сохраненную информацию, нельзя. Более надежное решение — Google Gears, устанавливаемый как плагин к браузеру и позволяющий умеющему работать с ним приложению хранить данные на клиентском компьютере (но только в специальной встроенной БД, доступа к файловой системе приложению не предоставляется). Adobe AIR также содержит встроенную БД и средства работы с ней (к слову, и Gears, и AIR, и многие другие используют один и тот же опенсорсный движок БД SQLite).
Возможно, судить еще рано, однако похоже, что тенденции на улучшение веб-приложений ведут клиентскую часть Веба куда-то далеко в сторону от изначальной "платформы для чтения документов". Например, мозилловцы, создавшие Prism, говорят о нем как о Site Specific Browser (каждому сайту свой браузер с подходящим именно этому сайту внешним видом и управлением), а горячие норвежские парни из Opera прямо говорят о своем курсе на превращение браузера в "полноценную платформу для приложений, работающую на любом устройстве"[Например, недавно Opera анонсировала поддержку Google Gears по собственному почину, не дожидаясь, пока "приспособление" биб лиотеки к браузеру сделает Google.]. Все это очень здорово, но как бы оставляет за кадром тот факт, что первоначальное назначение Веба — сети гипертекстовых документов — отнюдь не исчерпано. И тем не менее весь браузерный прогресс последних лет направлен вот на то самое — на превращение браузера в "платформу для всего" [Не могу не вспомнить бесконечно бородатую шутку про текстовый редактор Emacs, тоже стремившийся в свое время стать платформой и преуспевший: "Emacs — отличная операционная система, жаль, текстового редактора в ней нету". ], а не на удобство потребления информации. Не то пора, как предлагают некоторые, вводить HyperApplication Transfer Protocol — чтобы спасти Hyper Text от засилья приложений; не то пора создавать веб-приложение-для-удобного чтения [(Не сарказм.) Рекомендую обратить внимание, например, на New York Times Reader, сделанный на основе Microsoft WPF (то есть технологии, частью которой и является Silverlight). См]…