Flash и javascript – JavaScript, AJAX, Socket и Flash/ActionScript — исследуем вопрос передачи данных в AJAX-приложениях / Habr

Flash vs JavaScript / Habr

Здравствуйте, я разработчик игр на Flash. Последнее время все больше стало появляться постов про флешокапец, и MustHave JavaScript (дальше JS). Вроде как за JS будущие, и за открытым вебом.
Я долго не рассматривал JS всерьез как платформу для разработки игр. Ведь это интерпретированный язык, и скорость JS оставляет желать лучшего. Но совсем недавно был портирован на JS мой любимый фреймворк для анимации TweenLite. Вместе с этим автор создал тестовый пример показывающий производительность актуальных JS фреймворков: здесь.

Мне стало очень интересно, так как TweenLite JS выдавал неплохие FPS. И тут я решил написать такой же пример для сравнения Flash и JS фреймворков.
Дальше мне стало интересно сравнить FPS этих примеров в разных браузерах, и на разных ОС.
Сам тест — это анимация передвижения, и изменения размеров картинок, при чем можно изменять их количество. Тестовый пример для Flash лежит здесь, исходники примера здесь.

Тестирование проводилось на моем старом ноутбуке HP Compaq 625:

Железо:
AMD Turion II Dual-Core P520 (2.3 ГГц), RAM 2 ГБ, ATI Radeon HD 4200.

Операционные системы:
Windows 7 x32, Linux Mint 13 x32

Браузеры и Flash Player:
Google Chrome 21.0.1180 (Flash Player 11.3.31), FireFox 15.0.1 (Flash Player 11.4.402 for Windows, FP 11.2.202 for Linux), Interrnet Explorer 9.0.8112 (Flash Player 11.4.402)

Хочу сказать что Flash Player на Firefox-е был установлен разных версий под разные ОС, потому как официальная поддержка от Adobe на Linux уже закончилась, будут доступны только обновления безопасности для ветки 11.2. В отличии от Firefox, в Google Chrome Flash Player работает через новый межплатформенный API для плагинов Pepper API, и поэтому он обновляется до последней версии.

Итак, посмотрим, что получилось:

Тест №1:

Frames Per Second (Chrome 21.0.1180, Flash Player 11.3.31, Windows 7 x32)
Frameworks\Tests	TweenLite (AS)	tweener (AS)	GTween (AS)	jQuery (JS)	TweenLite (JS)	YUI3 (JS)	MooTools (JS)	Dojo (JS)	TweenJS (JS)	Zepto (JS)
500	60	60	60	16	60	6	12	22	17	47
1000	60	41	60	1	51	1	5	5	2	28
3000	21	6	19	1	16	1	1	1	1	5

Здесь проводилось три теста, для 500, 1000 и 3000 тысяч картинок. Как видим большой отрыв Flash фреймворков и TweenLite JS, при 3000 картинок он обогнал даже флешовский tweener. Хорошо показал себя zepto, а вот всеми любимый jQuery для анимации подходит весьма плохо. Можно сделать вывод, что если такими темпами и дальше пойдет развитие то в JS есть все шансы стать достойной заменой Flash.

Дальше, мне стало интересно как колеблется производительность на разных браузерах и на разных операционных системах. Ведь flash player разрабатывается одной канторой, и сильных отклонений в производительности быть не должно. А движок JS пишется под каждый отдельный браузер, совершенно разными людьми (велоэффект). Поэтому давайте посмотрим на результат.

Как видим хотя flash player один и тот же, но ведет себя в разных браузерах по разному, это скорее из за того что использует разные API при взаимодействии с браузерами. Самым неудачным плагин FP получился для Internet Explorer.

Теперь рассмотрим тест на производительность браузерных движков JavaScript. Здесь тест проводился на 500 картинок, потому как при 3000-и многие фреймворки просто зависают.

Самым быстрым оказался Google Chrome, что не удивительно, смотря на то сколько денег инвестирует в него Google. Дальше Firefox возможно ситуация изменится при внедрении нового инкрементного сборщика мусора.И в конце Internet Explorer. Разрыв между первым и последним просто колоссальный. Представляете вы написали игру на JS, и она у вас хорошо работает в Chrome, Firefox, но тут кто то зашел из IE, можно представить что будет дальше, IE зависнет и скорее всего впадет а вместе с ним очень много открытых вкладок. Как результат юзер добавит ваш сайт в черный список. Была бы игра на flash такого бы не случилось.

Раз такой достаточно большой разброс производительности Flash Player на разных браузерах, давайте теперь посмотрим как она будет изменяться на разных ОС в одном и том же браузере:

Печальная картина, но видать в виду малого распространения Linux, Adobe халатно относятся к оптимизации их плеера на этой ОС. Результаты Firefox выкладывать не буду, потому как считаю нечестным сравнивать flash player 11.4 и 11.2, а на самом деле разница чутли не в два раза.

Идем дальше, как ведет себя JS движок на разных ОС?

Как видим Chrome идет практически одинаково что не может не радовать, а вот у Firefox, Linux версия заметно отстает.

Заключение:

Как видим производительность JavaScript растет, это радует. Но остается немало проблем:

• Нужно тестить как будет вести себя игра во всех браузерах, и надеяться что при выходе нового IE дай Бог ничего не отвалилось.
• Разница у производительности браузеров, будет давать неприятный эффект, на одних игра летает на других тормозит.
• Исходный код скрыть не удастся разве что сильно обфусцировать.

Какие еще проблемы ждут при разработке клиентской части игры на JavaScript и как их можно решить?

Smokescreen — «Flash-плеер, написанный на Javascript» / Habr

Увидел недавно топик-ссылку Smokescreen — конвертер flash в html5\js, решил сделать перевод той информации, которую я уже читал в сети про этот новый инструмент. Если коротко: Smokescreen — новый проект с открытыми исходниками, направленный на преобразование Flash в JavaScript/HTML5 для лучшего взаимодействовия с веб-страницей там, где раньше это было невозможно.
С его помощью вы можете расширить поддержку своего проекта на новые платформы без изучения новых инструментов, Flash автоматически преобразуется в JavaScript/HTML5. Smokescreen будет выпущен под open source лицензией и будет распространяться бесплатно. Стоимость поддержки и обслуживания будет низкой, чтобы вы могли убедиться, что Smokescreen работает именно так, как вам необходимо. Библиотека даст вам широкий выбор инструментов для разработки, включая разработку на JavaScript, без использования ActionScript, и разработку с подключением Flash к HTML-страницам проекта.

