Mozilla | SEO-LPO.net

EpicとMozillaが共同でUnreal Engine 4をWebにポート, Webゲームの高速化いよいよ本番

EpicとMozillaが今日（米国時間3/12）、Unreal Engine 4をWebにポートすると発表した。

昨年のGame Developers ConferenceでMozillaは、Unreal Engine 3のポートを発表し、多くのトリプルAゲームの基盤になっているグラフィクスエンジンがブラウザ上でも動くことを見せつけた。それは多くのデベロッパにとって目覚まし時計が鳴る音になり、数年前までにはWebとブラウザには不可能だった高度なゲーム体験を、今やプラグインなしで提供できることを自覚させた。

それを可能にするMozilla側のツールが、JavaScriptを高速化したasm.jsと、C/C++のコードをasm.jsのコードにコンパイルする（==どのブラウザでも動くようにする）コンパイラEmscriptenだ。いずれももちろん、WebGLが必要である。Firefoxの今の安定バージョンはasm.jsをサポートしているので、コンパイル後のC++のコードをネイティブで動かす場合の1.5倍のスピードをブラウザ上で実現できる。

Mozillaの技術部長でWebGLを作ったVladimir Vukicevicによると、1年前のUnreal Engine 3のデモはまさに単なるデモだったが、今回のUnreal Engine 4でEpicは、Webをゲーム開発のためのメインのプラットホームにしてしまうエンジンとしてデベロッパたちに紹介するつもりだ。今のところは文字通りのデモがあるだけだが、もうすぐデベロッパが実際に利用できるようになる。

MozillaのCTOで技術担当SVPでもあるBrendan Eichは今日の声明の中で、“これからはWebのリンクをクリックしてすぐに遊べるゲームと、時間をかけてダウンロードしインストールしなければならないゲームが、見分けがつかないほどのほぼ同じ体験になる。Emscriptenを使ってCやC++をasm.jsへコンパイルすると、ブラウザ上にネイティブに近いスピードが実現するので、Webをそのほかのプラットホームと同格に遇することができる”。

以下は、EpicがGame Developers Conferenceで見せたデモのビデオだ（SoulとSwing Ninja）:

【中略】

asm.jsで実際に商用開発を行っている企業の一つがTrendy Entertainmentで、そのゲーム事業部の名前はNomNom。NomNomが初めてデモしたWebベースのゲームMonster Madnessは、昨年12月にリリースされた。今では同ゲームのユーザの半数がWebバージョンをプレイしている。

Googleは、ハイエンドの3Dグラフィクスをブラウザに持ち込むための技術として、Native Clientを押している。Mozillaのasm.jsがJavaScriptであるのに対し、Googleはネイティブコードをブラウザ内で動かそうとする。でもこの技術は、ほかのブラウザがサポートしていないだけでなく、Chromeでもデフォルトではoffだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

Mozilla、収入の安定を求めてFirefoxの「新しいタブ」に広告表示を検討

オープンソース・ブラウザのFirefoxは公式ブログで、「新しいタブ」ページに広告を表示することを検討していることを発表した。パブリッシャーは通常のショートカットタイルの横に表示される広告タイルを購入することができる。このタイルには「広告」というはっきりしたラベルが付加されるという。

現在、インストールして最初に立ち上げたFirefoxでは、「新しいタブ」ページはFirefoxサイトへのタイルをのぞいて白紙だ。他のブラウザのスピードダイヤル機能と同様、Firefoxもユーザーのウェブ履歴をベースにして「新しいタブ」ページにリンクを追加していく。履歴がクリアされると「新しいタブ」ページも白紙に戻る。

そこでMozillaではユーザーの居住地域でもっともポピュラーなサイトへリンクするタイルを予め設定しておくことにした。これらのタイルのいくつかを広告枠にしようというのが今回の計画だ。

おそらくMozillaでは全面的に広告表示を行う前に、まず一部のユーザーで実験して反応を確かめるだろう。

現在Mozilla財団は財政を主としてGoogleからの広告収入に頼っている。 MozillaはGoogleをFirefoxの既定の検索エンジンに設定するという契約を結んでいる。また両者はFirefox上に表示されるGoogle AdWords広告の収入を分配することでも合意している。.

このGoogleからの収入がMozillaの年間売上高の90%を占めている。Firefoxのシェアが減少を続けているため、Mozillaは新しい収入源を探す必要に迫られていた。Mozillaは以前はGoogleの主要なパートナーだった。しかしGoogleの独自のブラウザ、ChromeがFireoxよりはるかに大きなシェアを獲得した現在、Mozillaが契約を更新を望んでも条件の大幅ダウンは避けられないだろう。

またこの数年Mozillaと広告業界は緊張関係にあった。Mozillaがターゲット広告を無効化するdo-not-track（トラック禁止）という機能を実装したためだ。ユーザーがこの機能を有効にすると、サードパーティーのクッキーを一切拒否するようになるので、ターゲット広告の表示が非常に困難になる。さらに昨年はユーザーが初めて訪問するサイトのクッキーを自動的にブロックする機能も追加されている。

しかし、必要に迫られてMozillaは広告主とうまくやっていくことに決めたようだ。新しいユーザーに広告タイルを表示し始める時期は不明だ。いずれにせよMozillaはまず広告主と交渉しなければならない。

[原文へ]

（翻訳：滑川海彦　Facebook Google+）

Firefox 27が公開。ソーシャルAPIを改善、SPDY 3.1を新たにサポート

本日（米国時間2/4）Mozillaは、Firefox 27を公開した。新バージョンのブラウザーは、FirefoxソーシャルAPIに主要な改訂があり、旧世代のWeb 2.0ソーシャルブックマークツール、Deliciousや、インドの音楽サービス、Saavnをサポートした。しかし、もっと重要なのは、ソーシャルAPIで1ユーザーが複数のサービスを同時に使えるようになることだ。

FirefoxのソーシャルAPIは、ソーシャルネットワーク、チャットサービス、ニュースサイト等が、ブラウザー内の固定位置にポップアップ通知を表示できるようにするために作られた。2012年に公開され、昨年Mozillaがデベロッパーに開放したが、各社が挙ってソーシャルAPIを統合をするという動きは感じられなかった。

しかしこのサービスの大きな問題は、同時に1つしか統合アプリを動かすことができず、複数使いたい場合は少々面倒な切り替えを強いられることだった。このたびその制限が外されたことから、今後いくつか新しい統合が見られるかもしれない。

他の大きな新機能としては、GoogleのSPDY 3.1プロトコルのサポートと、Transport Layer Security (TLS) バージョン 1.1および1.2がFirefoxのネットワーキングの選択肢に加わったことだ。これらは、良く知られているSSL暗号化プロトコルの事実上の後継にあたる。

Androidに関して、今回Firefoxチームはわずかな変更を加えただけだった。モバイル版もTLS 1.1および1.2をサポートし、標準フォントが読みやすいものに変わった他、ユーザーインターフェースにいくつか小さな改善が施された。

[原文へ]

（翻訳：Nob Takahashi / facebook）

パナソニック、Mozillaと提携してFirefox OS搭載のスマートTV開発へ

CESでLGがOperaのweb OSを搭載したスマートTVを発表した直後にPanasonicもモバイル連動テレビの計画を明らかにした。

パナソニックはMozillaと提携してFirefox OS (FFOS)とオープンWeb標準の精神に準拠したスマートTVで居間の大画面の制覇を企てる。

今のところFirefox OSはブームを起こしているというには遠い。ヨーロッパや南アメリカの市場で安価な携帯電話に多少使われている程度だ。このHTML5ベースのモバイルOSのGoogleのAndroid OSと競争できるようになるのは困難が山積している。そこでMozillaがモバイル・デバイス以外の分野にエコシステムの拡張を図るというのはある程度納得できる。

