Содержание статьи
Компания Google практически не занимается разработкой десктопных приложений.
Ребята, безусловно, могли бы, но делать это незачем. Уже сейчас в вебе можно
разрабатывать приложения, которые успешно выполняются в рамках браузера. А
каждый день появляются все новые и новые технологии, которые, наконец, позволят
нам из пресловутой веб-странички сделать мощное приложение, по возможностям
ничуть не уступающее десктопным программам. Многие из этих технологий
разрабатываются в рамках работы над стандартом HTML5.
Интернет устарел, и об этом все знают! Сначала думали, что все обойдется, но
когда в Сети появились толпы людей, которых не интересовали скучные технические
отчеты и документация, это стало очевидно. Сеть требовала красоты и
функциональности: изображений, анимации, видео и аудио. Чтобы показать на
странице все, что взбредет в голову дизайнера, напрягаться приходится и
разработчикам браузеров, и составителям стандартов. Постепенно из обычного
формата разметки текста HTML превращался в довольно сложный стандарт, на базе
которого делали привычные нам страницы интернет-магазинов, банковские системы,
онлайн-игры и порносайты. Но возможностей стандарта HTML4 уже мало, а если уж
говорить совсем на чистоту, то стандарт устарел уже в момент его создания.
Первыми фишку потребностей народа просекли в Macromedia, давно купленной
гигантом Adobe, которые выпустили сначала Shockwave, а потом и Flash. Flash дал
то, что всем так хотелось – видео, звук и анимацию, возможности программировать
графику и создавать более-менее реальные приложения. Для особо одаренных была
реализована возможность объединить JavaScript и Flash (замечу, очень
по-уродливому и ненадежно), таким образом дополняя упущения разработчиков
браузера. Видео заполонило мир, YouTube, Facebook и ВКонтакте стали самыми
популярными сайтами. Во многом благодаря флешу, потому что без видео и
приложений это были бы намного более унылые ресурсы.
Упущенные возможности
Но разработчики стандарта HTML тоже поняли свое упущение и решили: надо дать
народу новый стандарт, чтобы все делали свое дело, не уходя из обычной платформы
браузера во всякие Flash/Silverlight/JavaFX. Дополнительный плагин для
отображения страницы — это уже по определению плохо. Пользователям это нужно
ставить, обновлять, мириться с дополнительными тормозами. А сам браузер из
основного окна в мир Сети стал ненужной прослойкой для запуска приложения на
Flash’е или Silverlight’е. Сети срочно потребовался новый стандарт взамен
устаревшего HTML4. Его и придумали, незатейливо обозвав HTML5. Это уже не только
и не столько язык для разметки страниц и их форматирования, сколько руководство
для разработчиков браузеров, какие возможности они должны предоставлять странице
и выполняемому там коду. При этом вторгаясь совсем не в область разметки,
поручили браузеру дать невиданные возможности скриптам. Отныне работа с видео и
звуком, 2D- и 3D-графикой, анимацией, эффектами, сетью на низком уровне – все
это должно быть доступным в обычном JavaScript.
Основная задача нового стандарта — расширение стандарта разметки веб-страниц
для того, чтобы создавать красивые и функциональные сайты стало легче и проще.
HTML5 развивается в двух направлениях. Первое — это расширение языка HTML для
внедрения новых возможностей, которые раньше делались через грязные хаки и при
помощи сплава CSS и JavaScript. В основном это всякие визуальные штучки вроде
скругленных уголков, элементы ввода (веб-формы) и прочие украшательства. Второе
— добавление в веб новых возможностей с таким расчетом, чтобы веб-приложение
имело все те же возможности, что и обычное десктопное приложение, при этом от
пользователя требовался бы только браузер без всяких плагинов или дополнительных
приблуд. Самый лучший этому пример – воспроизведение видео (привет, YouTube).
Сейчас надо на JavaScript и Flash написать плеер, организовать далеко не
тривиальную серверную часть, обеспечить все стандартные возможности
(проигрывание, остановку, прогрессивную загрузку и т.п.). Морока еще та. HTML5
тебе говорит, что это все не нужно – пусть браузер этим занимается, а ты просто
вставь новый тег <video> и все. Элементы управления плеера, сам код и даже
видеокодек – все это стандартно и уже есть в браузере. Предлагаю игры с
разметкой оставить неудачникам, которые стали верстальщиками, и познакомиться с
теми новыми технологиями, которые появились в HTML5.
В чем сила HTML5, брат?
Раньше веб-странички содержали или обычный текст, пусть и с форматированием,
или же заранее подготовленные изображения в растровых форматах JPEG/GIF/PNG,
изредка приправленные анимацией. Flash с его векторной природой и динамическим
рисованием сделал просто революцию – стало возможно генерировать анимацию прямо
на лету, реагируя на действия пользователя, масштабировать ее и накладывать
различные эффекты. Обычный HTML был лишен такого счастья и мог оперировать
только символами и объектами документа, но не отдельными графическими
примитивами вроде линий или точек. Ну что ж, теперь это все в прошлом. Canvas –
это одна из самых ожидаемых и мощных возможностей в HTML5. Как выглядит работа с
графикой теперь? Ты просто создаешь специальный тег, внутри которого, в
указанном прямоугольнике, имеешь возможность работать напрямую с пикселями и
графическими примитивами вроде фигур, линий, окружностей и т.п. И все это
доступно для управления программным способом через JavaScript. Если ты пробовал
программировать еще в DOS или интересовался, как делают игры, то должен
представлять, какие чувства вызывает необходимость рисовать по пикселям и
выводить каждую линию. Но раньше-то и этого не было. Если разработчики вовремя
подсуетятся и выпустят развитые библиотеки для рисования, можно сказать, что
Flash, наконец-то, обречен. Простейший пример использования canvas:
function draw()
{
var canvas = document.getElementById("canvas");
if (canvas.getContext) {
var ctx = canvas.getContext("2d");
ctx.fillStyle = "rgb(200,0,0)";
ctx.fillRect (10, 10, 55, 50);
ctx.fillStyle = "rgba(0, 0, 200,
0.5)";
ctx.fillRect (30, 30, 55, 50);
}
}
<body onload="draw();">
<canvas id="canvas" width="150" height="150"></canvas>
</body>
Canvas, конечно, не такой уж и новый или уникальный. Давно есть возможность
рисовать, используя разные ухищрения, вроде специального языка VML в браузерах
от Microsoft или свободных форматов SVG в Mozilla или Safari. Но годится это
разве что для рисования графиков, для которых не требуется много ресурсов.
Canvas — совсем другое дело. Производители браузеров заявили, что уже умеют
оптимизировать такие операции, передавая их на графическую карту. Теперь браузер
будет кушать не только память и процессор, но и GPU. В последних версиях Google
Chrome и IE 9beta для ускорения работы с графикой в элементе canvas используется
аппаратная поддержка и DirectX API.
Как попробовать HTML5?
Не буду скрывать – HTML5 как стандарта еще нет, многие части его
противоречивые и сырые. Производители браузеров думают по-разному,
реализовывают то, что хотят, и как сами считают нужным. Мол, нет еще
стандарта, поэтому сиди, юзер, молчи в тряпочку и жди, пока мы все сделаем!
И ждать этого вашего HTML5 годами. Но если ты разработчик, или просто решил
похвастаться, то вот тебе пара кратких рецептов, как добавить поддержку
HTML5-фич на свою страницу уже сейчас, не дожидаясь поддержки от браузера.
Конечно, это все костыли – где-то эмулируется через Flash, где-то через
сторонние библиотеки или CSS, но зато уже сейчас и во всех браузерах.Для начала нужно сверстать страницы по всем правилам, а чтобы можно было
использовать новые элементы разметки, и браузеры без их поддержки не
ругались, лучше всего сразу применить готовый шаблон – HTML5 Boilerplate,
который содержит в себе множество уже готовых фиксов и заменителей для
браузеров без нативной поддержки нового стандарта.Если хочешь проверить, что поддерживает браузер пользователя, то тебе
пригодится библиотека Modernizr, которая тестирует браузер на поддержку
множества разных фич и выдает это в виде API или просто как свойства
элемента body. Заметь, что скрипт только тестирует наличие или отсутствие
поддержки, а не эмулирует недостающий функционал.Для выводов простой векторной графики и рисования можно применить Raphael,
созданный, кстати, нашим программистом. Библиотека может работать как с SVG,
так и с VML, и скрывает от тебя все внутренности рисования. А заменить
canvas поможет разработка от гугла – exCanvas, с которой даже тупой IE7
сможет рисовать все, что ты ему прикажешь.Хранить данные можно при помощи Sessionstorage (единственный из скриптов,
который честно эмулирует все WebStorage API) или более знакомого нам jStore
(плагин к jQuery), который хотя и использует свой API, но что поделать.Хочешь воспроизводить видео и построить второй Youtube (ладно, чего уж
там, Porntube тоже сойдет) – можешь использовать плеер Video for Everybody,
который добавляет поддержку тега <video> при помощи JS-библиотеки и
Flash-проигрывателя.Всякие рюшечки в формы добавить? Легко при помощи библиотеки WebForms2,
работающей во всех браузерах.WebSocket – самая бедная часть, потому как полноценно ее эмулирует только
один проект. Разработка web-sockets-js использует небольшую JS-обертку над
Flash’ем. На сегодня это лучшее решение, умеющее проходить даже через разные
умные и не очень прокси и файерволы.Для обмена сообщениями между разными фреймами, в том числе и с разных
доменов подойдет библиотека easyXDM.Если очень захотелось уже сейчас использовать новую модель селекторов или
же другие фичи из CSS 3, здесь на помощь придет selectivizr и css3pie,
добавляющий свойства скругления уголков блоков и прочие радости жизни.
Что имеешь, не хранишь, загружая – плачешь
Если ты пробовал делать что-нибудь сложнее домашней странички, наверняка
сталкивался с ситуацией, когда на стороне клиента необходимо сохранить какую-то
информацию, чтобы сто раз не гонять ее по сети с сервера. Раньше единственным
вариантом было просто тупо загнать ее в JavaScript-переменную, но она жила лишь
то время, пока страница была открыта в браузере. Закрыл страницу – и все
безвозвратно исчезало. Если клиент возвратился на сайт, то все приходилось
загружать сначала, даже если ничего не изменилось. Cookies с задачей хранения
данных не справлялись, и единственное, что могли предложить – хранение
идентификатора, который тебе приходилось уже привязывать на сервере к данным
пользователя. Да и много ли можно сохранить в 4 Кб (а именно столько можно
хранить в одной "печеньке")? К тому же они посылаются на сервер с каждым
HTTP-запросом, что непомерно раздувает сетевой трафик.
Новая фишка – WebStorage или DOM Storage – призвана разгрузить приложение,
перенося часть данных на клиентскую сторону. Например, если у тебя есть
онлайн-магазин, то данные о самых популярных товарах можно хранить сразу у
клиента, лишь периодически его обновляя (и чем больше данных, тем заметнее
выигрыш). Разработчики получают единый механизм доступа к данным, независимость
хранилища от сайта, стойкость не только к закрытию вкладки или окна браузера, но
и к полной перезагрузке компьютера. Сколько данных можно так хранить? По
спецификации объем данных не ограничивается, но на деле IE разрешает до 10 Мб на
домен, в Firefox чуть скромнее – до 5 Мб. Неожиданно, но в деле реализации
спецификации хранилища Microsoft реально впереди всех остальных браузеров, так
как реализует не только рекомендованные спецификации, но и увеличивает лимиты,
добавляет полезные свойства. Например, IE8 – единственный, кто может сообщить,
сколько же памяти реально занято данными, другие браузеры этого и близко не
умеют. По спецификации хранилищ может быть два – session, когда данные
актуальные только для текущей вкладки (но при этом можно уходить на другие
сайты, данные сохраняются), и local – уже настоящее постоянное хранилище,
привязанное к домену, где оно было создано (для поддоменов будут свои
хранилища).
Работать с хранилищами данных проще простого – это, по сути, модная нынче
NoSQL база данных. Можно положить (set), получить (get) и удалить (remove)
значение переменной, данные при этом могут быть любыми, главное, чтобы это были
строки или приводимые к ним форматы. Можно также удалить все (clear) и узнать
объем (length). Работа с хранилищем осуществляется так же, как и с обычным хешем
в JavaScript. Например, сохраним список друзей пользователя:
window.localStorage[myfriend] =
JSON.stringify([{name:”Вася”,email:”vasja@xakep.ru”},
{name:”Alex”, email:”aleks@xakep.ru”}]);
На самом деле для реально крутых приложений этого недостаточно. Об этом
хорошо знают и понимают в W3C, поэтому хранению данных уделено столь большое
место в текущей спецификации HTML5. Так, на радость разработчиками, кроме
простого (и тупого) хранения строк, пусть и постоянного, можно надеяться и на
Web SQL Database – попытку предоставить в распоряжение скрипту свою собственную
полноценную SQL базу данных (обычно это SQLite).
Интернет? Нет, оффлайн!
Раньше работать с сайтами было можно, даже не имея доступа в Cеть: открыл
себе нужные страницы и читай, хоть на весь день, отключившись от модема. С
сегодняшними интерактивными сайтами такое уже не получится. Для многих действий
понадобиться устойчивая связь с сервером проекта, ведь ты хочешь мгновенно
видеть, что твои друзья делают рядом. Но ведь случается, что интернет просто
отрубается, верно? Раньше браузер мог даже не заметить кратковременных
отключений, максимум это грозило тем, что не отправляются формы. Современному же
приложению в браузере надо точно знать, есть у него выход в инет или нет. И, как
опытный разработчик, могу тебе сказать: узнать это не так уж и просто. Для
облегчения этой задачи в HTML5 появились новые события – offline/online, которые
оповещают твою программу о перебоях в соединении. Это здорово помогает,
например, при написании текстов – если нет интернета, то вместо отправки
заполненной формы на сервер достаточно воспользоваться одним из предложенных
хранилищ данных (DOM Storage) и сохранить в него все, что ты так кропотливо
набивал, а уже потом, когда появиться доступ в Сеть, отправить это на сервер.
Многие сервисы работы с документами или почтой нуждаются в таком уже сейчас, и
им приходится всячески извращаться, чтобы узнать то, что в HTML5 будет доступно
одной строкой!
document.body.addEventListener("offline",
function ()
{
alert(‘Чувак, звони провайдеру, твоя сетка упала!’));
},
false);
Но что делать, если твой сайт может прекрасно жить и без инета, лишь бы были
те несколько файлов, без которых ну просто никак не обойтись? И это решается.
Достаточно использовать application cache или offline resource. Это механизм,
когда ты в специальном файлике (манифесте) описываешь ссылки на все нужные
странице файлы, необходимые для того, чтобы работать без связи с сервером. Они
автоматически будут загружены и заботливо сохранены браузером, чтобы быть
наготове на случай обрыва связи. В отличие от настроек кэширования, это работает
более гарантированно, и браузер не может пропустить указанный файл — все они в
обязательном порядке будут заблаговременно загружены и сохранены. Уже сейчас это
можно попробовать в Firefox 3.5 и выше.
Web Workers – солнце светит, рабы пашут
В инете просто куча сайтов, на которые заходишь и понимаешь, что можно
выбросить в топку твой 4-х ядерный камень и 8 Гб оперативки – все это сжирает
один сайт! Причиной тормозов часто является Flash, но не он один. Разработчики
знают: JavaScript в браузере не предназначен для серьезных вычислений. Только в
последних версиях браузеры научились выделять скрипты в отдельные потоки (первым
это взял на вооружение Chrome, что позволило ему назваться самым быстрым
браузером на планете). Тем не менее, в рамках страницы все скрипты работают в
одном потоке, даже если процессор может выполнять их несколько одновременно.
Асинхронным, то есть исполняющимся параллельно был и есть только один
специальный системный объект XMLHTTPRequest, который может делать запросы на
сервер, не прерывая основную работу. Но что же делать, если сегодня ты уже
хочешь не просто загружать фото на свою страничку, а требуешь возможности ее
обработать, создавать коллажи или фотожабы, да и просто убрать красные глаза? И
все это на той же страничке, без необходимости отправлять фото на сервер.
Приближая возможности веба к обычным приложениям, следовало развязать руки
разработчикам, дав возможность загрузить клиентскую машину по максимуму. Так
появилась спецификация WebWorkers, впервые реализованная "в коде" еще Google
Gears. По сути, это возможность выделить некоторый участок кода (набор функций),
которые будут исполняться в отдельном фоновом потоке, никак не мешая обработке
основной страницы, не тормозя отрисовку DOM-дерева и другие операции. Конечно,
воркеры имеют множество ограничений (чтобы не наглели). Они не могут обращаться
к переменным основной страницы или к DOM-дереву страницы, не видят ее
переменные. Разрешена только загрузка с удаленных узлов и общение с родительским
процессом, где они были созданы через механизм обмена сообщениями (обычными
строками или JSON-данными). Простой пример:
var worker = new Worker("my_xaking_script.js");
worker.onmessage = function(event)
{
alert(‘Computing finished, result: ‘ + event.data)
};
worker.postMessage("5");
В воркере (файл my_xaking_script.js) может быть любой код JS, не
взаимодействующий с DOM, а чтобы он мог общаться с внешним миром, достаточно
объявить обработчик события onmessage, который срабатывает, когда воркеру
посылают данные для обработки. Результат возвращается через вызов метода
postMessage, который связывает код с основной страницей.
Можно смело возлагать на такой скрипт трудоемкие расчеты, например, в
стратегических или RPG-играх, фоторедакторах и там, где раньше едва справлялся
Flash или просто тупо вис браузер. Спецификация воркеров вышла на удивление
простой и гибкой, да так, что многие серверные приложения взяли ее на
вооружения, реализуя таким образом многопоточность (например, серверный
JavaScript NodeJS).
Плагины для Firefox, которые также могут быть написаны на чистом JS, могут
использовать WebWorker для вынесения ресурсоемких обработок в другой поток. Для
иллюстрации практической пользы от воркеров, легендарный JavaScript-гуру Джон
Резиг, создатель jQuery, портировал из C на JavaScript алгоритм поиска коллизий
в SHA-1 хеше (в рамках конкурса, организованного Ruby-хостером Engine Yard). Сам
код ты сможешь найти на нашем DVD, но
прирост скорости от использования многопоточности в разных браузерах составил от
двух до пяти раз. А это, как мне кажется, очень даже отличный результат.
А может, хватит?
Ты думаешь, на этом нововведения в HTML5 закончились? Нет, там еще много чего
припасено. Например, сейчас во всех браузерах перетаскивание чего-либо мышью (Drag-n-Drop)
приводит к ощутимым тормозам. Особенно этим славится IE (а где ж он не
тормозит-то?), поэтому все сложные веб-сайты с большим количеством информации
работают в страничном интерфейсе, не пытаясь наследовать десктоп с таскающимися
окнами. Разработчики HTML5 обещают, что Drag-n-Drop будет нативный и ускоряться
браузером, поэтому даже с огромным DOM-деревом и кучей CSS-стилей все будет
летать. Вдобавок появится возможность таскать не только элементы в пределах
окна, но и немного выйти за область браузера, разрешив загружать файлы прямым
перетаскиванием прямо с рабочего стола или из другого приложения. Это уже сейчас
можно попробовать в Google Chrome, приложив аттач к письму Gmail с помощью
Drag’n’Drop’а. Вообще, в спецификации обсуждается предоставление большей свободы
в плане работы с локальными данными, например, FileReaderAPI, который позволит
коду напрямую читать файлы с диска юзера (конечно, не все и не везде). И хотя
начальные варианты поддержки уже появились в последних сборках Firefox, это API
до конца не обрело свое место в стандарте.
О революционном решении добавить, наконец, в веб то, чего всегда не хватало –
нативную поддержку WebSockets (двусторонней постоянной связи с сервером, почти
настоящие TCP-сокеты), мы уже рассказывали подробнее в прошлых номерах (статья "Реал-тайм
в Вебе"). На сегодня это одна из самых обсуждаемых фич, которая уже
реализована в последних релизах браузера (кроме злосчастного IE9). И пусть
редакции стандарта на WebSockets могут изменяться и быть порой несовместимыми
между собой, дырявыми в плане безопасности – без сомнения именно они будут
главным локомотивом движения веб-сайтов в сторону приложений.
В истории Сети с середины 90-х годов пытались добавить настоящую 3D-графику
на сайты. Разрабатывались специальные языки (вроде уже умершего VRML),
создавались плагины и библиотеки, начиная от полностью новых (Blink 3D,
Wildtangent) и заканчивая расширениями привычных апплетов Java (Java3D) и Flash.
Ничего не пошло, пока не решили – а зачем вообще что-то придумывать, если все
уже придумано (и украдено) до нас? На том и решили. За основу взяли
индустриальный стандарт OpenGL (его особенно обожает легендарный Джон Кармайк,
создатель Doom и Quake) и портировали с некоторыми изменениями его API прямиком
в JavaScript. Так на свет появилась технология WebGL, которая сейчас лучше всего
поддерживается Chrome. Здесь, как и в canvas-элементе, есть где разгуляться
видеокарте: обещается, что графика будет ускорена по полной программе. Однако
эта часть еще не входит в спецификацию и развивается сторонними компаниями. Но
уже одно обещание единого графического API для работы с настоящим честным 3D и
на любимом JavaScript – это подвиг! А как применить – это мы уже сами придумаем;
будем писать игры, выводить классные графики и диаграммы, рисовать карты. Для
игр, кстати, уже сделали и развивают честный игровой движок CopperLicht.
Как жить дальше?
HTML5 – это определенно будущее интернета. Технологии, которые входят в этот
стандарт, позволяют с легкостью делать на веб-страницах то, что раньше было
доступно только суровым C++ программистам на десктопах. Сразу все, конечно, на
голову не свалится, новые возможности постепенно внедряются в браузеры. Но не
стоит думать, что раз стандарт в далеком будущем, то ничего из его возможностей
нельзя использовать сейчас. Многие браузеры поддерживают новшества HTML5, но вот
только одна засада – каждый норовит реализовать это по-своему.
WWW
Лучший сайт, где собраны разные примеры, учебники и исходники всех фич
HTML5:
www.html5rocks.com3D графика с помощью WebGL:
learningwebgl.com/blogПоддержка HTML5 и CSS 3 в разных браузерах:
www.findmebyip.com/litmusТаблица тегов в HTML5:
www.w3schools.com/html5/html5_reference.aspВведение в WebWorkers:
webo.in/articles/all/2009/25-computing-with-web-workers
