第39回 HTML5とか勉強会+日本Androidの会 2013年5月定例会に参加してきました。
そのメモ。ほぼベタ書きです。

最近のHTML5はどうなっているのか

（白石さん）
日本Androidの会との初めての合同勉強会と言うことで、HTML5の基本的なところを話す。

なぜHTML5がこんなに騒がれているか。

・マルチプラットフォームである
・マルチデバイスである
・技術的に成熟してきた

マルチプラットフォーム／マルチデバイスのところは異論もあると思うが、とりあえずそういうことにして話を進める。

HTML5の7つの「○○Web」

オフラインWeb。
リアルタイムWeb。
レスポンシブWeb。
セマンティックWeb。
スピーディなWeb。
Webプラットフォーム。
インプレッシブ（感動的な）Web。

オフラインWeb

電波の届かないところでも使える。
具体例。
Google Slides（Presentations？ Google版パワポ）。オフラインに対応している。
（補足：デモとしてGoogle Slides表示中に回線を切って動作確認したが、うまく動かなかった。理由不明）

オフラインWebを実現するためのテクノロジー。
アプリケーションキャッシュ。
Web Storage。
Indexed Database API。
File API。

リアルタイムWeb

WebSocketとか。
今のWebは、昔のWebに比べてリアルタイム性が遙かに優れている。
Google Spreadsheetsでは、他の人が行った変更がすぐに反映される。
TwitterとかFacebookもリアルタイム。

黒板デモ。（これ？→ http://codezine.jp/article/detail/6502）
WebSocketを通じてサーバ経由でブラウザ間で通信している。一方の変更がすぐ他方に反映される。

WebSocket。
Server Sent Events（昔のCommetが標準化されたもの）。
WebRTC。最近ChromeとFirefoxで疎通したというのが話題になった。

レスポンシブWeb

1枚のHTMLで複数のスクリーンサイズに最適なデザインを実現する。

CSSメディアクエリ。
レスポンシブ・イメージ。
グリッドレイアウト。これはまだ仕様ではないが、仕様が出つつある。
（補足：たぶんこれ→ http://www.w3.org/TR/css3-grid-layout/）

セマンティックWeb

エンジニアはHTMLをマークアップする時に「見出しだ」「段落だ」「イベントの名前だ」というような意図を持っている。
セマンティックWebでは、マークアップにその意味を込めることができる。
また、これによってWebが大きなデータベースになる。

マークアップの中にmicrodataがある。
例えばGoogleで検索を行い、検索結果を「イベント」で絞り込むと、リンクの他に日付やイベント名の情報が表示される。
これはメタデータとして埋め込まれている情報を使用している。

HTML5 Semantec Elements。
HTML5 microdata。
RDF/RDFa/RDFa Lite。
Microformats。
……

よりスピーディなWeb

SPDYという新しいプロトコル。
基本的にはHTML（HTTP 1.0や1.1？）と変わらないが、1回1回リクエストしてレスポンスを返して切断、という欠点を改善している。

SPDY。
HTTP/2.0。（SPDYをベースにした、HTTPの次期バージョン）
オフライン技術。これもWebを大幅に高速化する技術。わざわざWebまで取りに行かないので早い。

プラットフォームとしてのWeb

TIZEN。
Chrome OS。
Windows 8。
Firefox OS。

特にスマートフォン、モバイルプラットフォームのWebは、位置情報やカメラや音声などSystem APIsと呼ばれるものが揃ってきている。
あるいはテレビや電子書籍。

インプレッシブWeb

3Dの表現やCanvasや、最近ではシンセサイザーを作るようなこともできるようになった。
ネット上に山ほどデモがある。
例えば「ROME」（http://www.ro.me Chromeでしか動かない？）。3Dを生かしたインタラクティブムービー。

HTML5 Canvas。
SVG。
WebGL。
Web Audio API。

Webアプリとネイティブアプリの違い

HTML5だけの話であればここで終わりだが、今回はAndroidの会との合同勉強会と言うことでWebアプリとネイティブアプリの違いを。

Webアプリはインストール不要。
プラットフォームを跨いで動作する。
アプリの公開、停止のタイミングを自由に制御できる。
ビジネスモデルの自由度が高い。
一方でアプリストアからの導線が期待できない、デバイスの機能をフル活用できないといった欠点もある。