Описание проекта от авторов

Вы, вероятно, знакомы с тем, что Adobe Flash не работает на любом мобильном устройстве Apple. Более того, похоже, что Apple никогда не разрешит запуск Flash на iPhone/iPod/iPad.

Эти факты рисуют мрачную картину для интернет-рекламы на мобильных устройствах. Многие люди все еще хотят использовать существующие инструменты Adobe для создания рекламы, и замена этих инструментов иными ради одной единственной платформы (iPhone/IPod/iPad) выглядит глупо. Как рекламная сеть, мы считаем, что интерактивная реклама более привлекательна, чем скучные статические объявления, поэтому нам пришлось выбирать один из вариантов: жить в темноте, в пустынном мире скучных мобильных объявлений или что-то делать.
Мы направляем все усилия Smokescreen там в качестве предварительного прямо сейчас. В будущем мы рассчитываем добавить поддержку большего числа возможностей Flash, исправить ошибки и повысить производительность. Это только начало. Smokescreen в настоящее время поддерживает значительное возможностей анимации Flash 8, потокового звука, звуковые эффекты, некоторые возможности ввода и базовый ActionScript.

Принцип работы библиотеки

Smokescreen Криса Смоака (Chris Smoak), «флэш-плеер написанный на JavaScript», это невероятная вещь. Он работает полностью в окне браузера, считывает файлы SWF, распаковывает их (с помощью чистого JS), извлекает изображения и встроенные аудио-файлы, упаковывает их с помощью base64 и вставляет в HTML-страницу как data:uri, векторная графика собирается в анимированный SVG. В отладчике (Chrome Web Inspector) вы можете увидеть, как SVG изменяется в реальном времени во время проигрывания демо. Smokescreen даже реализует собственный интерпретатор байт-кода ActionScript. […] Единственное, что меня беспокоит, это производительность библиотеки — она имеет объем 175 KB и более 8000 строк кода, что может привести к проблемам на маломощных мобильных устройствах.

Демо, демонстрирующие работу библиотеки

Демо показывают Smokescreen в действии. Демо без звука сравниваются с их Flash-вариантами на той же странице. Поскольку Smokescreen написан на JavaScript, он работает медленнее, чем Flash-плагин, скорость ограничивается производительностю браузера. Пока мы не применим больше трюков для увеличения скорости, некоторые демо не будут работать с удовлетворительной скоростью на iPad/iPhone/iPod.

Используйте последнюю версию браузера. Smokescreen в настоящее время работает в Firefox 3.6, Chrome 5, Safari 4, и MobileSafari. Существуют известные проблемы с Opera 10.5 оперы, которые будут исправлены. Не работает в IE, несмотря на то, что IE9 выглядит многообещающе.

Анимационные ролики формата swf, отображаемые с помощью Smokescreen

Демо для платформ Win, Mac, и Linux

Анимационные баннеры

Демо для Win, Mac, Linux, iPad, iPhone, и iPod)

Демо для Win, Mac, Linux, и iPad

Видео работы Smokescreen на iPad

http://vimeo.com/moogaloop.swf?clip_id=12014368&server=vimeo.com&show_title=1&show_byline=1&show_portrait=0&color=&fullscreen=1

Ссылки

При подготовке статьи использовались следующие ресурсы:

Для желающих попробовать

Поскольку официально библиотека еще не представлена, ссылок на нее нет (анонсирован только пре-релиз). В будущем, как отмечалось выше, библиотека будет доступна под open source лицензией. Для ознакомительных целей можно воспользоваться репозиторием Саймона Виллисона, который выложил код библиотеки с пометкой:

Я выложил не сжатую версию (использовалась команда TextMate Bundles -> JavaScript -> Reformat Selection) здесь: http://gist.github.com/418177

Только для ознакомительных целей — код библиотеки еще не является открытым.

JavaScript и Flash — что лучше

Извечный вопрос сферы программирования не только в WordPress, но и области веб-разработки в целом. Существует много популярных платформ, технологий для реализации программных продуктов. Большая часть из них являются приложениями, к каковым относятся расширения. Также вордпрессовцам нередко требуются панели с уникальным набором функций. Как уже было сказано, для их создания предусмотрено много средств. Flash и JavaScript занимают среди них особое место. Им отдает предпочтение большинство веб-специалистов. Но вот вопрос – когда и что лучше использовать. В интернете ответа не нашлось. Многие склоняются к мысли, что все зависит от конкретного случая, и каждый выбирает сам. Мы считаем по-другому: если относятся к одной категории, значит разница есть. В этой статье постараемся найти истину, дать четкий ответ на вопрос, что же лучше – Flash или JavaScript.

Что такое Flash

Обе технологии широко востребован в сфере веб-разработки. Они пригодны для разных целей, из-за чего и получили свою популярность. Для новичков – это темный лес. Чтобы устранить данный пробел, прямо сейчас разберемся в сути и особенностях Flash и JS. Первая представляет собой специализированное кодирование для мультимедийного контента. Технология Flash знакома каждому активному и не очень пользователю ПК. Почему? Тотальное большинство современных интернет-пользователей любит смотреть видео, использует приложения, некоторые даже до сих пор балуются браузерными флеш-играми. Любое развлечение из перечисленных станет недоступным, если на компьютере не установлен Flash-плеер. Интересно, что 98% людей не подозревают о его существовании на своем устройстве. Считаем, что причина кроется в отсутствии необходимости его ручной установки. Флеш появилась давно, однако, по сей день работа с мультимедийной информацией в сети без нее невозможна. Авторы программного обеспечения, к примеру, браузера Google Chrome, добавляют соответствующий плеер в качестве дополнительного пакета в своей продукт по умолчанию. Интернет-аудитория буквально сидит на флеш-технологии, но даже не замечает этого.