はたしてFFOSのUIが消費者にパナソニックのスマートTVを買う気を起こさせ、オープン・プラットフォームの旗印がデベロッパーにアプリ開発に参加させるだけの魅力があるかどうかは今後に待たねばならないだろう。

「MozillaとPanasonicは共同でFirefox OSとそのオープンなエコシステムの普及に努力する」と両社は今朝(米国時間1/6)のプレスリリースで述べた。このプロジェクトはパソコンやモバイル・デバイスの世界ではすでに広く採用されているHTML5と各種のウェブ・テクノロジーをスマートTVに拡張し、消費者が放送と同時にウェブ・サービスを通じたコンテンツを簡単かつ幅広く利用できるようにすることが狙いだ。

パナソニックのAVCネットワークス社,のテレビ事業部長、Yuki Kusumはプレスリリースで「Mozillaとの提携はわれわれのスマートTVの接続性と対話能力を家庭の内外で強化することが目的だ」と述べた。

来るべきFFOS搭載のパナソニック・スマートTVはMozillaのWebAPIを搭載しているため、インターネットに接続可能な他のデバイスやスマート家電製品をモニタしたり制御したりすることが可能だ。

この記事の執筆時点ではMozillaはFFOS TVのスクリーンショットをまだ公開していないが、プレスリリースによればFFOS搭載テレビではEPGのような基本機能も専用の内蔵プログラムではなく、HTML5で書けるようになり、サードパーティーのデベロッパーが多様なアプリケーション容易に開発できるようになるとしている。

「パナソニックがわれわれのFirefox OSを採用したことをたいへん嬉しく思っている。Firefox OSとオープン・ウェブによるプラットフォームへの参加者は増えつつあり、スマート・スクリーンの普及に向けて大きな力となっていくだろう」とMozillaのアジア事業部のモバイル・デバイス担当上級副社長、Li Gong博士は述べた。

パナソニック自身もモバイル・デバイスのメーカーではあるが、昨年、スマートフォン市場からの撤退を決定しており、生産の努力をスマートTVのような別分野に向けることにしたものだろう。パナソニックはFirefox OS搭載の次世代テレビだけでなく、Firefox OSとオープン・エコシステムの普及に関してMozillaと幅広く協力していくと述べている。

[原文へ]

（翻訳：滑川海彦　Facebook Google+）

Mozillaのasm.jsがさらにネイティブコードのスピードに近づく

Mozillaのasm.jsはJavaScriptの厳密なサブセットだが、Firefox上の処理系/実装系はそれを、通常のJavaScriptのコードよりも相当高速に動かせる。すなわち、Firefoxが内蔵しているJavaScriptエンジンにはOdinMonkeyと呼ばれるモジュールがあって、そのおかげで今年の3月にはasm.jsのコードがネイティブコードの約2倍の所要時間で動くことを実証した*。そして今週のMozillaの発表では、多くのベンチマークにおいて、ネイティブの1.5倍以下という遅さ（速さ?）にまで接近した。〔*: 約2倍;ネイティブよりもちろん遅いのだけど相当接近した、という意味。2倍よりは1.5倍の方が、もちろん速い。〕

GoogleはNative ClientでWebアプリケーションが、コンパイラを通ったまさにネイティブのコードを実行することをねらっているが、MozillaはJavaScriptをネイティブに近い速さで動かす方に賭けている。両者のやり方は相当違うけど、共通しているのはどちらも、デベロッパがまずCやC++でコードを書き、それをブラウザ内で動かすことだ。Mozillaはそのために、LLVMからJavaScriptへのコンパイルを行うコンパイラEmscriptenを使用する。

ゲームエンジンはCやC++で書かれているものが多いので、asm.jsも主にゲームをねらっている。実際、Mozillaが初めて公開したasm.jsのデモの一つは、ブラウザ内でネイティブに走るEpicのUnreal Engine 3だった。

かつての2倍遅いから今回の1.5倍遅いへの改良は、asm.jsとコンパイラEmscripteの両方をすこしずついじって達成された、とMozillaのAlon ZakaiとRobert Nymanが発表の中で言っている。また、FirefoxのJavaScriptエンジンの改良の効果も大きい。ZakaiとNymanによると、中でもとくにスピードアップに貢献したのは、一部の浮動小数点数演算のの最適化だ。

asm.jsが2倍とか1.5倍と言っている対照のネイティブコードは、C/C++によるオリジナルをgccやclangでコンパイルした結果である。それを、Emscriptenとasm.jsによるコードと比較している。

下図は、最新の結果だ:

〔ブラウザ～HTMLがサイズを縮小しているので、クリックして別画面で見ると原寸で（大きく)見れます。〕

asm.jsは今のところMozillaのプロジェクトだが、GoogleのChromeチームはかねてから気にしていて、最近そのOctaneベンチマークの一員に加えた。Chrome本体がasm.jsを近々サポートすることはないと思うが、asm.jsのコードは、ふつうのJavaScriptコードとしては今のどのJavaScriptエンジンでも動く。Firefoxの上ほど速くないけど。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

HTML5/JavaScriptでFlash Playerを置換するMozillaのShumway, 最新Firefox Nightlyに登場

WebネイティブでFlashファイル用の効率の良いレンダラーを作ろう、というMozillaの実験的技術Shumwayがついに、Firefoxの最新のナイトリービルドに登場した。製品としての完成はまだまだ先だが、このプロジェクトはFlash Playerを完全に置換して、HTML5とJavaScriptでSWFファイルを表示することをねらっている。

90年代の後期には、MacromediaのFlash Playerを使ってWebにサウンドやビデオやアニメーションを導入できたが、しかし今では、Flashはたぶん、いちばん嫌われているブラウザプラグインの一つだ。でもそれは、今でも至る所で使われており、モバイルブラウザの多くがもはやサポートしていない中で、デスクトップ上では依然として必須アイテムだ。

Mozillaがこのプロジェクトを開始したのは2012年の初めだが、同団体がこのプロジェクトについて詳しく語ったのはその年の11月で、それ以降は音沙汰がなかった。そのときの説明によるとShumwayの目標は、“SWFやそのほかのリッチメディアフォーマットのためのランタイムプロセッサを、ランタイムの実装のないプラットホーム向けに提供すること”、とされていた。また、リッチメディアフォーマットをブラウザ内で表示する方法を改良し、プロプライエタリなソリューションを不要にすることによって、オープンWebを一層前進させたい、とも言っている。

今のところShumwayはブラウザのエクステンションなので、最新のナイトリービルド（バージョン27）のデフォルトの機能ではない。しかし、about:configへ行けばアクチベートできる（ただしFlash Playerがインストールされていることが必要）。

また最新のFirefox Nightlyをインストールしなくても、MozillaのShumway Inspectorでその能力を見ることができる。まだ、Flashを使っている商用アプリケーションのすべてを動かせるわけではないが、提供されているデモのレーシングゲームやベーシックな2Dフィジックスエンジンなどは、この技術のポテンシャルを見せている。今後Flashのすべての能力を完全に置換できるようになるのか、それはまだ未知数だが。

MozillaがAdobeの技術を置換しようとする大規模プロジェクトは、これが二つめだ。この前同団体はPDF.jsでAdobe Readerを置換し、ブラウザ内でPDFファイルを表示するための新たなデフォルト技術を提示した。

なお、同種の試みはMozilla以外でも行われている。たとえばGoogleが2011年に立ち上げたSwiffyは、SWF→HTML5コンバータだった。その後今日まで情報はないが、今でも活発に開発が行われているプロジェクトであるようだ。

