Flash и HTML5 – друзья, а не конкуренты.

Flash и HTML5 рассматривают как конкурирующие платформы. Любители холиваров всегда готовы подробно объяснить, почему одна из них правильная, а другая не имеет права на существование, и должна быть уничтожена. Между тем, эти платформы не совсем конкуренты, и решают довольно разные задачи.

Как это всегда бывает, каждая платформа имеет свои достоинства и недостатки. Интересный момент в том, что в данном случае достоинства одной платформы неплохо компенсируют недостатки другой, и наоборот. Поэтому Flash и HTML5 могут успешно применяться вместе, в одном проекте, и гармонично дополнять друг друга.

Я постараюсь быть беспристрастным, насколько это возможно, при том что я по большей части флэш разработчик :)

Хотел бы отметить такой нюанс: почти все флэш разработчики в какой-то мере имеют дело с HTML и JavaScript, если и не пишут такой код, то понимают, в какой среде работает их приложение. Между тем для большинства JavaScript разработчиков флэш является черным ящиком. Я постараюсь его открыть.

Преимущества HTML5, компенсирующие недостатки Flash

Flash довольно слабо и неэффективно работает с текстом и со сложным форматированием.

Это давняя проблема флэша, его ахиллесова пята, и у вендора никак не получается ее решить. Вот Адоби выпустил Text Layout Framework, который должен решать эту проблему. В принципе решает, но с производительностью дела обстоят неважно. И он не свободен от багов и неприятных побочных эффектов. Из-за чего в некоторых случаях даже приходится от него отказываться, и возвращаться к старым, менее функциональным средствам.

Ну а HTML изначально создавался для работы с текстом. Так что там, где нужно показать больше двух абзацев текста, и отформатировать его более, чем парочкой стилей, предпочтительнее использовать HTML.

Во Flash сложно или невозможно реализовать многие стандартные для браузеров фичи.

Например, ссылку в браузере пользователь может открыть в том же табе, в новом табе или в новом окне по своему желанию. Ссылку во флэше пользователь открывает либо в том же табе, либо в новом табе по желанию программиста (а у программиста, скорее всего, будет желание сделать по второму варианту, ибо первый выгрузит флэш приложение).

Проблема частично решается -- можно добавить соответствующие функции в контекстное меню. Но вот отличить клик средней кнопки мыши от левой кнопки уже нельзя (можно только в AIR). Или нужно искать непростые варианты с привлечением на помощь JavaScript (что плохо скажется на производительности).

Далее, посещенные и не посещенные ссылки в браузере выглядят по разному (если дизайнер не накосячил). Во флэше это реализовать сложно, и опять же, нужно звать на помощь JavaScript.

По наведению мыши на ссылку в браузере пользователь видит в строке статуса, куда она ведет. Флэшу для этого опять нужна помощь JavaScript. Хотя тут есть неплохой вариант -- показать url в tooltip прямо под ссылкой.

Часто бывает необходимо изменить размер шрифта на странице. Размеры и разрешения экранов сейчас отличаются большим разнообразием, так что дефолтный размер может не устраивать. Эта возможность есть в любом браузере. А в случае флэш приложения об этом должен позаботиться программист.

История посещений, кнопки "вперед" и "назад" браузера. Это тоже, в принципе, решается, но опять ценой дополнительных усилий программиста и с привлечением JavaScript.

Непонятно, как поисковики индексируют контент внутри флэша.

Теоретически гугл индексирует содержимое swf файлов. Вроде бы как есть специальная консольная версия флэш плеера, которая позволяет гуглботу интерпретировать swf файлы, и даже как-то имитировать действия пользователя -- нажимать кнопки и т.д.

Практически же непонятно, что именно в swf файле видно гуглботу, а что нет. Есть подозрение, что виден статический контент, вкомпилированный внутрь swf, но не виден (или не всегда виден) контент динамический, который подгружается в рантайме. А именно он и важен.

Требователен к ресурсам, плохо подходит для мобильных платформ

Да, сейчас Адоби сосредоточилась на этом направлении и прилагает серьезные усилия. Но у меня складывается впечатление, что разработчики под мобильные платформы пока предпочитают нативные технологии.

Преимущества Flash, компенсирующие недостатки HTML5

Постоянное соединение с TCP сокетом, push данных со стороны сервера

Специфика протокола HTTP, построенного по принципу запрос-ответ, где сервер не может активно передать данные клиенту, без запроса клиента, не всегда удобна. В ряде случаев бывает необходимо, чтобы сервер активно отдавал данные.

Есть разные способы это обойти: http streaming, long polling, частые запросы со стороны клиента. Но все они дают избыточную нагрузку на сервер.

Есть технология Web Sockets, но она пока не очень хорошо поддерживается браузерами.

Между тем во флэше такое соединение создается легко и работает эффективно. Есть свой бинарный протокол RTMP, созданный для передачи больших объемов данных (медиа контента), есть своя эффективная сериализация данных -- AMF. Есть ряд серверов, поддерживающих RTMP и AMF, как от Adobe (Flash Media Server, LiveCycle Data Services, ColdFusion), так и от сторонних вендоров (Wowza Media Server, Erlyvideo, haXe Remoting, WebORB и др.).