AndroidとChromeの統合について

丸山先生

Webアプリの変化

今まではサーバサイドのWebアプリを指していた。今も主流はそうだが、変わりつつある。

サーバサイドのWebアプリとAndroid Nativeアプリ。
両者は、現在はほぼ独立。それはなぜか。
Androidのアプリは多くがAndroid単体で動くアプリであり、クラウドのサービスを利用するアプリは少数だった。

これがサーバサイドのWebアプリ＋HTML5アプリへ。

FacebookのHTML5からの離脱。
彼らはHTML5に肩入れしすぎたと語り、アプリをネイティブで作り直した。

「サーバサイドのWebアプリ＋HTML5」という話と「Nativeアプリ＋HTML5」という別の流れ。

背景に、サーバサイドのWebアプリのスタイルの見直しの進行がある。
サーバ側はサーバの負担やネットワーク帯域の増大といった困難が生まれていて、見直しが進んでいる。
一方でクライアントのリソースはリッチになってきている。

アプリケーションの多様化

現実に進行したのは「サーバサイドWebアプリ＋HTML5」の一方的な拡大でなく、いろいろなバリエーションのアプリが出てきた。

Webアプリは、サーバ側の従来のWebアプリと、クライアント側単体で動くアプリとで分岐してきた。

こうした中でPackaged Web Appsに注目している。
Web標準の技術を使いつつ、デバイス／OS／ハードウェアに依存しないアプリ。

Offline enabled by default。ネットワークを必要としない。
Cloud enabled by default.。
Install based。Packageの形でアプリを配布。
新しいセキュリティポリシーの採用。CSP（Contents Security Policy）。

Rich Client／Thin Server Architecture

サーバとクライアントの役割の見直しの一般的な背景。
・クライアント側でハードの性能が飛躍的に向上した。クラウド・デバイス（クラウドに接続するクライアントデバイス？）は、PCより遙かにリッチなクライアント。
・サーバの負荷が増大。
・ネットワーク・トラフィックの増大。
・プログラムとViewの分離の難しさ。全てがサーバ側でコントロールされ、かつ込み合ったWebアプリでは、プログラムもViewもどちらの変更も開発の工程に大きなインパクトを与える可能性がある。

IntelのXeon Phiは60コア。

8コア Android時代の始まり。
アーキテクチャ的には4コア＋4コアだが、次期に8コアになる。
Galaxy S4は2つバージョンがあって、Samsungのチップを使っている方は8コア？

Thin Server Architectureは2008年初め頃に提唱された。
サーバ側の開発者はViewを考えず、ビジネスロジックに集中できる。
クライアントが分離して開発でき、アプリケーションが複雑でなくなる。

先ほど、Webアプリがサーバとクライアントへ分岐したという話をした。
その中でPackaged Web Appsは大事だが。

Web Apps on Mobile。
FacebookはサーバサイドのWebアプリをそのまま載せるのには反対したが、サーバの負荷をAndroidやiPhoneのネイティブに逃がすということで下げた。
（手段がHTML5か否かは別として）プレゼンテーション層をモバイルへ移すという大きな流れがある。

AndroidのHTML5対応の遅れ

昨年来のAndroidへのChrome搭載開始によって、AndroidのHTML5対応の流れが変わりつつある。
Nexus 7から、Chromeが標準ブラウザになった。

Android 2.3（従来の標準ブラウザ）では223だったスコアが、4.2（Chrome）で417と倍近くに改善された。
今まではAndroidとPCでChromeのバージョンがずれていたが、今後は揃えると言われている。

Googleの進むべき道（※）

（※丸山先生が考えるところの）

GoogleのWebアプリ／HTML5の取り組み。
GoogleはAndroidもやっているが、一方でブラウザのシェアもChromeで着実に取っている。

両者がいつ合流するかはわからない。
Android 5.0、あるいはChrome 29で実現されるか？ 今年の秋頃か。

Chrome Packaged Apps。
今年の2月にDeveloper Preview、5月にCustomer Preview。