Adobe自身も、このところFlash離れを進めている。同社の最近のWebデベロッパ向けのプロジェクトはほとんどすべて、WebスタンダードとHTML5ベースのサイトの制作に関連している。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

Web Componentsのバスに乗り遅れたくないMozillaがpolyfillコンポーネントライブラリBrickをローンチ

Web Componentsは近い将来、Webアプリケーションの作り方を変えるだろう。Web Componentsの中核的な機能は、まるでライブラリのように、デベロッパがユーザインタフェイスの独自の部位/部品（コンポーネント）を作り、それらをHTML上で、デベロッパが命名した任意の名前のタグ（たとえば<datepicker>）で再利用できることだ。そんなWebコンポーネントを作るのは簡単ではないが、基本的にはHTMLとCSSとJavaScriptの知識だけあればよい（”Shadow DOM”に関する知識もあった方がよいかも）。Web Componentsの標準化プロセスはまだまだ時間がかかりそうだが、GoogleとMozillaはその前からいろんな取り組みを開始している。

しかし、まだほとんどのブラウザがサポートしていないのに、Web Componentsはどこから手出しをしたらいいのだろう？　そこで、polyfillというコンセプトが登場してくる。また、GoogleのPolymerフレームワークや、Mozillaの地味な名前のpolyfillライブラリx-Tagというものもある。polyfillというコンセプト自体は、かなり前からある。その考え方は、ブラウザがネイティブに持っているAPIをJavaScriptなどで複製して、クロスブラウザで使えるようにすることだ（それをまだネイティブでサポートしていないブラウザ上でも）。それは要するに Modernizrなどが使ってるのと同じコンセプトだが、GoogleとMozillaのプロジェクトは同じ低レベルのWeb Components用polyfillsを共有している。

Googleは今年初めのI/OカンファレンスでPolymerフレームワークを紹介したが、それは明らかにGoogleが今後長期にわたって推進したいと考えているコンセプトだ。Mozillaもこのバスに乗り遅れたくないので、このたび、x-TagベースのクロスブラウザなライブラリBrickをローンチした。それは、説明によると、“一般的によく使われるユーザインタフェイスパターンを、使いやすく柔軟性に富みそしてセマンティックなWeb Componentsに抽象化する、新しいカスタムHTMLタグ集”、を提供するものだ。

Brickを使うことによってデベロッパは、ベーシックなインタフェイス成分、たとえばヘッダメニューや日付指定、カレンダーなどや、もっと複雑なアニメによるトランジションのあるスライドデッキなんかを、単純にBrickのスタイルシートやJavaScriptライブラリへのリンクをドキュメント（Webページ）に書き、それからカスタムのHTMLタグを使って、それらの新しいインタフェイス成分を呼び出せるようになる。

Mozillaも認めるように、それまでは、そういう新しいユーザインタフェイス成分を使うためにはjQuery UIみたいなものを使い、定型的でノンセマンティックなマークアップをHTML中に置いて、初期化や管理もJavaScriptで明示的に書く必要があった。またそういうタグの多くは、カスタマイズしようと思うと大量の属性を加える必要があった。

将来的には、Web ComponentsはデベロッパによるWebアプリケーションの作り方を変え、UI成分の再利用や共有を容易にするだろう。MozillaとGoogleが積極的にその開発を支援しているから、やがてpolyfillsは、レガシーブラウザをサポートするためにのみ、必要なものになってしまうと思う。ただしメジャーなブラウザのすべてがWeb Componentsをサポートするのは、さらに先かもしれないが。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

アプリストアをもっと楽しい場所に…Mozillaの取り組みはAppleやGoogleも参考にすべきでは

アプリストアは破綻している。そこは、何千何万ものがらくたに占領され、良いアプリやおもしろいアプリを見つけることがほとんど不可能だ。各カテゴリのトップテン以外にも、良いアプリはあるはずなのに、それを簡単確実に見つける方法がない。Appleの”Genius”機能はすごくおバカだったのでiOS 7では下ろされ、さらにつまらない”Apps Near Me”機能に代わった。それは、あなたの周辺にいる人たちが今使っているアプリを、教えてくれる機能だ。Microsoftは、トップテンの愚かさに代わるものとして、Windows 8.1では人間が編集した情報を提供するようになったが、そこでもまだ、単純なランキングの支配力は強い。

Mozillaは、Firefox OSでごく最近モバイルゲームに参戦したばかりだが、過去数年間競合他社たちがやってきたことを、反面教師として（やってはいけないこととして）学ぶことができた。今現在のFirefox OS Marketplaceは、それほど革命的でもないが、Webアプリに力を入れる姿勢には新鮮さがある。そしてMozillaが先週発表したアプリストアプロトタイプの計画には、先行各社が参考にすべきものがあると思う。

Mozillaは次のように論ずる: “今のアプリストアでは、そこのメンテナーたちが任意に選んだものしか見ることができない。そこには、自分との個人的な関連性がない。新しいアプリを探したくても、どうやって探したらいいのか、分からない。せいぜい、友だちの言うことや、どこかの記事で読んだことを、参考にするぐらいだ”。

これらに対しFirefox OS Marketplaceのプロトタイプでは、個々のユーザに合わせたニューズフィードみたいな形で、アプリストア体験を個人化しようとする。それは、“フォロー”のような面倒な仕組みを実装しなくても、ユーザが関心のあるコンテンツを追っていける方法だ。プロトタイプでは、ユーザはハート型の小さなアイコンをクリックして自分の関心を指定する。すると、その関心分野の今後のアップデートや関連コンテンツを見られるようになる。

しかしMozillaが長期的に考えているのは、フィードそのものをユーザ自身が編集できる方式だ。その具体的なやり方は未定だが、今すでに一部のサードパーティのアプリストアがやってるような方式かもしれない。でもそれは、既存のメジャーなアプリストアがほとんどやらなかった試みであり、いわばアプリストアをソーシャル化するものだ。Androidのストアも、友だちがダウンロードしたアプリを教えてくれるが、その友だち自身が編集したリストが送られてくるわけではない。

Mozillaのチームは、このところユーザのアプリストアにおけるエンゲージメントが低下傾向だ、と言っている（ぼくも個人的にそのことを実感する）。つまり、今のアプリストアは、楽しいから訪れる、というものになっていない。Mozillaは、ちょっと風変わりなマイクロコピーやアニメーションでユーザを釣ろうとしているが、しかしいちばんかんじんなのは、ユーザがここでいろんなアプリやコレクションや記事やリビューやビデオ、などなどを発見できる、というコンセプトだ。Mozillaは、アプリストアを楽しく長居できる場所にしようと努力している。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

Mozillaからの企業や広告業界への要求: 消費者のプライバシーを犯さない個人化技術を採用せよ

Mozillaが今進めているプロジェクトが完成すると、ブラウザがユーザのすべての関心事のリストを収める中心的なリポジトリになる。今日（米国時間7/25）Firefoxブラウザの非営利の母体的団体Mozillaは、多くのWebサイトで個人化が進んでいるが、しかしそのために、“ユーザが知らず知らずのうちに自分の個人情報その便利な機能のいわば代価として払っている場合が多い”、と論争を挑んだ。個人の関心グラフをオンラインで多くのベンダと共有するのではなく、Firefoxのやり方ならユーザの閲覧履歴を見るだけで趣味や関心事を見抜ける、と。

Mozillaは前にもこのアイデアを提唱したことがあるが、今日の提案はMozillaが広告業界と、クッキーやDo Not Track（トラッキング拒否）の取扱いについて長らく議論している最中に行われたのだ。