Интересна история появления, развития Flash. Сегодня технология известна под брендом Adobe. Мало кто знает, что ранее авторские права принадлежали другому разработчику – фирме Macromedia. Именно она загорелась идеей тотального пользования мультимедиа в интернете, на 90% реализовала ее. Далее случилось неизбежное: крупный игрок рынка Adobe Systems поглотила конкурента вместе с его продуктами. Грустная, но типичная история тогдашнего времени. Однако не известно, чем бы все закончилось, если бы технология не попала в руки топового разработчика программного обеспечения. Специалисты Adobe Systems довели флеш до ума, положили в красивую упаковку, сделали продукт общедоступным. Благодаря своевременному инвестированию проекта, для просмотра, обмена, отправки видео, аудио, анимации, игр, презентаций и прочей мультимедиа достаточно установки одной утилиты. К слову, Flash имеет вес в рекламном бизнесе. Многие из современных баннеров реализованы на базе данной веб-технологии. У нее есть масса преимуществ и недостатков. Подробно познакомимся с ними чуть позже.

В WordPress флеш встречается реже JS. Авторы CMS отдали предпочтения продвинутым языкам программирования, выступающим в качестве аналога. Это сложнее, но универсальнее. Однако, когда вопрос касается, скажем, вставки видео в запись или на страницу, без Flash дело не обходится. Соответствующие файлы системы имеют расширение .swf (он же Small Web Format). Существуют и другие, но их в «ВордПресс» не используют. Не так давно добавление соответствующего набора файлов в CMS было проблемой. Сегодня для данной цели существует разнообразие плагинов от ведущих разработчиков: от простых инструментов до комплексных решений с гибкой настройкой. Сама система управления контентом «ВордПресс» не адаптирована под чтение формата .swf. Специальные дополнения дают ей такую возможность, а также позволяют редактировать флеш-файлы. Это удобнее в ряде ситуаций.

Что такое JavaScript

JS – язык программирование, поддерживающий объектно-ориентированные, императивные и функциональные конструкции. Опцион JavaScript представляется больше, чем у оппонента. Не путайте данную технологию кодирования с Java. Последняя была популярна около 10 лет назад в разработке утилит, игр для мобильных устройств. Технология JavaScript – это совершенно другой продукт. Она также позволяет создавать современные интерактивные приложения. В сети ее задача сводится к созданию отдельных элементов, конструкций либо полноценных страниц с высокой иерархией. Проще говоря, дизайн свежее, структура функциональнее, поддержка и опции глобальные. Большим преимуществом JS является тесная связь с HTML, CSS-стилями. Интерактивные элементы в несколько раз повышают интерес пользователя к сайту – это факт. Сам код HTML не дает глобальных возможностей. Он нуждается в доработке, путь к которой открывает JavaScript. Параллельно JS выступает в роли пользовательского клиента, формируя запросы, отображая контент по отклику сервера. Представленной информации недостаточно для общего понимания сути JavaScript. Рассмотрим основные функции технологии:

• создание диалоговых окон – статичных и всплывающих;
• редактирование HTML через элементы HTML dom;
• построение форм для обратной связи с гостями ресурса;
• создание панели входа/регистрации, блоков поиска, комментариев;
• удобный инструмент правки макета страницы, общего повышения его качества;
• скрытие/раскрытие информации;
• хранение IP-адресов для безопасной автоподстановки данных;
• возможность загрузки только части интерактивного контента;
• проверка алгоритмов браузера;
• наличие базы данных (БД) mongodb для приема запросов;
• возможность использования для скриптов благодаря поддержке формата .org;
• глобальная поддержка сторонних языков программирования, технологий и приложений.

Работа с мультимедиа не входит в перечень основного назначения JS. Однако технология для этого пригодна и активно используется. Получаем универсальным инструмент для создания, настройки интерактивного контента на сайте. Складывается впечатление, что между Flash и JavaScript нет прямой связи. Давайте разбираться. Оба представлены кодом, заключенным в файлы определенного формата. Второе сходство – функция добавления, редактирования мультимедийного контента. Отличие кроется в подходе к решению задач. Технология флеш широко распространена, но слегка устарела. JavaScript профи называют будущим веб-разработки, так как она предлагает расширенные возможности, работает не только с мультимедийными файлами. Так ли это на самом деле, разберемся далее.

Плюсы и минусы Flash

Давайте копнем глубже обыденного представление о данной веб-технологии как простом инструменте для работы с мультимедиа. В ее основе лежит масса сложных компонентов. Одним из них является векторная графика, без которой невозможно создать анимированный объект. Она также обеспечивает малый файловый вес, качественную картинку даже на больших экранах. В свою очередь, векторная графика основана на морфинге: алгоритме, превращающем набор картинок в анимацию. Последняя редко выступает как конечный вариант в рамках тех же плагинов. Чтобы превратить анимированный объект в полноценный мультимедийный, в дело вступают интерактивные алгоритмы. Они и доводят набор изображений до конечного файла .swf. При этом используется язык программирования ActionScript. По факту, именно он стал конкурентом JS. Из выше представленного делаем вывод, что флеш отличается следующими преимуществами:

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

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

1. Необходимость установки специальной программы, расширения. Такова цена поддержки файлов .swf и аналогичных. При этом контент отображается только при наличии последней версии. Мобильной адаптации у технологии нет. В случае с WordPress, все немного позитивнее. Веб-мастера разрабатывают плагины отдельных Flash-элементов, которые отличаются адаптивным дизайном. Но если на ПК не обнаружится последней версии дополнения, ничего работать не будет.
2. Серьезная нагрузка на процессор, оперативную память.
3. Требует хорошего и стабильного интернет-соединения для нормальной работы.
4. Сохранение в кэш проходит со скрипом.
5. Слабая защита. Эта проблема преследует технологию с момента ее появления. Решения у нее нет: архитектура такова, что лечение одной дыры открывает новую. Хакеры раскрутили данный недостаток на полную. Особенно пользователям запомнился 2015 год, когда наплыв атак вынудил Firefox и Chrome на время отказаться от поддержки Flash.
6. Необходимость адаптации под индексацию. Стандартный вариант подразумевает вывод в карту только заголовка. К расширениям WP это не относится.
7. Apple более не поддерживает флеш-технологию.

Оценить перевес недостатков можно визуально. В итоге, получаем простую веб-технологию, которая отличается слабой безопасностью, не поддерживается устройствами от компании Apple. Это касается смартфонов, планшетов, ноутбуков. Согласитесь, перспектива так себе. Что же предлагает JS?