AndroidとChromeのマーケット統合。
AndroidのPlay MarketとChromeのWeb Storeの統合に帰結すると予測。
ここで販売されるアプリはデバイスだけでなくLinuxなど他の環境でも動く。

Androidアプリ開発の可能性。
グローバルに目を向ければ、Androidアプリの潜在的なユーザはiOSアプリユーザの3〜5倍。

2012年のGoogle Playの売上げは日本が1位だった。
1位はLINEなので日本か韓国かと言われると微妙だが。

50ドル携帯でNext Billionへ。iPhoneはここに追随できない。

日本のAndroidアプリ開発者の課題。
スタンドアロンでなくクラウドと連携したアプリを。

次回の日本Androidの会の定例会はGoogle Glass。

ネイティブとHTML5をスマートに連携させる設計と実装のノウハウについて

http://www.slideshare.net/kazuakihidaka/html5-22091660

クックパッドのひだかさん。（@kaaさん）

ゲーム以外のハイブリッドアプリについて。

以下の話はしない。
・WebアプリかNativeアプリか。
・ゲーム環境としてのHTML5、Unity。
・ソーシャルゲームの話。
・コードの話。

クックパッドはPCよりモバイルの利用の方が増えている。

アプリの環境の流れ

端末のスペックが上がったのが大きい。
WebViewでも、アプリとして許されるかなという一定のレベルで動かせるようになった。
HTML5の仕様も固まってきた。
iOSのUI面での審査も緩くなってきて、アプリ独自UIもやりやすくなった。
やっとAndroidのOS分布も変わってきた（新しいOSが主流になってきた）。

ハイブリッドアプリのタイプ

ハイブリッドアプリはネイティブとHTML5の中間のような捉え方をされているが、実際のところはどうか。
このプレゼンでは、ハイブリッドアプリ＝HTML5を生かしたアプリとする。

ハイブリッドアプリは公式マーケットで配布が可能で、複数プラットフォームに対応しやすい。
ハイブリッド＝技術を組み合わせる、nativeとHTMLを組み合わせる。

ハイブリッドアプリの3つのタイプ。

1つ目はWebViewをラッピングしたアプリで、かつアプリはWebViewを包むためだけの位置付け。
「がわnative」とも呼ばれる。

コンテンツ（HTML）はサーバに置く。
Webアプリをそのまま移植できる。
普通はAPIはJSONとかを使うが、それに比べて通信量が多いというデメリットがある。

2つ目はWebViewをラップするが、HTMLはアプリに埋め込む。
サーバとはAPI通信を行わない連携。
ローカルでもある程度動かせる。
アプリのnative実装の代わりにHTML5を使う。

3つ目は、一部の画面でWebViewを利用する。
基本的にはnaativeアプリで実装するがWebViewを利用することでメリットのある画面はWebViewを使う。

これら3つのうち、クックパッドは1と3のハイブリッドである。

今日中心に話すのは3つ目。

大事な方針

「とりあえずHTMLで」ではなく、どちらでやった方が価値がある画面なのかを判断する。
画面遷移図を見ながら、画面毎に判断する。

価値とは何か？
できあがる物の品質。HTMLでやらない方が良い画面、（実装者の）モチベーションが下がる画面もある。

実装コスト。
HTML5にすることでどれだけ楽になるか、他に予算を回せるようになるか。
また、AndroidとiPhoneで共通で使える部分があればコストが下がる。

運用コスト。
データの更新頻度がどのぐらいあるか。
例えば週1で更新するとしたら、nativeでは当初の設計で盛り込めないデータが出てくるがHTMLでは柔軟に対応できる。

WebViewが適さないもの

リストや、画像のサムネイルが並ぶようなギャラリー画面。

AndroidもiPhoneもリスト用のビューがある。
なぜそれがあるかと言えば、それがないと快適に動かないから。
ずっとスライドしていったときの動きなどはnaativeのほうが考えられているし、nativeのほうが勝っている。

また画面をスライドさせていったときに次々読み込むが、HTMLだとDOMがどんどん大きくなってメモリがどうなるかとか。
（個人的メモ：画面から消えた領域のDOMを消す or 再利用とかそういう話ではない？）

あとは起動時の画面。（ここメモ追いつかず）

WebViewが適しているもの

詳細画面などのコンテンツ。