この提案は、ユーザが、自分が訪れたWebサイトと自分の関心を共有する場合は、それを明示的かつ透明に（==自分に分かるように）行われるべきだ、という主張に基づいている。Webサイトは、ユーザの関心事に関する個人プロファイルを密かに勝手に作らなくても、個人化は十分にできる。そのような個人化なら、ユーザがそのサイトを初めて訪れた場合でも可能だ（閲覧履歴が見られるならば）。

“Web上の対話的な活動に個人が明示的に参加することによって、欲しいものを容易に得られるようになるべきだ。その参加の仕方も、ユーザに見えない楽屋裏部分があるのではなく、その全体が明示的に定義されていなければならない”、Mozillaの企業および法務担当SVP Harvey Andersonが、今日そう書いている。“Webサイトのコンテンツの個人化とそれに関連したイノベーションはすべて、ユーザの体験の質を上げるものでなければならない。そのためには、個人化を行おうとする側が消費者に、彼/彼女にどれだけの個人情報を公開する意思があるかを問う、明確なオプションを提示すべきである。サイトは、それに基づいて、もっとも適切なコンテンツやサービスをユーザに提供するものでなければならない”。

Mozillaはこの考え方の実装を目下実験中だが、誰もが利用できる公式の実装が提供されるのはまだまだ先のようだ。Mozillaがこれについて初めて語ったときにはしかし、Webサイトはユーザの個人的情報を勝手に記録すべきでないし、どんな情報を共有するかしないかはユーザ側が完全に決められるべきだ、と述べていた。しかしそのことを、企業の善意と良心と良識にだけ依存して実現するのは、とても難しいだろう。

しかし当面Mozillaは、とにかくこの問題について会話を始めよう、という姿勢だ。広告業界もMozillaには一目置いているから、会話ならそんなに難しい課題ではないと思われる。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

Firefox 22安定版リリース―asm.jsとWebRTCをサポートでウェブ・アプリ開発全般にも大きな影響

今日（米国時間6/25）、MozillはFirefox 22をリリースした。これはWebRTCプロトコルとasm.js JavaScriptサブセットをサポートする最初の安定版Firefoxだ。

Microsoftの場合を除けば、現在、ブラウザのアップデートは日常的ルーチンになっている。しかし今回のWebRTCとasm.jsの追加は今後のウェブアプリの開発のあり方を大きく変える可能性がある。当面Firefoxをターゲットにしていないデベロッパーもこの変化には注目しておく必要があるだろう。

ビルトインWebRTCのサポート

デベロッパーはWebRTCを利用してビデオチャットや音声通話、ファイル共有などの機能をビルトインしたアプリを開発することができる。サードパーティのプラグインやソフトウェアを組み込む必要はない。Tokboxを始め多くの企業がWebRTCに社運を掛けている。しかし現在までWebRTCをサポートする有力ブラウザはGoogle Chromeだけだった。今回Firefox安定版がWebRTCをサポートしたことでスタートアップも既存大企業もこぞってこのテクノロジーの利用を始めるだろう。今のところMicrosoftだけがWebRTCとは異なる規格の採用を決めているが、将来Internet ExplorerにもWebRTCが採用される可能性は大いにある。

asm.js

asm.jsもゲームのルールを変える可能性のある重要なテクノロジーだ。われわれが3月の記事で詳しく紹介したとおり、asm.jsはJavaScriptのサブセットで、ウェブブラウザ内でネーティブアプリに匹敵する高速で作動する。MozillaのCTO、BrendanEichは私の取材に対して、「メモリが安全ではないC、 C++のような言語に対して安全なバーチャルマシンを構成できるJavaScript言語のサブセットだ」と説明した。EmscriptenのようなC and C++をasm.js向けにコンパイルできるツールのおかげで、デベロッパーは既存のC、C++プログラムをブラウザ内で安全に作動させることができるようになる。

この新機能はMozillaのBananaBreadゲーム・デモで試すことができる。このデモにはWebGL、Emscripten、asm.js、WebRTCが使われており、ハイエンドの3Dマルチプレイヤー・ゲームをブラウザ内で高速に作動させることができることを証明している。

その他Firexfox 22ではWebGLのレンダリングのパフォーマンスの向上などいくつかのマイナー・アップデートがある。詳細なリリースノートはこちら。

[原文へ]

（翻訳：滑川海彦　Facebook Google+）

正規の科学もWeb化したい: Mozillaがそのための運動組織ScienceLabを立ち上げ

Mozillaが今日立ち上げたプロジェクトは、これまでこの団体が得意としてきた標準規格周辺のプロジェクトとはやや趣が違う。そのScienceLabと呼ばれるプロジェクトは、オープンサイエンス運動のリーダーKaitlin ThaneyとSoftware CarpentryのファウンダGreg Wilsonが長となり、“世界中の科学者がオープンなWebを利用して科学の未来を作りだしていく”ことを支援する。プロジェクトは、Alfred P. Sloan Foundation（スローン財団）がスポンサーしている。

“Webを作ったのは科学者たちだが、そのオープンなWebはまだ、科学の実践を、メディアや教育やビジネスなどそのほかの領域を変えたほどには変えていない”、MozillaのMark Surmanはこう主張する。

現在の学術評価のシステムは、悪名高い”publish or perish”（発表するか消え去るか）という言葉にも見られるように、知識は研究論文によってのみ広まる、という観念の上に立脚している。しかも論文はなるべく、学者村において“ステータスの高い学術誌”に載った方がよい。この状況に対してMozillaが当然考えるのは、“これだと科学者たちは永遠にWebとそのオープンでコラボレーション的な特質を学習や共有の場として利用しない”、ということだ。

彼らがプロジェクトの目的として記しているのは、“今あまり実績や評価が良いとは言えないデジタル的ネットワーキング的な科学研究の領域を大きく押し広げ、Webが科学に対してなし得ることをさらに遠い未来的視野まで探究する”ことだ。

プロジェクトが最初に取り組むのは、学生や学者たちへのデジタルリテラシの啓蒙だ（まだインターネットもWebも知らない研究者がざらにいる）。また、研究者たちに基礎的なコンピューティングスキルを身につけてもらう。そして何よりも重要なのは、これまでオープンなWebを作ってきた方式ややり方を、科学の未来を作るためにも応用できるという認識を、対話の活性化を通じて広めていくことだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

次世代Firefox v.25のデザインはChrome風―メジャーアップデートのNightly版公開へ

数日前、MozillaのFirefoxエンジニアリング担当副社長、Jonathan Nightingaleは私の取材に対して新しいFirefoxを説明し、「もうこれはブラウザとは呼べないかもしれない」と述べた。

Nightingaleは、「ブラウザというのはすでに語感が古臭い。ユーザーはブラウザで以前ほどウェブサイトをブラウズしない。ブラウザは高度なウェブ・アプリを動作させたりソーシャル・ネットワークにアクセスしたりする手段としてもっぱら使われている」という。つまり開発者はブラウザの利用法の大きな変化に対応して、ブラウザのあるべき姿を考えなおさねばならないということだ。

コードネームはAustralis：タブは角丸に、機能は単純に

Mozillaの未来型ブラウザ計画はAustralisと呼ばれている（Mozillaはプロジェクトのコードネームに星の名前をつけるのが好みのようだ〔タニア・アウストラリスはおおぐま座の連星〕）。このプロジェクトの成果は近くFirefoxのNightly版v.25として公開される。その後、Firefoxの通常のリリース・チャンネルで公開され公開され、最終的には安定版での公開となるはずだ。

ただしNightingaleによればこのバージョンが安定版として公開されるまでにある程度時間がかかるかもしれないという。

冒険をいとわないユーザーならMozillaのあまり知られていなUX部門から開発途上版をダウンロードしてインストールできる（ただしその結果クラッシュするのはもちろん、HDDがずたずたになるなどの事態が起きても自己責任で）。