Плюсы и минусы JavaScript

Данная технология имеет иной принцип действия. JS обходится без сторонних расширений. Алгоритмы обработки зашиваются в сам сайт, а не браузер. В основе лежит та же векторная графика. Двухмерное кодирование осуществляется через HTML посредством особого тега. Для управления им используется скрипт, который можно прописать в этом же либо отдельном документе типа .js. В результате, интерактивные компоненты загружаются по прямому запросу с самого сайта. Это положительно сказывается на скорости загрузки, не требует дополнительного ПО, подходит для мобильных устройств. Вот полный список достоинств JavaScript:

• простой язык кодирования. Для работы с JS нужны минимальные навыки. Справится даже малоопытный пользователь;
• поддерживается актуальными версиями браузеров;
• прямая связь с HTML и CSS. Избавляет от правок в отдельных файлах. Изменения прописываются в скрипте;
• доступно клиентское и серверное программирование.

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

1. Отсутствует простой, рациональный способ добавления мультимедиа на сайт.
2. Открытый код, что позволяет злоумышленникам изучить исполнительный алгоритм, быстро адаптировать под него различные вирусы.
3. Творческие порывы новичков ломают стандарты оформления кода. Часто понять, что прописано, может только автор.

Ядром обеих веб-технологий является ECMAScript. Он выступает в качестве основного компонента. Долгое время пара файла .swf показывала ним куда большую эффективность. Внедрение в ECMAScript HTML-тега canvas в корне изменила ситуацию. Возможности JS существенно расширились. Начинающие программисты и профи регулярно публикуют новые идеи, которые стали основным источником модернизации JavaScript. Несмотря на ряд затруднений, он остается лучшим способом для добавления интерактива на веб-сайт. Открытый исходный код – источник инноваций. Ряд компаний работает над расширением возможностей JS-технологии, но большая их часть не доходит до рядового пользователя. Причина кроется в жесткой конкуренции таких организаций: здесь любая наработка на особом счету. Остается уповать на мировое сообщество разработчиков. Нужно сказать, оно хорошо справляется с задачей.

Вывод

JavaScript лидирует в гонке веб-технологий. На сегодняшний день, JS лучше Flash практически во всем. Единственным достоинством флеш остается простота добавления интерактивных компонентов в файл. Безопасность, производительность, необходимые условия, поддержка сторонних компаний – она проигрывает по каждому пункту. Но та решила история. ECMAScript изначально лег в основу эти веб-технологий. Во Flash специалисты увидели ряд классных решений в конце 90-х. Он стал востребован, получил широкое распространение, дал старт целой эре программных решений. Удержать лидирующие позиции ему не дали… рядовые пользователи. JavaScript имел открытый код, что способствовало его повсеместной модернизации. Со временем, частные разработчики реализовали в JS все функции Flash, а затем и добавили большой набор новых функций. В итоге, на вопрос, что лучше – JavaScript или Flash, – дает однозначный ответ – JS. Его отличают большие возможности, безостановочная модернизация, всеобщая доступность.

Flash vs Javascript. Размышления о Web-приложениях. / Habr

Совсем недавно в разработке проекта перед моей командой встала задача реализации интернет приложения в котором один его компонент не должен перезагружаться при переходе с одной страницы на другую. Варианта нашлось 2 либо делать полностью Flash приложение, либо использовать внедрение методами iframe или object. Flash отпал ввиду технических требований портирования проекта на портативные устройства, посему остался JavaScript и object. В итоге мы остановились на схеме:
Контейнер и два вложенных в него объекта. Предварительное тестирование структура прошла и мы принялись за реализацию но

Глава 1. AJAX против браузерной системы навигации.

Пока разработчки браузеров не осознали что сайты уже давно перестали быть набором html страниц, и все больше и больше становятся похожи на приложения, перед нами (веб-разработчиками) стоит сложная задача о корректном функционировании кнопок вперед-назад при частичном обновлении контента.
Наща задача еще более осложнена тем, что фактически обновляемая страница (контент) вложена в контейнер и даже полном обновлении страницы контента, адресная строка не меняется. А это лишает пользователя привычным способом возможности получить прямую ссылку на контент внутри сайта. Под привычным способом я подразумеваю копирование адреса из адресной строки.
Когда список проблем был очерчен мы стали искать решения. И оно было найдено в window.location.hash. Я вспомнил что видел как на одном сайте его зачем-то меняли методами JS, но не придал этому значения. Позже когда я делал поиск на своем проекте я наконец-то понял, что в хэш можно просто писать ту самую часть ссылки, которая обычно идет за именем домена/. И именно так мы и сделали.
Решение проблемы с актуальной адресной строкой породило другую. Перестали работать кнопки «Вперед»-«Назад», потому как в единственное, что менялось в адресной строке — это hash. То есть фактически переход по history происходил, но браузер видя что URL не изменился не перегружал страницу контента. Пришлось вешать таймер, который раз в пол-секунды опрашивал адресную строку на предмет изменения и, если такое происходило, то перегружал контент. Путем шаманства и JS-кунг-фу было достигнута работоспособность во всех популярных браузерах.

Глава 2. IE опять опускает с небес на землю.

В процессе решения проблемы с навигацией, мы распрощались с XHTML-валидной вёрсткой. Потому как тег object, который мы так удачно заюзали вместо deprecated iframe напрочь отказался давать доступ к своему parent window. Потратив много времени на шаманство мы простились с валидатором и вставили iframe. Помимо этого IE дал прикурить и просраться на тему прозрачных PNG, вставки Flash и экспорта его методов в JS. Но это мелочи, которые известны многим и широко освещены в интернете, поэтому я не буду заострять ваше внимание на них.

Кстати, SWFObject не проходит валидацию.

Глава 3. А вот и Flash