そもそもHTMLとはテキストなどの文章を見せやすくするためのもの。

HTMLのレイアウト能力の高さ、文字の回り込みや枠付け、リンクの挿入などはHTMLのほうが楽。

実装例1

WebViewの進む・戻る遷移とnativeの画面遷移（Activityのcreate/destory）の管理の問題が起きやすい。両方が噛むと混乱する。
従って、「WebViewでのリンク遷移はさせない」方針とするか、あるいは「遷移はWebViewで行い、native部分はダイアログ展開」。

実装例2

要素の長押しの処理やフリックの処理はJavaScriptで行い、Native側に通知。
Nativeの中にHTMLがある場合は、どちらがフォーカスを握っているのかややこしくなる。
このため、JavaScript側で処理したことがある。

補足。ログイン状態を連携させたいときはCookieを使う。

忘れがちな違い

HTMLのリンク遷移をしたときは、その都度ページをサーバ側から取得する。
Nativeでは何を取得するか決められるので、例えば一覧画面と詳細画面をまとめて取ってくることができる。
前者と後者を比べると、使ってみると変に読み込みが多いというような差が出てくる。

クックパッドの場合

サービスの性質として、もともとWebサービスなのでコンテンツはサーバ上にある。
ローカルに保存するものが本当に少ない。
更新も多いし、リアルタイム性もある。
特定の機能を提供すると言うよりは総合アプリという立ち位置。
ツール系のアプリだと操作性等が求められるが……。

ローカルで行っていること。
アプリ間連携用のアカウント情報管理。
レシピを載せる機能全般。
各種ダイアログやAPI通信。
検索時の候補、音声検索、ウィジェット。
Android独特の部分もやっている。

運用上の理由

細かく仮説・検証が行われている。
chanko http://bit.ly/cookpad2012

A/Bテスト、一部ユーザ向けテストをするための環境が整っている。

スマホサイト（iPhone？ ガラケー向けも含む？）とAndroidで共通のコンテンツがある。

まとめ

ハイブリッドアプリの幅は広い。
WebViewのレイアウト能力の高さや方針に対する汎用性・耐久性は大きい。
HTMLを表示するための道具でなく、TextViewのような見せるモジュールの一つとして捉える。
運用は大切。
仲間も大切。

ハイブリッドソーシャルアプリの現場

ポケラボ 鈴木さん、前田さん

iOSアプリのランキングでは上位だがAndroidのほうではそうでもない。
ここにハイブリッドアプリの弱みがある。

ポケラボは元はガラケー向けソーシャルゲーム開発が中心で、つまりWebエンジニアが多かった。
先行で出せたので、ソーシャルアプリの市場でユーザを獲得できた。
PHPエンジニアが多かった。

海外の投信ファンドから増資してもらう際、シリコンバレーで「iアプリはJavaリッチなゲームができるが、モバゲーやGreeでリッチなゲームができるのはなぜか、これからはWebか」というところで先人達の考えに共感した。

モバゲーでやっていたときの途中から競合が増えて、売上げが右肩下がりに落ちた。
そこでスマホへ進出した。

モバゲーの頃はFlashを使っていたが、スマホでは難しかった。
当初はSwiffyを使っていたが、今はCreateJSを使っている。

なぜハイブリッドアプリを採用したか、というよりはハイブリッドアプリを採用せざるを得なかった。

ハイブリッドアプリのメリットは、iPhoneとAndroidを1ソースで管理できること。かなり楽。

ネイティブアプリは映画を作っている感覚であり、がんばって作って大ヒットを狙うイメージ。
一方でソーシャルアプリはテレビやニュースのイメージで、常に新しい情報を発信してユーザが毎日訪れたくなるようにしなければならない。

イベントをやりたい場合、ネイティブではユーザに告知するのも難しいが、Webの場合は簡単。

WebViewって遅いのでは？
ポケラボでは、Canvas、CSS Animation、WebViewを適材適所で使っている。
CSS Animationでしんどい複雑なところはcreateJSで作っている。

ゲームでの具体例。

HTML5でのアバターシステム。
ボーンをどうやって作るか。HTML5でやりたい。
結果、Flashで作って、オブジェクトの位置を配列で出して、createJSで作った。