Конечно, ничто не мешает реализовать другой протокол и другую сериализацию, и даже придумать свои.

Больше возможностей работы с медиа контентом

Передача медиа контента по протоколу RTMP более эффективна, чем по HTTP: меньше траффик, более эффективно расходуются ресурсы сервера, возможно публиковать и получать видео в реальном времени, записывать видео на клиенте и сохранять его в файл на сервере.

По этой теме я подробно рассказывал в своем докладе Видео в интернете, кратко обо всем на 11-й конференции BAFPUG.

Возможности HTML5 по работе с видео развиваются, но еще далеки до возможностей Flash. И имеются некоторые врожденные проблемы с кодеками и лицензиями, которые сложно будет преодолеть. Идеологические разногласия по этим вопросом значительно осложняют развитие HTML5.

Кроссбраузерность, нет зависимости от конкретного браузера

Ну это давняя проблема при использовании HTML, CSS, JavaScript. Браузеры каждый по своему понимают этот код, особенно своенравен один браузер, сами знаете, какой.

Да, разработчики научились решать эти проблемы, и обычно удается написать кроссбраузерный код. Но это стоит времени и усилий.

Признаться, у флэш плеера тоже есть некоторые нюансы поведения в разных браузерах, но они редки и бывают в очень специфичных ситуациях. Обычно флэш разработчику не приходится заботится о таких проблемах, а значит он делает свою работу быстрее.

Взаимодействие между html-страницами находящихся в разных табах (или разных окнах) браузера

Иногда бывает необходимо синхронизировать информацию между несколькими HTML страницами, открытыми в разных табах или окнах браузера. Для JavaScript разработчика это можно сделать только через сервер, что приводит к задержкам и повышенной нагрузке на сервер. Скорее всего JavaScript разработчик даже не будет ставит себе такую задачу.

При использовании флэш эта задача решаема. Несколько флэш приложений могут взаимодействовать с помощью LocalConnection и передавать друг другу информацию, независимо от того, где они находятся -- на одной странице, на разных, или вообще в stand alone флэш плеере.

Примеры удачных проектов

Давайте глянем на некоторые примеры удачных Flash и HTML проектов.

acrobat.com -- сервис веб-конференций от компании Adobe. Проект такого рода в принципе невозможно создать без флэш технологии. Между тем, и без HTML этот проект не может обойтись :)

Big Blue Button -- e-learning сервис для удаленного обучения студентов. Это open source проект, опирающийся на ряд open source технологий, в т.ч. Red5.

gmail.com, docs.google.com и другие сервисы Гугл примечательны тем, что сделаны на HTML + JavaScript, тогда как проекты такого рода было бы проще сделать с помощью флэш. Тут потребовался немалый инженерный талант ( который у Гугла таки есть :)

xd.adobe.com -- противоположный пример, тут типичный контентный проект (коллективный блог), построен на flex, тогда как было бы гораздо проще и эффективнее делать это на HTML. Но кому, как не Adobe демонстрировать возможности flex таким образом :)

Moto CMS еще один нетривиальный пример применения флэш -- CMS для флэш сайтов. Что ж, создать такой продукт было сложно, разработчиком пришлось решить немало нетривиальных проблем. Но у них получилось :)

Пример архитектуры проекта

Возмем пример проекта, сочетающего возможности Flash и HTML5, и рассмотрим, из каких частей он может состоять, и как эти части могут взаимодействовать.

Итак, у нас есть серверный слой, включающий веб-сервер (apache, ngnix и др.), сервер реального времени (FMS, Wowza, LCDS, ColdFusion, свой кастомный сервер и т.д.), и база данных (MySQL, PostreSQL, Oracle и т.д.)

И есть клиентский слой, включающий несколько HTML страниц, JavaScript код в них и несколько swf файлов.

1) флэш приложение может получить входящие параметры с HTML страницы;

2) флэш приложение может общаться с другим флэш приложением через LocalConnection;

3) даже если другое флэш приложение находится в другом табе браузера;

4) флэш приложение может общаться с JavaScript кодом (ExternalInterface, JSInterface);

5) JavaScript может общаться с веб сервером по HTTP;

6) флэш приложение тоже может так :)

7) флэш приложение может общаться с сервером реального времени через постоянное соединение;

8) сервер реального времени может общаться с веб-сервером (HTTP запросы, XML, SOAP и т.д.)

9) веб-сервер может общаться с базой данных;

10) сервер реального времени тоже может :)

Все рассмотренные элементы и взаимодействия между ними мы реально используем в своих проектах :)

Проекты, где можно с пользой сочетать Flash и HTML

• Проекты, где важно получать данные с сервера с минимальной задержкой:
  • chat;
  • instant messaging;
  • whiteboard;
  • одновременная коллективная работа над документом;
  • e-learning;
  • софт для торговли на бирже;
  • софт для мониторинга состояния чего-либо;
• Проекты, связанные с публикацией и получением видео и аудио:
  • видеочат;
  • IP телефония;
  • сервисы просмотра видео (youtube);
• Браузерные многопользовательские игры.