ではAustralisとは何か？　従来のFirefoxよりGoogle Chromeに似ているというのが第一印象だ。現在のAustralisのテーマは角を丸めたタブでその下にURL窓、検索窓、各種アイコンと並ぶ。右端は三本の横棒のアイコンの設定オプションだ。

Nightingaleによれば、Australisのコンセプトは「できるかぎり高機能化すると同時に操作をできるかぎり単純化する」ことだ。このため開発チームはユーザーが実際にブラウザをどのように操作しているか詳しく観察した。新デザインは明快で直感的になっているという。たとえば、現在のデザインでは選択されていないタブは枠も表示されず、アイコンだけを残して背景に溶け込んでしまう。Chromeでどんどんタブを開いていくとやがてタブの表示幅が狭くなりすぎてアイコンも見えなくなってしまうが、Australisではタブの最小幅が設定されており、タブの数が表示の限界を超えるとタブ・バーがスクロールできるようにした。

AustralisのUIテーマが安定版に実装されるのは10月以後になるということだが、 Nightingaleは「現在公開されているバージョンもAustralisのデザイン・コンセプトの影響を受けている」と強調した。「読込中止、読込、再読込」がひとつのボタンに統合されたのもその一例だという。

またこうした新デザインはAndroid版Firefoxにも用いられている。このアプリは4000万ダウンロードを記録しているという。念のために付け加えるとMozillaは現在でもiOS版を諦めたわけではない。しかしAppleの現在のApp Storeの約款ではMozillaとしてiOS版をリリースすることはできないのだという。しかしMozillaチームはブラウザ以外の分野でのiOSアプリの開発を考えているようだ。

カスタマイズ

Australisの単にUIデザインの改良だけではない。ルック&フィールを含めたブラウザのカスタマイズの方法も大きく変わる。Mozillaは現在多様なカスタマイズ・ツールを提供しているが、必要なツールが探しにくく、使いやすさも高いとはいえない。MozillaのGavinSharpは私の取材に対して「ここでの目的はユーザーがそれぞれのニーズに合わせて簡単にカスタマズでできるようにすることだ。しかしせっかくのカスタマイズ機能もユーザーが存在に気づかなければ意味がない。われわれはユーザーがFirefoxのほとんどあらゆるパーツを自由に削除、追加、配置できるようにし、またそのカスタマイズ機能を今までよりユーザーの目につきやすいようにすることにした」と語った。

もちろん未来のブラウザを作るにはデザインだけでは足りない。MozillaではユーザーがSocial APIのようなツールをどのように利用しているか詳しく調査している。またパフォーマンスの改善のためにはOdinMonkeyやasm.jsのプロジェクトを実施している。

とはいえ、Australisが公開されたときにユーザーがまっさきに気づくのは新デザインだろう。率直に言ってChromeとの類似を否定するのは難しい。この点をめぐっては間違いなく賛否の論議が巻き起こるに違いない。

[原文へ]

（翻訳：滑川海彦　Facebook Google+）

BlinkとServoとRust: ブラウザの次の進化の方向性が見えてきた

先週は、ぼくのようにブラウザを追っているブロガーにとっておもしろい週だった。週の終わりには、Internet Explorer 11がWebGLとSPDYをサポートするらしい、という話も聞いた。その前の火曜日にはMozillaがメールで、MozillaのCTO Brendan Eichへの電話インタビューの可能性を打診してきた。その話題は次世代のブラウザエンジンServoと、それが書かれているプログラミング言語Rustだ。しかしMozilla Researchが単独でこれらを手がけているのではなく、この、マルチコアプロセッサと異種混成的なアーキテクチャ向けに最適化されている新型エンジンをAndroidとARMに実装する作業には、Samsungが協力しているのだった。MozillaはこれまでServoについてあまり何も発表しなかったから、今こうやって大きく発表することは少々意外だ。

おもしろいことに、GoogleのChromeのチームが話をしたいと言ってきたのも、先週の火曜日だ。おかしなことに、そのときの広報の連中は、いつもと違って、詳しい話を何もしない（通常は、何の話かぐらいは事前に教えてくれる）。Googleのエンジニアリング担当VP Linus UpsonとOpen Web PlatformのプロダクトマネージャAlex Komoroskeは、WebKitをフォークしてWebKitベースの独自のレンダリングエンジンBlinkをローンチする、と言った。ぼくは自分が話を聞き間違っていないか気になって、何度も彼らに念を押した。WebKit開発の外部の人間ににとっては、GoogleがWebKitの本流を去るという話を、にわかには信じられない。一般的にWebKitは、ChromeとSafariのおかげでデスクトップとモバイルで大成功した、と見られている。それを独自フォークする理由が、思い当たらない。

でもBlinkは正しい

だからGoogleのWebKitフォークは先週のいろんな発表やリークの中で、いちばん話題になった。Googleはフォークの理由を純粋に技術的なものと言うが、WebKitは今でもAppleとGoogleが仲良くやっている数少ないものの一つだから、政治的動機も疑われる。しかもWebKitへのコード貢献量は、このところGoogleが最大なのに。

今後の成り行きを予言するのは早すぎるが、ぼく自身はかなり楽観的だ。たしかに、Webデベロッパが自分のコードを試験すべきレンダリングエンジンが一つ増えてしまう。でもChromeのチームによれば、それは彼らにとって“苦渋の決断”だった。Googleはレンダリングのスピードを上げたいが、WebKitは今いろんなブラウザで使われている。だから、WebKit本流における抜本的な改作は難しい。

Chromeのチームは、“ブラウザが複数あることと同じく、レンダリングエンジンも複数あった方が、今後の健全なイノベーションを刺激し、オープンなWeb全体のエコシステムの健康にとって良い”、と考えている。たしかに、そのとおりだろう。2008年にChromeが突然現れてから、ほかのブラウザのイノベーションは加速した。当時の競争の中心は、高速なJavaScriptエンジンの開発だった（そしてWebKitを使っているブラウザも、JavaScriptエンジンはそれぞれ違っていた）。BlinkとServoという新しい馬が走り出した今は、レンダリングエンジンも重要な競争の要素になり、そしてその競争は、より速くてより安定的なブラウザを求めるユーザとデベロッパに利益をもたらす。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

Web上のペイメント（支払決済）には共通APIがあるべきだ, と頑張るMozillaがFirefox OSに実験的実装

Mozillaはペイメントベンダ(payment vendors, Paypalなど)やWebの標準規格団体W3Cに働きかけて、支払決済の共通APIを作ろうとしている。それはデスクトップとモバイルの両方で使える、使いやすくてセキュアなAPIだ。Mozillaはすでに、実験的なJavaScript APIをスマートフォン用のFirefox OSに実装している。それは最終的に、Webアプリケーションが支払を受け取るための共通APIになるものだ。支払を取り扱うための共通のAPIを複数のペイメントベンダが実装すれば、デベロッパやパブリッシャーにとって新しいビジネスモデルが開かれる、とMozillaは主張する。

この新しいAPI、navigator.mozPay()は、MozillaによるとGoogleのWallet for Digital GoodsのAPIを参考にしており、まずFirefox OSに実装されてから、その後Firefox for AndroidやデスクトップのFirefoxにも加わる。今のきわめて実験的で不完全なAPIでも“Firefox OSフォーンの上でライブの支払を十分に処理でき、急速に実用レベルでの採用が進む”、とMozillaは期待している。

しかし疑問なのは、ユーザやデベロッパにとってはPayPalやStripeがあれば十分で、オンラインの支払決済はそれほど重大な問題ではないのに、なぜMozillaがことさらそれを取りあげるのか、だ。それは、Mozillaの主張では、あらゆる支払サービスにおいてAPIが統一されていれば、個々のWebアプリケーションを使っているユーザに選択の自由が生ずる。また現状では、ユーザも企業もクレジットカード情報という重要な個人情報を扱わざるを得ず、Webという混雑した環境で事故や事件に遭わないことはつねに、運を天にまかせた結果でしかない。言い換えると、ユーザ自身が自分のセキュリティをコントロールできない。