増え続けるスキル演出。現在110個、次は+70以上。
requireJSを使用して、都度必要なファイルを読み込んでいる。
ただAndroid版はまだリリースできていなくて、その理由はWebViewが遅いため。

ここから前田さん。

ポケラボのエンジニアがAndroidでどういうことを目指しているか。
より速く、より快適に動作させること、ユーザに楽しんでもらうこと。

これを実現するための3つのアプローチ。

ハイブリッド固定メニュー

アプリに重要なヘッダーフッターの固定メニューを「overflow: scroll; とposition: fixed;」で実装。
でも端末によっては動かない……。
　
iScrollというJQueryのライブラリは、端末によっては遅い……。

ということで、WebViewで表示することをやめた。

ヘッダーフッター用のコマンドを用意し、それをnative側で受け取ってnativeのViewとして表示することにした。
Android native上で「http://header/json〜」のようなコマンドのパラメータを解析して表示する。
コマンドをWebページ上で指定し、Android側とiOS側のそれぞれでnativeでヘッダーとフッターを表示する。

ハイブリッド高速アニメーション

そんな高速なライブラリはなかった。

基本はハイブリッド＝Web。
そして、リソースは今あるものを使いたい。

そこで、FlashからJavaScriptへ変換し、さらにそれをAndroidへ変換するという2段階変換を行った。
JavaScriptでnative用のコマンドを作り、ネイティブ側で受け取ってネイティブのCanvasで描画する。
これによってWebViewの3倍で描画できた。

iOSとのUUID連携

AndroidのUUIDは使えない。

UUIDは重複しない値。
Androidで作るためにはUUID.randomUUID().toString()で簡単、だが、アプリをアンインストールするとUUIDも同時に削除されてしまう。

そこで「ポケラボネットワークシステム」を利用して必ず1端末1IDとなるようなキーを生成することにした。
これを使うことで、端末／アプリに関係なくコラボ連携することが可能になった。
外ではAndroid、家ではiPadで互いにデータを引き継げるというような。

Androidにはまだまだ課題がある。

パネルディスカッション

モデレータ：新野さん
丸山先生、佐々木さん、白石さん

（新野さん）
Google I/Oの印象は？

（丸山先生）
今年は外れて行けなかった。
印象としては地味だったが、次へのタメか。
Packaged Appsは充実していた。

（新野さん）
僕もそれに注目して基調講演を見ていたが。

（丸山先生）
確実な確度で、今年中にAndroidとChromeの統合の姿が見えてくるだろうと思っている。

（新野さん）
佐々木さんは？

（佐々木さん）
Tizenの開発機はスコアが492で良いスコアになってきている。
海外ではS3はローエンド機種になってきていて、S4がメイン。
TizenカンファレンスではHTML5関連の展示も多くあって、MID、2003〜2004年頃のものは動く感じ。
一方でHugeなアプリを動かそうとすると厳しい。
大きいWebGLのアプリだとPCのChromeではよく動くようになったがモバイルではきつい。
でもGalaxy S4では結構動くようになってきたので、あと2〜3年後には今のChromeで体験できるるようなことがモバイルでもできるようになるかもしれない。
　
（新野さん）
佐々木さんの立ち位置は？

（佐々木さん）
AndroidもiOSもやっているが、今一番熱いのはTizen。

（白石さん）
Google I/OではHTML5等のセッションに参加した。
いろいろ目に付いたのは、パフォーマンスを高速化しようとか、Chrome Packaged Web Apps v2とWeb Components、Polymer（http://www.polymer-project.org/）というフレームワークが出てきた。
UIコンポーネントはネイティブでは結構揃っているがWebではなかった、これを埋めていくのがWeb Components。

WebアプリケーションのプラットフォームとしてAndroidやモバイルデバイスのこれから

（新野さん）
丸山先生の先ほどのプレゼンで、統合してよりよいプラットフォームにという話があったが。