Отказаться от использования Flash мы изначально не могли. Тогда бы у нас не было аудиопроигрывателя и многопоточного загрузчика. Но вместо того, чтобы делать визуальные элементы на Flash мы сделали тонкие модули без интерфейса выделив каждому жилплощадь в размере 1х1 пиксель. Если делать их бомжами, то они в знак протеста перестают экспортировать свои методы в JS. Мы приняли решение поместить все модули в контейнер и это позволило нам сделать фоновую загрузку. То есть можно поставить на закачку файлы и уйти со страницы загрузки, потом вернуться на нее, а файлы продолжают закачиваться. (Данный режим ещё не включён в официальный релиз, так как мы не уверены в его стабильности.) Ко всему прочему сделав тонкие модули мы минимизировали количество стыков JSFlash и тем самым повысили отказоустойчивость всей системы. Но тут Safari сказало свое решительное НЕТ. Дело в том, что по непонятным причинам JS не может дернуть Flash за его экспортированные методы, если они находятся в разных фреймах. К счастью после каникул у нас в офисе появится MacBook для производственных целей и поборем этот браузер.

Глава 4. Сегодня я многое понял.

Самое первое что выяснилось — это то, что нет идеального браузера, все «ломаются» когда начинаешь гонять на них по бездорожью на предельной скорости. Особо порадовал IE с PNG, Opera с тем что при изменении Opacity она упрямо накладывает ее на все внутренние элементы блока, из-за чего эффект растворения начинает тормозить, и конечно же FireFox, который при обработке JS «переключается как бабушка». Особо это касается анимации.

Вместо заключения.

Внимательный читатель спросит меня: «Какое отношение имеет заголовок к содержанию?».
Сейчас каникулы, и есть время подумать. Вот я сижу и думаю не было бы проще все-таки сделать сайт на Flash. Не смотря на все прелести, которые предоставляет HTML+JS.

Как перестать беспокоиться и начать жить без Flash / Habr

В этой статье — небольшая мотивационная часть и рабочий сценарий, как полноценно жить в сети без Flash-плагина

Сценарий будет состоять из трёх рецептов:

• Рецепт для сайтов, замечающих Flash через feature detection.
• Рецепт для сайтов, которые обращают внимание на User agent.
• Рецепт для сайтов, которые просто всегда дают Flash.
• + Запасной вариант на случай, если Flash понадобится.

Советы будут снабжаться примерами для Safari и Firefox.
Если вы полностью довольны Flash, не беспокоитесь и не планируете от него отказываться — это практическое руководство вам будет не интересно
Зачем вообще отказываться от Flash?

• Потому что на смену ему пришли новые технологии, которые решают те же задачи лучше, которые используются в новых проектах и стартапах.
• Потому что на большинстве из тех сайтов, где вы видите Flash, эти технологии уже лежат в запасниках, и вам давно подготовлен Flash-free experience.
• Потому что Flash имеет множество проблем. Основные проблемы решить невозможно — они заложены в его архитектуру. Хороший список проблем есть в английской Википедии.
• Потому что все авторитетные стороны, связанные с Flash, говорят о том, что Flash пора выбросить¹.

Об этом поподробнее:

• Google говорит: «Откажитесь от плагинов». «Операции, которые раньше требовали использования плагинов, теперь можно выполнять с помощью веб-технологий»
• Mozilla борется с Flash; вспоминает, что Flash — основная причина падений Firefox и говорит: «Плагины — это унаследованная технология, не доступная на большинстве мобильных устройств. Mozilla советует веб-разработчикам всеми способами избегать плагинов. Если у вас есть функциональность, которую не удаётся создать без плагина, обратитесь к нам»
• Apple в 2010 опубликовала прекрасное письмо «Thoughts on Flash», а в английской Вики есть отличный разбор мнений об этом письме и ситуации в целом.
• Electronic Frontier Foundation часто пишет о том, что Flash — это плохо
• Adobe в 2011 свернула поддержку Flash Player на всех ОС и платформах, кроме Wintel и Mac OS X. В своём письме они сказали: «…HTML5 — лучшее решение для создания материалов для мобильных платформ.»
• Даже рекламщики, а именно — IAB, их главный профсоюз — сказали в 2010: «Рекламодателям просто пора делать баннеры на HTML5, а не на Flash. Многие бренды уже сделали так для iPad, и их результаты радуют»

А, может, альтернативный Flash-плеер?

Если вы решите использовать альтернативный Flash-player (список-музей которых есть в той же Википедии), то вы ничего хорошего не получите. Все плееры полумертвы, поддерживают только часть возможностей Flash, тормозят, сбоят, и — в целом — малопригодны. Была надежда на Mozilla Shumway, но и она тихонько тает.
Главное же — альтернативный Flash player не решит основную проблему: в интернетах вам регулярно подсовывают SWF-файлы вместо полезного содержимого.

А решается проблема просто:

Удивительно, но многие сайты показывают вам Flash-содержимое … потому что у вас есть Flash!

Однажды вы задумались о жизни без него и блокировали его Flashblock-ом, а он продолжал быть в системе, и сайты всё так же давали вам всякие embed-ы и object-ы, которые Flashblock и блокировал. Это похоже на анекдот про обезьяну, которая таксиста обманула: мы попросили Flash-содержимое, а, когда оно пришло — заблокировали.

Конечно, это полная фигня. Отключите Flash-декодер. Ещё лучше — удалите его полностью. Тут-то окажется, что часто он не был нужен.

Иногда, впрочем, сайтам надо помочь

А как быть с Youtube-видео, вставленным много лет назад на сторонние сайты через embed или object? Воспользуйтесь расширениями и Userscript-ами.
Например, ClickToPlugin для Safari знает в лицо пол-сотни object-ов и умеет заменять их на HTML5-эквивалент².

Кто никогда не касался Flash, как гордый стриж никогда не касался земли? Конечно, iPhone и iPad.
Смените себе User agent на Safari @ iPad, и многие, очень многие сайты чудесно заработают.

Выберите в меню разработчика³ Safari «Маскироваться под Internet Explorer» Разработка → Пользовательский агент → Safari iOS — iPad. Настройка применится для выбранной вкладки, она перезагрузится, и сервер выдаст вам версию для планшетов, функционирующую без Flash. Проделывать это, к сожалению, придётся каждый раз при посещении сайта, потому что в Safari нет автоматических способов сменить User agent.

Если у вас Firefox, вам повезло больше. Расширение UAControl позволяет выбирать User agent для каждого сайта. Откройте негодный сайт, ткните по кнопке UAControl → UAControl options for this site… → Action: Custom и вставьте в поле Custom user agent строчку от Safari iOS 8.1 на iPad:

Mozilla/5.0 (iPad; CPU OS 8_1 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12B410 Safari/600.1.4

Теперь запросы для этого сайта будут всегда отправляться от имени iPad Safari. Viva la Firefox!

Некоторые герои меняют User agent глобально и насовсем — но я категорически это не советую. Любоваться планшетной навигацией на каждом сайте — выше моих сил. Одного Хабра хватило, спасибо <sarcasm />.

Например: ваш любимый сайт с гитарным тюнером работает через Flash? Отправьте его на пенсию, и найдите тюнер на HTML5 и WebRTC.

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

Но что делать, если вы встретили сайт, которому действительно нужен Flash? Таким сайтом, например, оказался Livemocha, использующий Flash для аудио-занятий иностранным языком. Проект чрезвычайно интересный, Flash-free альтернативы нет, и обходиться без него не хочется.

Мы пойдём на небольшую хитрость: мы возьмём коммерческий Google Chrome. От своей opensource основы Chromium он отличается двумя главными вещами:

• Гугловским анальным зондом отслеживающим модулем (а заодно — интеграцией с Гуглосервисами)
• Не общесистемным, авто-обновляемым встроенным Adobe Flash.

Да! Google тоже понимают нашу боль по поводу Flash, и борются с ней своеобразно — упаковывают спец.версию плагина прямо в свой браузер, решая этим часть проблем с технологией.

Итак, ставим вторым браузером Google Chrome — или любой другой коммерческий браузер на его основе, например, новую Оперу или Яндексобраузер. Я выбрал последний — Гугловский зонд модуль интеграции там выпилен и заменён на Яндексовский, а Яндекс-сервисами я как раз не пользуюсь. К тому же, их новый (бета) интерфейс очень клёвый

Теперь, когда попадаем на Flash-only сайт, с которого не хочется уходить на что-то более достойное, тыкаем в Safari: «Open in IE» Разработка → Открыть страницу с помощью → Yandex, и радуемся.
Для Firefox есть удобные расширения вроде Open In Chrome

1. Flash в вебе устарел. Первые серьёзные высказывания о том, что он больше не нужен, появились 5 лет назад. От его использования в вебе отреклись все главные игроки, в том числе авторы технологии, браузеров, и рекламщики. Проникновение Flash уменьшается и на устройствах, и на сайтах
2. Большинство сайтов имеют полноценную Flash-free версию, но не показывают её браузерам на ПК по различным причинам
3. Если эти причины устранить, можно отлично пользоваться вебом без Flash. Автор этой статьи живёт так уже год, и встретил лишь два сайта, ради которых пришлось запускать Flash-enabled браузер⁴.
4. Пользователи Google Chrome не смогут избавиться от Flash — Google сделала этот плагин неотъемлемой частью браузера. Этот плагин, как говорит solver, можно только отключить.
5. Если вы полностью довольны Flash — вам, конечно, не зачем от него отказываться
6. Если один из ваших любимых сайтов (например, Flash-игры, хитрая мультимедиа и более старые веб-приложения) использует Flash и не умеет работать без него — вам действительно нужен Flash.

---

Примечания

1. Не выбросить, а ограничить применение: использовать как платформу для создания анимации и Air-приложений. Но в нашем случае это не принципиально.
2. Впрочем, он создавал больше проблем, чем решал, и от него пришлось отказаться.
3. Инструменты разработчика включаются в меню Настройки → Дополнительно
4. И один из этих сайтов, кстати, к написанию статьи уже обзавёлся HTML5-версией.

И, немного статистики:

JavaScript, AJAX, Socket и Flash/ActionScript — исследуем вопрос передачи данных в AJAX-приложениях / Habr

Как то в последнее время я начал активно повышать свои навыки и знакомиться не только и не столько с новыми технологиями. Например, я уже более-менее освоил Java, а именно — занимаюсь сетевыми сервисами. Также начал работать с ActionScript 3, хотя мое мнение относительно применимости в AJAX-приложениях Flash-компонентов не изменилось — их надо использовать там, где они дают максимальное преимущество, а вот вся «обвязка», например, интерфейс пользователя, можно сделать при помощи стандартных технологий. При разработке AJAX-приложений у разработчика есть достаточно большой выбор для решения задачи обмена данными с сервером. В основном, общение с сервером заключается в…

• получении первоначальных данных для формирования страницы, это обычно выполняет веб-сервер, так как большинство приложений — это обычные веб-страницы. Для этого может подключаться и сервер приложений, например, PHP или любой другой, то есть, страница может быть как статичной, так и динамической.
• получение данных для работы — например, когда приложение уже загрузило себя и все необходимое, включая графику, стили и код, идёт запрос данных, допустим — списка писем для отображения в почтовом клиенте. Для приложения на ExtJS (впрочем, любые фреймворки подойдут) обычно данные загружаются в виде JSON или XML, реже используется прямая загрузка кода (то есть, в ответ на запрос сервер формирует HTML-код c включенным в него JavaScript кодом и, возможно, дополнительно, JSON-данные). Кстати, именно этот подход во многих случаях использую и я, он очень удобен — например, если у вас интерфейс с вкладками (табами), то вы можете формировать код для каждого таба в момент первого обращения, а также обновлять, если надо, при каждом посещении. Например, на этом было основан мой последний игровой проект, где так формировались все внутренние информационные блоки.
• Периодический обмен данными (двусторонний) между приложением и сервером. Например, это команды от пользователя и результат обработки сервером. Не всегда это требует перегрузки интерфейса, я сюда выделяю именно поток данных и команд в границах одного экрана, при этом его состояние не изменяется. Здесь можно применить или прямую загрузку кода в скрытый элемент. Как раз так я и сделал в том игровом проекте — периодически посылался запрос на сервер, а для него был выделен специальный DOM-элемент, который обновлялся при помощи встроенного механизма UpdateManager из ExtJS (подробнее мы уже описывали его архитектуру и методы работы на примере ExtJS 1.1, и материал все ещё актуален, изменения в компоненте минимальны при переходе на другие версии).

Кроме этой достаточно простой классификации я бы хотел поднять еще такой вопрос. По сути, для коммуникации с сервером у нас есть, на самом нижнем уровне, доступном с JavaScript-а, объект XMLHTTPRequest, который приспособлен для передачи только строковых данных по HTTP-протоколу, а также множественные обвязки, врапперы и надстройки, скрывающие детали реализации, и предоставляющие специфический интерфейс для конкретных нужд. Например, в том же ExtJS, на этой основе построены все варианты взаимодействия — и Ext.Update, и Ext.data.Proxy, хотя в последнем случае не все так просто. Осознавая давно уже ограниченность возможностей XMLHTTPRequest (думаю, если у вас есть опыт разработки, то вы знаете о каких ограничениях идет речь), разработчики предусмотрели и другие варианты взаимодействия с сервером, включая экзотические варианты через фреймы (для реализации техники long poll). Для преодоления кросс-доменных ограничений есть и ScriptTagProxy и другие. Но основываясь только на возможностях браузера, HTML-а и JavaScript все же очень сложно реализовать достаточно хорошую, стабильную, а главное, производительную и универсальную систему коммуникации.

Данный вопрос ожидает своего решения кардинальным образом в спецификации HTML5, где будут предусмотрены WebSocket, то есть возможность получить в свое распоряжение и управление через обычный JavaScript возможностей сокет-соединений с сервером. Но вот когда это еще будет…

А такая возможность надо уже сейчас! Да, именно возможность заменить доступ через XMLHTTPRequest (вернее не заменить, а дополнить) на свой протокол, используя стандартные для серверных систем API сокетов, передавая через них как строковые данные, так и традиционные текстовые.

Основное отличие состоит в непрерывности канала передачи и его двунаправленности. То есть, если при традиционном способе мы, по сути, каждый раз инициализируем новый запрос, тратя время на установление соединения (а для HTTP это достаточно накладно, есть нюансы с свойством Keep-Alive, но они мало влияют на общую картину). Да и число параллельных запросов у каждого браузера ограничена. А нам во многих приложениях надо именно после старта установить канал связи и постоянно его держать открытым. Вот в этом нам может помощь модуль реализации сетевых сокетов в JavaScript.

На сегодняшний день есть несколько вариантов реализации такого модуля, два самых распространенных:

• через JavaFX приложение или Java Applet, который будет взаимодействовать с вашим JavaScript модулем через интерфейс (а он есть у каждой технологии, которая предназначена для внедрения в веб-страницы).
• через Flash, коммуникация посредством Extertnal Interface, путем внедрения невидимого Flash-объекта.

Хотя по многим параметрам технологически путь взаимодействия через Java/JavaFX кажется более мощным, там есть еще множество сложностей, хотя возможностей там намного больше, включая перенос частично логики сетевого приложения в апплет на сторону клиента. Однако есть и ряд сложностей, например, долгое время инициализации, но это вроде побеждёно в новой архитектуре Java Applet-а, а также сложности с безопасностью и кроссдоменными политиками (но это есть везде, в любой технологии, так как такой модуль потенциальная дыра в безопасности). Кстати, в процесса сбора информации наткнулся на описание того, что вариант с Java не требует policy-файла, но зато jar-файл с приложением должен иметь цифровую подпись, а кроме этого, скрыто инициализировать соединение все же не выйдет — требуется подтверждение от пользователя. Обе технологии позволяют реализовать как бинарные сокеты, для передачи двоичных данных, так и текстовые, но следует учесть, что во Flash это появилось в последних версиях, поэтому ниже 9 (вообще-то 8, но я не уверен) может не работать.

В общих чертах задача следующая — необходим компонент для реализации постоянного соединения с сервером, при этом желательно отвязаться от HTTP-протокола, используя прямое соединение TCP/IP или UDP, а также иметь возможность подключаться к любому хосту и порту. Кроме этого, надо иметь возможность реализовать собственный протокол, передавать любые данные, как в текстовом виде, так и, возможно, двоичные данные, а соединение должно быть постоянным, то есть, после инициализации сокет остается открытым до принудительного закрытия программой или сервером, либо до перезагрузки страницы. Ну и обычные требования — минимальная ресурсоемкость установления и поддержания соединения, кроссплатформеность и кроссбраузерность, объектный интерфейс и возможность управлять и перехватывать все значимые события.

Полностью этим условиям, на мой взгляд, удовлетворяет как раз связка Flash — небольшого модуля на ActionScript, который реализует сокетное соединение, и враппера на JavaScript, который управляет соединением и принимает/отправляет данные. В 9 и выше Flash-е, у нас кроме XMLSocket появился и более низкоуровневый механизм ввода-вывода, который и будем использовать, принимая во внимание его большую универсальность, а также повсеместное распространение 9-ой версии Flash Player-а (а теперь и 10-й).

Одно ещё надо заметить — для коммуникации с удаленным хостом, особенно если это не тот же хост, с которого загружена флешка, а также обязательно, в случае использования портов выше 1024 (здесь я могу ошибаться, поправьте, если кто в теме), необходимо наличие на этом хосте файла crossdomain.xml, в котором описываться политика доступа (хорошая статья по теме). Заметьте, не на хосте, с которого мы соединяемся, а к которому подключаемся! Файл политики должен быть доступен по 80-му порту, либо по другому, 843. Здесь могут возникнуть определенные сложности, если у вас работает только собственный сокет-сервер, который обслуживает другой порт, тогда ради этого надо или поднимать HTTP-сервер дополнительно, или переделать свой, добавив прослушивание этих портов.

Стоит ли писать такой компонент самостоятельно? В принципе, если требуемая функциональность специфична и вы хорошо знаете Flash/ActionScript, то создание такого модуля займет от силы несколько часов, и еще столько-же для написания и отладки JavaScript-враппера для взаимодействия. Но стоит поискать, возможно есть готовые решения? А они есть.

• Cometdesktop — реализация целого веб-десктопа, на базе как раз ExtJS, с применением реализации веб-сокетов (там даже есть сразу компоненты для ExtJS), впрочем сетевая подсистема там достаточно интересна для изучения, но все же это комплексный продукт, к нашим задачам он мало подходит.
• Cumhurchat — скорее заявка на реализацию чата на основе сетевого флеш-модуля, с сервером на РНР, но пока дальше анонса дело у разработчиков не зашло. А жаль.
• Хорошее исследование различных вариантов для технологии GWT, в частности, рассматривается и серверная сторона. Полезно прочитать для именно теоретической части, узнать о совместимости и сложностях в реализации.
• jssockets — вот это именно то, что нам надо. Очень простой проект, API состоит из нескольких функций и событий (ведь взаимодействие асинхронное), позволяет установить соединение, записать и прочитать строковые данные, а также управлять соединением. Предлагается минимум документации, а код надо брать из SVN, флеш-модуль компилировать вручную. Так что хочется чего-то более развитого…
• jSocket — лучший на сегодняшний день компонент для реализации сетевой коммуникации на базе Flash socket! Не побоюсь назвать его лучшим, так как предоставляет полный интерфейс сокетов из Flash в JavaScript — любые функции, для записи/чтения любых типов данных (строки, байты, целые числа, числа с плавающей точкой, даже объекты), оповещает обо всех событиях, позволяет встроить модуль в любое приложение. Особенностью библиотеки является поддержка множества независимых соединений — мы можем неограниченно создавать новые сокеты, библиотека держит служебный массив и каждый сокет уникальный (идентифицируется по id, хотя все реализовано через один и тот же SWF-файл). Используется jQuery, однако если посмотреть в исходный код, то библиотечно-зависимого кода там всего несколько строк, поэтому его можно, при надобности, переписать под другой фреймворк.

Есть правда в jSocket один нюанс — библиотека все еще в стадии альфа-версии, хоть и полностью рабочая, запланирована уже и 1.0 релизная версия. Лучше всего брать не доступную собранную версию, а зайти в SVN-репозиторий и получить исходники оттуда. К сожалению, автор занял позицию, что раз альфа, значит никаких гарантий и помощи, кроме доступного описания API и одного примера (я стучал ему в GTalk, но такой был ответ). Кстати, если вам надо, в SVN найдете и простейший сетевой сервер на Java, который может работать в паре с jSocket. Я, к примеру, реализовал собственный на основе фреймворка xSocket (Java NIO фреймворк), а в клиентской части использовал ExtJS вместе с jQuery адаптером, в такой конфигурации библиотека работала без проблем. API достаточно простой, всего одна страница описания функций, а пример охватывает типичное применение библиотеки, поэтому для знакомства вам этого материала будет достаточно, а я в будущем постараюсь написать свое руководство, осталось кое-что переделать на серверной стороне, чтобы можно было создавать свои протоколы обмена на основе строк.

А итог этого исследования прост. Для серьезных AJAX-приложений, если у вас есть несколько точек в архитектуре клиента, которые запрашивают данные и они требуют постоянного обновление, либо периодичность их относительно небольшая, вариант с несколькими соединениями через XMLHTTPRequest (или надстройки, доступные в сторонних фреймворках) может стать узким местом.

Вот для примера: в онлайн игре, что мы делали, у нас было, в лучшем случае 3 запроса на обновления данных, которые работали периодически — для того, чтобы избежать проблем с производительностью пришлось пожертвовать скоростью обновления, буквально вручную расставляя временные интервалы обновления (как сейчас помню, для чата там было 3 секунды на обновление списка сообщений или по факту отсылки своего, для списка онлайн было 7 секунд, периодический heartbeat-запрос, обновляющий статус игрока и получающий еще некоторые данные, работал каждые 15 секунд). И все равно такая схема, особенно если на нее накладываются действия пользователя, которые также генерируют запросы, начинает работать не лучшим образом.

Потому стоит серьезно рассматривать возможность использования сокетного соединения и специального сервера, если вам требуется быстрая реакция и обработка данных.

Касательно сервера — пока лучшим вариантом будет сервер на Java, так как РНР за счет своей сессионной природы работы сведет практически на нет все выгоды, а Java-сервер, правильно спроектированный, вполне сможет обслуживать тысячи одновременных подключений. Если вам этот путь интересен, посмотрите на ещё один проект, найденный в недрах Google Code — GFS Server — open source socket server for Flash and Flex clients. Мы, в рамках своего проекта по созданию открытой игровой платформы, скоро выложим реализацию собственного сервера (Java, на базе фреймворка JBoss Netty), а также упрощенную версию клиентского скрипта на базе jSocket, но переписанного для использования ExtJS, без необходимости сторонних библиотек, ну и поделимся одним из вариантов протокола поверх этой связки.

Flash и JavaScript-связь в IE (javascript, html, flash, flash-cs4, actionscript-3)

0 Gopherism [2010-07-21 08:58:00]

У меня возникает проблема с тем, что IE передает строку обратно в swf, используя класс EternalInterface во Flash CS4.

У меня есть swf со следующим кодом:

var externalString:String = ExternalInterface.call("IncomingJS")

который находится внутри прослушивателя событий, присоединенного к Event.ENTERFRAME, и оператора if, ожидающего ExternalInterface.available.

Функция IncomingJS выглядит так:

function IncomingJS() {
   return stringFromHTML;
}

и сидит на HTML-странице с помощью swf.

Я могу успешно получить переменную externalString и перейти к остальной части AS3 script в Firefox, Safari и Chrome, но не в IE.

Если я добавлю в alert (stringFromHTML) перед оператором return в Javascript, я получаю значение спама stringFromHTML, похожее на то, что Flash запускает функцию с нужной скоростью.

Встраиваемый код в HTML для swf немного прост:

<object><param name="movie" value="http://www.myURL.com/controlledScale.swf"><param name="allowScriptAccess" value="sameDomain" /><embed src="http://www.myURL.com/controlledScale.swf" allowScriptAccess="sameDomain"></embed></object>

Приветствуется любая помощь или совет.

Спасибо, DavidB

Изменить

Я понимаю, насколько слабый код вставки SWF. К сожалению, код HTML фактически работает в стороннем HTML-генераторе, и одним из его ограничений является то, что я могу иметь только одну строку (с неограниченной длиной) html за раз.

Могут ли другие параметры (swfObject и т.д.) работать либо без разрывов строк в коде, либо я буду задавать проблемы с Javascript и SWF, вместо того, чтобы напрямую встраивать SWF, использовать что-то вроде iFrame и обратитесь к «правильному» файлу html flash delpoyment?

Вид в точке на этом, где я даже не уверен, где проблема на самом деле находится. SWF обнаруживает отправку в Javascript во всех браузерах, просто не получая информацию только в IE.

javascript html flash flash-cs4 actionscript-3