navigator.mozPay()ではデベロッパが、彼/彼女が選んだペイメントプロバイダをを認可でき、きわめて単純率直な方法で支払を処理できる。それはクレジットカード情報の交換ではなく、（ローカルな）トークンの交換処理になる。

今のバージョンのAPIを実装して試してみたい人は、ここへどうぞ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

Mozillaもブラウザの並列処理に本腰, Samsungと提携してマルチコアプロセッサ向けエンジンServoを開発

一見すると不似合いなカップルのようだがMozillaが今日（米国時間4/3）、同団体の次世代ブラウザエンジンServoでSamsungとのコラボレーションを開始した、と発表した。Mozilla ResearchがServoに研究プロジェクトとして着手したのは2012年だが、今もまだ商用プロジェクトにはほど遠い。Rustという比較的新しいプログラミング言語で書かれていて、この言語もMozilla Researchが開発している。MozillaとSamsungは、RustとServoをAndroidとARMアーキテクチャに実装することで協働する。

Samsungの広報によると、同社がこのプロジェクトに関心を持った理由は、同社が“レガシー製品を革新するためのさまざまな新しい技術を探究中であるから。このコラボレーションによって未来のWeb体験の新しい局面が切り開かれることを期待している”、とのことだ。

マルチコア時代のブラウザエンジンとは

MozillaのCTO Brendan Eichによると、未来のコンピューティングにおいては並列処理がふつうになる（そう思っているのは彼だけではない）。Mozillaの研究部門はこのことをWebという視点から見て、今多くのユーザのコンピュータや携帯電話やタブレットがマルチコアのプロセッサを使っているにもかかわらず、今日のブラウザはもっともベーシックなマルチコアプロセッサすら有効活用していないことに気づいた。というより、Eichによれば、Webの今日のスタンダード自体が、これまでのブラウザが用いているシーケンシャルな処理から、マルチコア上のより効果的なページレンダリングに移行することを、妨げている。今その例外と言えるのは、GPUを使うWebGLと、JavaScriptにマルチスレッドを導入するHTML5のWeb Workersぐらいだ。

しかしEichが強調するのは、ブラウザの処理の一部とレンダリングのパイプラインをただ並列化するだけでは不十分である、ということ。彼によると、全体的にすみからすみまで、いちばん深い部分で並列化されているWebエンジンだけが、明日の16コア32コア〜〜といったマルチコアプロセッサを完全に有効利用できる。

Samsungはもちろん、モバイル用の強力なマルチコアプロセッサの開発に取り組んでいる。だから、今マルチコア指向にはまっているMozillaとのパートナーシップは、良い相性である。しかし問題は、SamsungとGoogleの長年の深い仲、それにAndroid上のモバイルブラウザとしてのChromeの強力な地位が、今後どうなるのかだ。

RustとServo

そこで、Rustが登場する（Mozillaは今日、コンパイラのバージョン0.6と関連ツールをローンチした）。Rustは、C++、Lisp、Erlangなどいろんな言語の良いとこ取りをしたような言語だが、言語設計の力点は安全性（C++のようにメモリ管理のエラーが頻発しないこと）と並列処理に置かれている。RustはMozillaによると、“多くの用途においてC++をリプレースできる現代的な言語を作る試みであり、とくに、クラッシュやセキュリティの脆弱性に導くタイプのエラーの抑止を目標としている”、という。今年の終わりまでにはコアライブラリが完備し、めでたくRust 1.0をリリースすることをMozillaは目指している。現在の開発チームはMozillaから5〜6人、Samsungから10〜20名、という規模だ。

Geckoの将来

Mozillaにはすでに、Geckoという優秀なエンジンがあり、それが同団体のブラウザとFirefox OSのベースになっている。また現時点では、Geckoを完全にServoでリプレースする計画はない。むしろMozillaはServoを、“新しいハードウェアのための新しいエンジン”と位置づけるだろう、とEichは語る。Firefoxの人気から考えると、Geckoの抜本的改良は互換性を損なう危険性が大きい。しかしたとえばFirefox OSでは、かなり新しい機能をエンジンに導入することに成功している。だからEichが考えているのは、ServoがMozillaに多くのことを教えて、それがGeckoにも使われていく、という将来の道筋だ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

MozillaとEpic GamesがUnreal Engine 3をWeb化, Web 3DゲームのFlash不要化へ

2011年にEpicは、好評なUnreal Engine 3の技術をFlashにポートして、ブラウザでもかなり高度な3Dゲームができることを示した。しかし2013年の今では、Flashはもう人気のプラットホームではない。そこで、現代的なブラウザではプラグイン不要でどれだけのことができるかをゲームデベロッパたちに示すために、MozillaとEpicが協力してUnreal Engine 3をWebにポートした。Flashプラグイン全盛の2011年には、考えられなかったことだ。

Mozillaの技術部長でWebGLの発明者でもあるVladimir Vukicevicが今週の初めに語ったところによると、MozillaはWebを現代的なゲームにとって十分有効なプラットホームにしたいと考えている。約半年前にMozillaは、そのemscriptenコンパイラを使ってCやC++のコードをJavaScriptのサブセットであるasm.jsにポートすることができるようになった。それによってJavaScriptのコードはネイティブコードの約2倍近い速さになり、この方法による最適化はFirefox Nightlyの最新バージョンがサポートしている。現代のゲームとゲームエンジンは複雑だから、ネイティブに近い速度をWeb上でも実現できることは、たとえばEpicの有名なデモCitadelやUnreal Tournamentを動かすことに欠かせない。今日行われたGame Developers ConferenceでMozillaは、Unreal Tournamentをブラウザ内でネイティブに動かして見せた。

Unreal 3 Engineの全体をWebに移植するのにEpicは4日を要し、その後小さな調整作業も行った、とVukicevicは述べている。Epicが同社のゲームエンジンをWebに持ち込むのはこれが初めてではないが、それにしても上々の結果だった。デモは数週間後にお目見えする。それまでは、最新のFirefox Nightlyの上でMozilla作のBananaBreadデモを見て我慢しよう。Web用のUnreal Engine 3をEpicが商用製品として提供するのか否かについては、まだ不明だ。

Mozillaのゲームプラットホーム担当Martin Bestによると、今回の作業の結果はすべて、MozillaのAndroid用モバイルブラウザと、そしてもちろんFirefox OSに実装される。モバイルでもゲームはネイティブの2倍近い速さで動くとMozillaは予想しており、それを示す社内的なデモもすでにある。一般公開は、まだ先のようだが。

これらの技術を使った商用製品を作っていくことに関してBestは、MozillaはすでにDisneyやElectronic Arts、ZeptLabなどと共同で作業を進めている、と言った。ZeptLabはすでに、Microsoftとの協働によりCut The RopeのHTML5バージョンを作ってWeb上に持ち込んでいる。Bestによると、このような協働案件を打診すると最初はどの企業も疑心暗鬼であるが、“一週間もするととても熱心なパートナーになってしまう”そうだ。

Googleも、ブラウザをネイティブの速さに近づけることに、Native Clientを通じて努力している。これは、デベロッパが作ったWebアプリケーションがコンパイルされたネイティブコードをブラウザ内で実行できる、という技術だ。GoogleのChrome Web Storeには、そのようなゲームがすでにかなりある。しかしMozillaのCTOでJavaScriptの作者でもあるBrendan Eichの言では、Firefoxがそのような技術をサポートすることは短期的にはない。むしろ彼の考えではJavaScriptの今後の進化でネイティブに近いパフォーマンスが達成されるだろう、という。Eichの見方では、Native Clientは“Webとは別のもの”だ。APIも、WebのAPIとは言えない。だからそれは、Mozillaが志向しているものとは違う。Mozillaは、Webそのものを前進させることにのみ、関心がある。