（丸山先生）
AndroidのHTML5対応は恥ずかしいほど遅れている。
Chromeが動くようになったのは4.0からで、まだ全Android端末の半分ほど。ただこれを標準になるように進めている状況。
Chromeのランタイムがあれば動くような世界を考えていて、それはサーバサイドのWeb AppのようにWebを通じてインストールしていくタイプのアプリでなく、パッケージするタイプが今年の大きな流れになるだろうと考えている。
まだ姿は見えないが、Chromeベースのマーケットは既にあるし、それがAndroidにも入ってくるのではないか。
デバイスの違いで悩んでWebがほしかった、というだけでなく、Packaged AppsはWindowsでもMacでもLinuxでも、もちろんChrome（OS？ Android？）でも動く。
いろいろな問題はあると思うが、流れとしてはおもしろい。

（佐々木さん）
うちの会社的にはPhoneGapのようなエンジン、OpenGLのようなゲームエンジンなどを作ってきていて、パッケージをnativeのように発信している。
その時にベンチマークを取っているが、今のWebでネイティブのようなアプリを作ることはまだ無理。だが、S4では結構いい。

OpenGLで書くと移植が楽。
iOSとAndroidで動いているもの、C++で書いているが、これをTizenへ移植するのは2日ぐらい。適材適所で使い分けるようになる。
iOSでは、動的なランタイムのロードを規約で禁止していてこれはネック。

（新野さん）
これまではWebで作るのが遅かったからOpenGLを使っていたが、Webが早くなってきたからWebになるということ？

（佐々木さん）
将来的にはそうだが、やはり適材適所。3年ぐらいはネイティブとWebの間が続くのでは。

（新野さん）
どのぐらい早い、あるいは遅い？

（佐々木さん）
今HTML5で3Dのゲームを作ろうとすると、Chromeでしか作れない。
これがすべての端末に入るのであれば、Webで作るという選択肢もあるかもしれないが。
但しリッチな3Dでなければそこまでのパフォーマンスは求められないので、そういう意味で使い分けが続くのではないかと思っている。
　　
（白石さん）
2〜3年ぐらい前からずっとわかっていたこととしては、Webアプリはスマホの機能を使い切れない、カメラを使ったりBluetoothを使ったり。
当時Device APIというものがあって、これで何かできるのではないかということを思っていた。
しかし時代の流れではそうではなく、インストール型のアプリとホスト型のアプリに分かれた。インストール型はカメラやBluetoothにアクセスできるが、ホスト型は従来とあまり変わらない。
Geolocationは例外だが（ホスト型でも使えるが）、時代の流れとしてそうなってきている。

（新野さん）
同じHTML5のテクノロジを使っていても、インストール型とホスト型では分かれる？

（白石さん）そうなってきている。
インストール型のほうはMozillaがSysApps（補足：W3CのSysApps WG）で標準化を進めていて、一方でGoogleのほうは独自で行っている。I/Oの中でも質問されていたが、標準化はしたいがごにょごにょという感じ。
それぞれでBluetoothやRaw Socketで似たようなもの（API）が出てきていて、そこはSysAppsのほうが先行しているので、そこが標準化してくれると嬉しいと考えている。
　　　
（丸山先生）
SysAppsは、昔キャッシュを使おう、Widgetがあって、そこからPackaged Appsへ移った。Chrome、Firefox OS、Tizen、みんなバラバラである。
おそらくTizenがWidgetのマニフェストで標準に近い。
しかしChromeのPackaged Appsのmanifest.json？？（メモできず）

白石さんと異なる意見もあって、HTML5の標準化は必要。
しかしデバイスレベルのところは標準化がイノベーションに追いつかないところがあって、いろいろな試行錯誤があることを考えると、先に標準化で1〜2年を費やすというのは悲観的。
HTML5では綺麗に標準化を進めるが、新しい技術のところはFirefox OSやChromeが目を瞑って？？（ここもメモできず）

HTML5のCanvasやSVGに対して、OpenGLやネイティブアプリの動向は？

（新野さん）
Packaged Appsを考える上で、業務系アプリなら結構作れるが3D系だとグラフィックが足を引っ張っているといったことがある。

