Flash vs. Ajaxを翻訳してみた
経緯
最近、思うことあって、Flashと、Ajaxの技術的比較について、調べまわっているのですが、そんな中で、だーいぶ前の記事ですが、Flash vs. Ajaxって記事が興味深かったので翻訳しました。
注意！
- TOEIC 250点の脅威の英語力の持ち主が、Excite翻訳片手に訳した文章ですので、内容は保障できません！
- よく分からないところは括弧書きで訳注と英文入れときます。
- Flashムーブメントについては、疎いのでその辺も考慮してください。
- 2005年7月の記事なので、ちょっと内容が古いです。
- FLASHは、FLASH 7, ActionScript2.0の頃
- prototype.jsとかのjavascriptフレームワークはまだそんなにメジャーになっていない頃？
以降本編
Macromediaと「Ajaxムーブメント」
私は、(訳注：2005年)7月前半にニューヨークのFlash Forwardカンファレンスに出席しました。
Ajaxムーブメントがどのように、Flashの開発者と、Macromediaの考えに影響を与えているかを見るのはおもしろかったです。
(Ajaxは、むしろ既存の技術を使用するための新しいアプローチである為、私が、新技術ではなくムーブメントとして、Ajaxをとらえている傾向がある事に注意してください。)
Ajaxは、Macromediaの基調講演、彼らのQ&Aセッション、およびFlash/Javascript Integration Kitにおけるプレゼンテーションで、何度か言及されました。
Macromediaは明らかに、Web開発のトレンドにとどまろうとしていますが、
AjaxがFlashに取って変わってしまう恐れはあるのでしょうか？
(英文：but is there also some fear on their part that AJAX techniques could supplant Flash?)
手広くFlashを扱い、Ajaxの可能性を探り始めた開発者として、
私の考えを共有したいと思いました。
(英文：I thought I would share some of my thoughts. )
現在、技術的な見地からFlashがAjaxムーブメントを恐れる要素はそれほどありません。
クライアントで出来ることについて、FlashがまだDHTMLより前にいます。
そして古いブラウザ上では、Flashは、javascript依存関係の為、Ajaxより有利な立場を保ちそうです。
Flashの代わりにAjaxを使用するサイトでは、当分は、比較的簡単なUIと機能を主な特徴とするでしょう。
Google Mapのような大規模なAjaxアプリがいくつか出てくるでしょう。
しかし、殆どの場合、開発者はJavaScriptの頭痛の種の為に、それには価値が無いと決めるでしょう。
そして、GoogleMapですら、その規則を証明する一種の例外です。
(英文：And even Google Maps is a sort of exception that proves the rule.)
(訳注：「GoogleMapは、Ajaxで大規模アプリが作れるという例ではなく、例外的な事項である」みたいな意味？)
私は、Googleはビジネス的な理由で、Macromedia/Adobeに依存したくないのだと思います。
しかし、我々はGoogle Mapのイメージキャッシングと機能が、Flashと比べて、より滑らかで実装が容易であるか、考えなければなりません。
PRの観点から、MacromediaにはAjaxの台頭に、心配する所が少しあると思います。
Flashはある汚名を常に持ちました。それは、煩わしいイントロアニメに対しての反発という形で表に出ました。
Flashの最大の強みである「開発の容易さ」は弱みでもあります。
Flashで簡単にアニメーションが作れるため、最小公分母(英文：Lowest Common Denominator)が首位に立つのを許します。
(訳注：「ダメダメなFlashクリエイターが表に出るのを許した」みたいな意味？)
他にも、Macromediaによる過失はあります(それらは、Flashをまともな開発環境として受け入れられるのを遅らせました)
(英文：which have slowed Flash's acceptance as a serious development environment: )
- 厳密なプログラミング(最近改善されました)と、設計基準の欠如
(英文：The absence (until recently) of strict programming and design standards.) - プレビルド・コンポーネント(英文：pre-built components)のパフォーマンス悪さと、バグの多さ
- 完全なHTMLとCSS対応の不足
- テキストレンダリングの問題
Flashの将来は、近づく「8ボール」リリース(訳注：Flash9の事？)に、多くが掛かっています。
(英文：The future of Flash has a lot riding on the upcoming "8 Ball"
release.)
Flash Platformの採用が見送られている問題を、Macromediaが解決することが出来るならば、Ajaxによる、Macromedia支配への襲撃を避けることが出来るでしょう。
(英文：If Macromedia can address the issues that have held back the adoption of the Flash Platform, they can stave off the assault on their dominance by AJAX.)
Flash Forwardに採用した、Ajaxのような技術と共存できるツールとしてFlashを売り込む、という戦略は恐らく十分ではありません。
彼らは、より大胆に、そして、さらに詳細に、Flashがなぜ代替手段より良いかを述べなければならないでしょう。
本当にフラッシュの方が良いか？
| 特徴 | Flash | Ajax |
|---|---|---|
| オーディオ | フラッシュオーディオのサポート |
Media Playerのような外部プラグインを通してのみ対応 |
| ブラウザとの統合 | Flash Playerプラグインが必要 Flashはブラウザの事前に定義された長方形エリアにのみ制限される |
ブラウザのどんな部分とも簡単に相互作用可能 |
| 互換性の問題 | ブラウザのバージョンによる大きな互換性の違い | |
| CSS | 限定的な対応 | |
| 動的な生成 | SWFは事前にコンパイルする為、難しい 現在、SWFを動的生成できる言語は無い。(SVGと比較。あちらはXMLベース) (英文：Compare SVG, which is XML-based) |
動的な生成は難しいが、PHP等のいくつかのプラットフォームで可能 |
| プログラミングモデル | JavaScript2.0はどのブラウザでも対応していない(訳注：2005年の時点) JavaScript1.5では、大規模なOOPアプリを推奨していない |
|
| ラスター（ビットマップ）グラフィックス | JPG、GIF、PNGに対応 ビットマップ操作が可能 |
動的に画像をロード可能 |
| 正規表現 | ActionScript 2.0で対応 但しネイティブではなく、オープンソースソリューションが利用可能 |
|
| サーバーとの通信 | ASP、PHP、ASPX等の多くのサーバスクリプトと通信可能 Flash Remotingのような、商用ソリューションも利用可能。DBとのライブ接続を提供 (英文：Commercial solutions, like Flash Remoting, are also available that provide live connections to a database.) |
制限される IFRAMEハックかXMLHttpRequestを使用して、動的にサーバと通信可能 |
| テキスト | テキストAPIは、HTML機能を少しだけ模倣している | |
| ベクターグラフィックス | なし (訳注：2005年時点。今はCanvasとかあり) |
|
| ビデオ | Media Playerのような外部プラグインを通して、複数のフォーマットをロード可能 | |
| XML | ネィティブなサポートなし |
チェックの数がFlashがより優れたソリューションである印象を与えると思います。
確かに、多くのハードコアなFlash開発者は、何でも出来るのだから、Flashで全てを行った方が良いと言うでしょう。
しかし、結局は、あなたが何を開発しているか次第です。
(英文：But ultimately, it depends on what you are developing.)
しかし、AjaxがFlashを殺す領域があります。
動的に生成される重いテキストのアプリケーション。
それは、現在webを支配しています。
もし、あなたがメールプログラム、オンライン個人情報機器、またはオンラインストアを作っているなら、Flashはあまり意味を成しません。
Flashは、構文解析のための柔軟性や、大量のテキストデータの表示を絶対に与えません。
ダイナミックなテキスト領域でFlashを使わなければならないときの苦痛は誰もが理解しています。
たくさんのコードを書くことなく、テキストエリアを移動したり、大きさを変更するような柔軟性はありません。
ローカライズされる必要があるならば、問題は更にやっかいになります…
私は、インターネットアプリが双方向マルチメディア体験以上のものに進化することが必然であると思います。
(英文：I think it's inevitable that internet apps will evolve to be more of an interactive multimedia experience.)
その時(まだ争っているのであれば)Flashは、それを引き継ぐ準備ができているかもしれません。
(英文：At that point -- if it's still in contention -- Flash may be poised to take over. But for now, we're still in the stone age.)
他のリソース
Markは、今年(訳注：2005年)のSFでのAjaxカンファレンスでのMacromediaのプレゼンテーションについて、O'Reilly Radarに書きました。
(訳注：SFって何？)
私がFlash Forwardのプレゼンテーションで感じたことと、似たような反応を持っているように感じます。
MacromediaはAjaxの一部としてFlashを売り込もうとしていましたが、裏では、Ajaxを潜在的な脅威と感じているということでした。
要約：
Ajaxは、Flash(そして、Java、およびActiveX)等のインタフェースを不要にします。
例えば、私が、動的に表を更新したいとき、最初の選択肢はJavaだけでした。
その後、ずっと良い選択肢として、Flashが増えました。
現在、Ajax/JavaScriptは、Flashに勝るいくつかの利点を提供します。
- より早い読み込み時間
- 多くのブラウザ(英文：the rest of the browser)との一貫したインタフェース
- 一般的なものでも、自由なものでも、好きに選べるHTTPサーババックエンド
- 幅広い開発ツール
JonathanBoutelle.comには、双方の長所と短所が書かれたエントリがあります。
彼は双方が互いに補い合って、共存できると書いています。
私は、このエントリがFlash、Ajax比較の問題が掲示された最初の記事であると思います。
JD on MXには、簡潔なエントリしかありませんが、コメントで興味深い討論が行われています。
Microsoft WatchのMary JoはMicrosoftの、Ajaxへの関心について論じています。
Ajaxは運動場の形をかえる、500ボンドのゴリラであるかも知れません。
(訳注：「Ajaxは業界のルールを変えるかもしれない」みたいな意味？)
IE7は、今年リリースされます。
私は、Ajaxムーブメントの未来が、このブラウザの成功の鍵を握っていると思います。