Asm.jsのコードの良いところは、それがあくまでもJavaScriptであることだ。だからどのブラウザでもそれは動く。しかしAsm.js向けに最適化されたブラウザなら、相当に速い。Eichによると、いずれはどのベンダも〔Googleも？〕、遅かれ早かれ、その最適化を実装するだろう、とのことだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

自分が伸びる場を見つけたFirefox OS: アプリはHTML5, デバイスは途上国低価格機

zte-open2

ZTEの昨日（米国時間2/25）の記者会見の内容は旧聞ばかりだったが、少なくともこの中国のOEMの初のFirefox OSスマートフォンで遊ぶことはできた。低コストを第一目標とするこのOpenと呼ばれる機種は、ZTEのキャッチフレーズによれば、“冒険好きで新しいものを試したがっている若者たち”がターゲットだそうだが、どこがそうなのか？

Openの3.5インチディスプレイは、好悪両面がある。スワイプやタッチへの反応は速くてスムースだが、小さいからアクションに精度を要する（テキストの正しい場所をタップするときとか）。指の太い人は困るかもしれない。色の再現力はそれほどではないし、視野角も狭いが、まあお値段相当か。

Openの良い点は、まず、かわいいこと。余計な、ごちゃごちゃしたものがない。かどがまるいのも、かわいい。オレンジとブルーのソフトなプラスチックを着ていて、その色はなんとなくFirefoxを強調しているようだ。リアカメラは3.2メガピクセルの固定焦点だから、もちろん感動的な性能ではない。

率直に言ってこのハードウェアは、HPのSlate 7と同様に、派手なニュースになるネタがない。でも、それで当然だろう。この記事の画像からもお分かりと思うが、Openは明らかに途上国向けの製品だ。まずヨーロッパでローンチしてから、この夏にはラテンアメリカへ向かう。乗る馬（キャリア）は、Firefox OSの大スポンサーTelefonicaだ。まだ価格の発表はないが、Mozillaのエンジニアリング事業担当マネージャMichael Treeseによると、部品コストは総額で100ドル未満ぐらい、というから、最終価格も相当安いだろう。

そしてもちろん、気になるのはFirefox OSだ。記者会見で実機を試した時点では、最終リリースではなく、まだキャリアによるテストなどが待っている。でも、Firefoxのブート画面は、なかなかキュートだ。ブートはすぐ終わるから、ユーザがタップしたロック画面を出すのに待たされることはない。

Firefox OS（以下FFOSと略記）はこれまでの数か月で何度も見たから、ぼくにとっては見慣れたインタフェイスだ。ホーム画面をさっとスワイプすると、大量のHTML5アプリが出る。電話、メッセージング、Firefoxブラウザ、カメラの4つは大きな固定アイコンがある。ナビゲートは十分にスムースだが、たぶんハードウェアが非力なせいで、ひっかかる瞬間もある。アプリの立ち上げには、気になる遅さはない。

FFOSユーザにとっては、今からすでにかなりのアプリがある。FacebookとTwitterのFFOS専用アプリ、Pulse、AirBnB、SoundcloudなどなどはHTML5アプリがある。Firefox Marketplaceへ行けば、“数千本”ぐらいのアプリがすでにある。ただしMozillaが念を押して曰く、今のところFFOS機のユーザがアプリやコンテンツを入手できる場所は、ここだけだ。ユーザは主に途上国の人びとと想定されるから、彼らのお金の節約のために、 Mozillaはリアルタイムのネットワーク/トラフィックモニタツールを、同機にプレインストールしている。

あらゆる点から見て、Firefox OSには確かに将来性がある。もちろん、まだ磨き込みは必要だ。機能面で、Androidなどと互角に勝負できるか？　それは、まだまだ。Mozillaも、その点は率直に認めている。

TreeseはFirefox OSの機能集合について、“まだ力の差があるが、1年で追いつきたいと考えている”、と述べる。短納期低価格機のプロであるZTEを味方に付けたことは、Mozillaの目標市場を考えると賢明な動きだ。まだ評価用の最終製品はないが、でもこのおちびさんは、価格とマーケティングが適正なら、大ブレークするかもしれない。
★この記事の原文で、スライドを見てください。

〔今週のFirefox OS関連記事：
Telefonica, T-Mobileが採用、
Twitterアプリが登場、
キャリア決済（通話料と合算）もサポート。
〕

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

Firefoxの先行テスト版がWebRTC, H.264, MP3をデフォルトでサポート

Mozilla_Nightly_icon_2011

Firefoxブラウザのテスト専用の先進的バージョンFirefox Nightlyで、WebRTCがデフォルトでサポートされた。WebRTCは、プラグインなしでブラウザ自身がリアルタイムのUDP通信を行う規格で、とくにオーディオやビデオによる対話やコンテンツ配布に適している。これまではFirefox Nightlyのオプションとしてサポートされていたが、これがデフォルトになったことにより、数か月後には安定版（正規リリース版）の工程に組み入れられることが期待される。

MozillaのPaul RougetとRober Nymanが今日の発表声明の中で、“これは大きな前進である。これにより特殊な設定や構成を必要とせずにWebRTCを直接、Webブラウザの中で動かせるようになる”、と書いている。

おそらく今年いっぱい、WebRTCがにぎやかな話題になるだろう。主なブラウザがこぞって、その実装を開始しているからだ。Chromeはすでにバージョン23から安定版でWebRTCをサポートしており、最近Mozilla とGoogleは、二つのブラウザのユーザ同士がWebRTCを使って対話できる、というデモを公開した。

なお今回のFirefox Nightlyでは、H.264とMP3形式がサポートされる。ただしデコードはオペレーティングシステムが行い、今はWindowsの7以上のみでサポートされる。MacとLinuxのサポートは、目下開発中だ。

Mozillaが今週初めに発表したように、このNightlyリリースはWindows 8のMetroインタフェイスをサポートしている。

WebGLのデモも…

ちょっと関係のない話題だが、Mozillaは今日（米国時間2/20）、WebGLのすばらしいデモを発表した。ACTISKUのAnthony Liotが書いたこのデモは、Webブラウザもついにここまで来たか！と思わせる最先端のグラフィクスであり、しかもデベロッパはプラグインに依存せずにクロスプラットホームな体験をユーザに容易に提供できる。ただし現状では、Internet ExplorerがまだWebGLをサポートしていない。

webgl_demo_actisku

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

WebKitの独占状態の是非

Operaが自前のレンダリングエンジンの開発を停止し、オープンソースのWebKitエンジンを採用することにしたというニュースは各所から大いに注目を集めた。WebKitはGoogleのAndroid向けブラウザでも、またAppleのiOS向けブラウザにも採用されている。すなわちモバイル環境においては、既に事実上の標準の地位を獲得している。そしてさらにその触手をデスクトップ環境にも伸ばしつつあるところだ。既にChromeは、Tridentを採用しているMicrosoftのInternet Explorerや、MozillaのGeckoを採用しているFirefoxと比べてかなりのリードを獲得している。こうした状況の中で、頭に浮かぶ疑問がある。各社が独自のエンジンを開発して、競い合う環境の方が良いのか、それともWebKitを標準として各社に採用してもらう方向が望ましいものなのだろうか。