（佐々木さん）
Canvasはあまり使わない。アプリを書くときはWebGLを使う。
画像をクルクル回転させたり拡縮をしたりということをリアルタイムにやりたいが、これらはCanvasでできることを越えた表現。WebGLはnativeで下のレイヤに落としているので早いし、複雑なことをやろうとするとそちらのほうが適切。
ただiPhoneのほうは（動的ロードの？）許可が下りていないし、Androidのほうも難しい。例えばソニーの端末では動くが他では動かないとか。そういうところもあって独自のランタイムを作ったりした。
海外のいろいろな会社と会ったが、皆WebViewは使っていない。nativeの（独自の）ランタイムエンジンとHTML5とCSSをパッケージングしてやっている。

（新野さん）
自分でエンジンを作っている？

（佐々木さん）
そう。V8エンジンとかを使って、ネイティブの処理はGPUに落としてという形で。それが主流。
WebGLはだいぶ動くようになってきたが、古い端末をどうするか。これは悩ましい問題で、やはり独自ランタイムを使う形に落ち着く。
CoronaとかUnityを使えばスクリプトでサクサク動くものが作れるし、そういうソリューションができるようになっているので、そういうものも追わないと行けない。

（新野さん）
再確認だが、今の話は一般のアプリでなく3Dとかのハイエンドのアプリの話？

（佐々木さん）
そう。その辺で困っている。

（新野さん）
白石さんはCanvasについてどう思っている？

（白石さん）
バリバリに使ったことはないが、そこまでのパフォーマンスを求められることもそうそうない。また、個人的にはCanvasを選択するのは最後の手段で、DOMでどうにもならないときに使うようなものと思っている。

（新野さん）
自分はサンデープログラマ的に自作でグラフのライブラリを作っている。商用のものも含めて試したがすごく遅くて、Canvasで同じものを書くとGPUに乗るのですごく早い。
普通のビジネスチャートだが、ライブラリの書き方によってGPUに乗る場合と乗らない場合があって、乗ると100倍ぐらい早い。iPad＋PhoneGap（WebView）で確認しているが、どういう場合に乗る、乗らないというノウハウが足りなくて、そういうノウハウの蓄積が必要ではと考えている。

（白石さん）
つい最近作ろうと思っていたのが、WebRTCから取って加工しようという処理。
大抵のものはCanvasでリアルタイムで使い物にならず、唯一使えたのがGLXGL？（たぶん綴り間違い、メモし損ね）で、名前から推測できるとおりWebGLを使っている。
そうしたことを考えると、（Canvasでなく）WebGLに焦点を絞るのもありか。

Webアプリ≒ハイブリッドアプリの進化とは？

（丸山さん）
エンタープライズがWebに与えたインパクトが大きくて、それが10年ぐらい続いた。
クライアントで処理するのであれば、HTML5を使おうがネイティブを使おうが構わなくて、それよりはサーバの負荷を下げる方が重要。まだまだHTML5だけではパフォーマンスが、というところはあるが、それを一つのソースで書けばOS等に関係なしに動くというのは綺麗だし……

（佐々木さん）
端末をいろいろ評価してきてわかったのは、チップレベルで評価しないと難しい。Tizenはチップレベルで最適化を始めていると言うことをやっている。Galaxy S4でChrome Betaを使うとグリグリ動く。
ある程度チューンアップが終わったら、ネイティブで書かなくてもいいかなと思っている。

ネイティブはフルフルで速度を出せるが、それが書けるエンジニアを探してくるのがまず大変で、最後は誰でも書けるようなところに落ちていくと思う。願望として、そういう時代は3年ぐらいで来ると思っている。
C++はnativeでビルドしているが、HTML5は動的にいろいろなものを持ってくることができる。そういうことはWebの世界でしかできないのでその方向で進化するのがよいと思うし、技術的にHTML5の方が面白い。

（白石さん）
自分のセッションの中でWebアプリでできないことをいろいろ言ったが、そこをどうにかしようと考えている人が大勢いる。
例えばスピードが遅いというところで言えばasm.jsで、ネイティブの2倍（1/2？）程度の速度は出せる。インストール型のアプリであれば（OSレベルの？）使い切れるようにしようとか、Webアプリの世界は明るいかなと考えている。
足を引っ張り続けているAppleはどうなるのかなと考えている。

（丸山さん）
AndroidのプラットフォームがWebの世界で一番大きいと思っている。

（佐々木さん）
TizenやAndroidのアプリの開発イベントをUDXでやるので、興味がある人は参加してほしい。