WebKitはオープンソースのプロジェクトであるので、誰でも開発に参加することができる。Google、Apple、Mozilla、Microsoft、Opera、あるいはブラウザ関連のさまざまな企業が参加しているので、標準的に採用される技術を即座に実装することができる。レンダリングエンジンが統一されることで、開発者の苦労は大いに低減されることとなる。レンダリングエンジンの違いによる細々とした表示スタイルの違いに頭を悩ませないで済むようになるわけだ。

Hacker Newsのスレッドにも多くのコメントが寄せられている。WebKitの開発に集中することで、多くのイノベーションが生み出されるのであれば、WebKit独占の状態は開発者にとっても利用者にとっても良いものとなる可能性があるという論調もみてとれる。

こうした独占に向けた流れに抵抗する筆頭はMozillaだ。これまで独自のGeckoエンジンおよび、その後継となるServoに多大なリソースを割いてきた。Mozilla CTOのBrendan Eich曰く、Mozillaの存在意義をかけて独占には抗っていくつもりだとのこと。また、MozillaエンジニアのSteve Finkは、モバイルかデスクトップかを問わず、WebKit独占を許してしまえばイノベーションが阻害され、少数企業によるプラットフォーム独占を惹起してしまうと述べている。そのような状況になれば、結局は各社利益を追求する迷惑な混乱に支配されてしまうことになるとも述べている。

しかしWebKitはオープンソースであるので、もし開発が滞ったりあるいは特定のステークホルダーが開発を政治的理由によって妨害するようなことがあれば、即時に開発の道筋を分岐させることができるので、独占による悪影響などはないと考える人もいる。

但し、ウェブの世界ではこれまでにも「独占の弊害」を経験したことがある。IE5やIE6の時代（Netscapeが舞台を去り、そしてIEは6のリリースが2001年で、IE7が登場したのは2006年だった）には、完全に「停滞」状況になっていた。そうした状況の中、2004年あたりからはFirefoxがスタートし、そしてWebKitをベースとしたGoogleのChromeも2008年に登場してきたのだった。Chromeのミッションはレンダリングエンジンの標準化を試み、そしてJavaScriptの高速化を行うということだった。独占を崩す存在が登場してきたことにより、ウェブプラットフォームは現在のような応用環境に進化したのだとも言えるだろう。

「ウェブ」が今後戦っていく相手は?

Operaは、「独占状態は良くない」と主張しつつ、その言葉とは正反対にも見える道を歩むことになった。Operaもそれなりのシェアを獲得しているにも関わらず、「多くの開発者たちがWebKitのみをターゲットに開発をしているという現状があります」と述べ「先頭に立って独自の道を追求していくことにメリットは少ないと判断しました」とのこと。

Operaの選択した方向は興味深いものだ。結局のところ、ウェブ技術は各社のレンダリングエンジンの違いで競っていくのではないと判断したわけだ。今後の競合相手はネイティブアプリケーションであると判断したわけだ。Operaは「閉鎖的な“アプリケーション”に対抗して、オープンなウェブ技術を推し進めていくつもりだ」とのこと。その戦いを効率的・効果的に進めていくためにWebKitの採用を決めたということだ。

開発者と利用者の着眼点の違い

理想を言えば、さまざまなベンダーが「標準」に則った開発を行って、レンダリングエンジンの違いによる差異などを意識しないで済むというのが良いのだろう。同じコードは同じように表示されるべきだろう。しかし、「標準」を意識しつつも実装により細かな違いがあり、同じような表示を実現するなどということはできなかった。

但し、たいていの利用者はレンダリング方式の違いによるウェブページやウェブアプリケーションの見え方にはほとんど意識を払わなかった。利用者は利用可能な機能（ブックマーク、プラグイン、タブなど）によってブラウザを選択していただけなのだ。そうした機能の多寡や使い勝手によって、利用者はブラウザを切り替えてきたのだ（もちろんあまりに速度が遅いものなどは排除されることになる）。

Mozillaは、魅力的な機能を提供していくためには、ブラウザ全体を自ら手がけていく必要があると述べている。今やWebKitに対する唯一の対抗勢力と言っても良い存在になったMozilla陣営は、自らの言葉を証明するために、利用者にとって真に魅力的な機能を提供していく必要がある。

個人的には、「標準」に基づいた競合がある方がイノベーションサイクルも早まると考えている。ウェブ技術というのは、まだひとつのエンジンに集約してしまうような枯れた技術ではないと思うのだ。レンダリングエンジンが複数存在すれば、余計な作業も増えるだろうし、迷惑に感じられることすらあるかもしれない。しかし将来的にきっと実を結ぶ、「若い時の苦労」になると思うのだ。

［原文へ］

（翻訳：Maeda, H）

ここに来てMozillaの存在意義, WebKitに乗り換えないことの意味

mozilla_wordmark_300dpi

今週初めにOperaは、Prestoと呼ばれる独自のレイアウトエンジンを捨ててWebKitに鞍替えする、と発表した。Google、Appleに続いて今度はOperaだから、オープンソースのWebKitエンジンは今、大きな支配的勢力になりつつある。しかしMozillaのCTO Brendan Eichは昨夜の記事で、Mozillaは当面、レンダリングエンジンを変えない、との意思を表明した。Mozillaは上記3者のような営利企業ではないので（そのことをふだん忘れている人も多いと思うが）、そのミッションも自ずから異なるのである、と。

Eichは、“Mozillaがふつうの企業なら、Operaと同じことをしただろう”、と言う。“しかしわれわれは企業ではないし、またデスクトップにおけるシェアは、横ばいもしくは伸びていると思われる。それには、Geckoがもたらした短期的な勝利、という側面もある”。

Eichはさらに続けて、“われわれがWebKitの波に乗ってしまえば、そのブラウザはWebKitを核とするChromeと何ら変わりのないものになる。しかし、そのようなモノカルチャーはWebに良いものをもたらさない。WebKit一色でなく、FirefoxがありInternet Explorerがある、という多様性が重要だ”、と言う。しかもEichの見方では、8つのビルドシステムがあり多様なフォークもあるWebKitは、単一の存在ではない（8、AppleのNitro、iOSバージョンのSafari、…）。グラフィクスのバックエンドやネットワークスタックも、それぞれ異なる。“Android 2.3のときWebデベロッパたちは、WebKitの不統一性に苦労したのだ”、とEichは書いている。

またWebKitに切り替えるとしたらその費用は、Operaに比べてMozillaでは相当に大きい、とEichは言う。Operaはデスクトップのシェアが比較的小さいから、切り換えの費用も比較的少ないが、それでも、ささいな額とは言えない。しかしMozillaは、XMLベースのユーザインタフェイス構築言語 XULに、大きな有形無形の投資を蓄積している。それを捨ててWebKitに乗り換えたら、Firefoxアドオンの膨大な資産とエコシステムを失うことにもなる。

独自のエンジンを持つからこそ、Firefox OSやFirefox for Androidなどのプロジェクトも可能になる。中でもとくにEichは、今Firefoxが使っているGeckoエンジンの次世代版Servoに、大きな期待を抱いている。Servoは、マルチコアのCPUと大規模並列処理のできるGPU向けに最適化されている。だから、ブラウザのマルチスレッド化（==内部的並列処理化）ではAppleやGoogleよりも一歩進んだものになる。

Webデベロッパにとって、OperaがWebKitに切り替えたことは大きな意味を持たないだろう。元々、サイトをOpera向けに最適化していたデベロッパは、それほど多くないからだ。デベロッパはむしろ、WebKitへの切り換えを歓迎するだろうし、またMozillaについても、Eichが主張する独自路線の維持が本当に将来のイノベーションを招き寄せるのか、議論したいところではないだろうか。しかしWebも人間社会と同様、健全な多様性こそが、進歩の動因なのだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）