ふろしき Blog

コンテンツサービスを科学する株式会社ブートストラップ代表のブログ

HTML5ハイブリッドアプリ開発を支えるOSS「Cordova」はどのように課題を克服し、進化するのか?

本記事は「HTML5ハイブリッドアプリ開発を支えるOSS『Cordova』シリーズ」の続編です。前回に引き続き、2014年6月10日に開催された「第1回Apache Cordovaスーパー勉強会」にて、アシアル株式会社の田中正裕氏が行なった講演のダイジェストをお届けします。

まだまだ進化を止めないApache Cordova

ハイブリッドアプリも日々進化しています。3年前はPhoneGapもようやく1.0という状況でしたが、それも今ではCordova3.5ということで、ここに来るまで相当な進化があったんです。

f:id:furoshiki0223:20150204170353j:plain

3年前に、僕が初めてPhoneGapを触った時、iOSも4.2で、CSSもまったく充実していませんでした。Androidも当時は2.2だったのですが、あれからAndroid自体のパフォーマンスが改善されてきました。

Cordovaもプロジェクトが大きくなって、やれることも増えてきました。ここで、最近どういう動向があったのかをご紹介します。

ハイブリッドアプリの新たな姿「WebView内包アプリ」とその進化

f:id:furoshiki0223:20150204170354j:plain

従来のハイブリッド開発は、OS付属のWebViewを活用するというものでした。最近はそうではなく、自前のWebViewを内包して開発しようというアイデアがあります。その内包するためのWebViewとして、僕がいま注目しているいくつかのプロジェクトがあります。これらは、今のハイブリッドアプリの制約を改善する可能性を秘めていると考えています。

ChromeのエンジンであるBlinkは、パフォーマンスが高くてキビキビ動きます。これをCordovaへ取り込もうということで、IntelがCrosswalkというプロジェクトを進めています。そしてその取り組みが、今、最もポピュラーになってきています。ChromeのOSSプロジェクトであるChromiumをフォークすることで、彼ら独自のブラウザエンジンとして、Cordovaと互換性のあるものを作っています。Intelらしく、Tizenに対応しているのが強みです。OSSなので、サイトに行けばダウンロードして使うことができます。

ゲームという分野だと、LudeiというCocoonJSを開発しているアメリカのゲーム会社があります。彼らも同じ考えを持っており、WebView+というAndroid用のブラウザエンジンを作っています。Crosswalkと違うところは、WebGLという3DをレンダリングするためのAPIを有効にできるという点です。HTML5だと、どうしても苦手と言われているような3Dを改善しています。彼らのデモを見てみると、グリグリと動いていて面白いですよ。こちらはクローズドソースで、彼らの公開しているサーバ上でビルドすることで、使うことができます。

もうひとつはAmazonです。彼らもHTML5に対する動きはすごく活発で、Amazon Silkという、Blinkベースのレンダリングエンジンを開発しています。これは、Kindle Fireという彼らの製品の中に組み込まれています。使い方は、CrosswalkやWebView+とも違っています。Cordovaで作ったアプリをAmazonで販売する場合に申請して、ソースコードをアップロードすると、Amazon Silkでビルドされリリースされるという仕組みになります。

「WebView内包アプリ」にはどのようなメリットがあるか?

f:id:furoshiki0223:20150204170355j:plain

彼らの取り組みには、色んな利点があります。

HTML5を使えば一つの知識でいけるなんて言われますけど、環境によっては対応しているCSSのプロパティが全然違っていたり、JavaScriptの構文にもAndroidのバージョンによって差があったりします。そういうものを、ブラウザエンジンを内包して一つのアプリとして提供できるようになれば、フラグメントという問題もAndroidにおいては無くなります。

iOSについては、アップグレードが浸透しており、iOS7が今の時点でもう既に90%以上の方に使われています。そのアダプションを考えると、今のウィークなポイントは、Androidの2.3とか4.0が未だに多くのユーザに使われているというところです。正直、Chromeのブラウザエンジンを内包するという方式は、Androidの4.0以上でないと対応できないためネックになっています。ただ、Androidの2系が無視できるような状況になると、4.0以上がシェアを占めるため、一気にハイブリッドアプリを作る環境が改善されると考えています。

もう一つの利点としては、Chromeのエンジンを内包できることで、Chrome Dev Toolsが利用できるという点です。従来のCordovaだと、デバッグにはやや特殊な方法が必要だったりします。しかしChromeのエンジン、もしくはそれに類するものを内包できると、Chrome Dev Toolsが利用できるので、AndroidをUSBで繋いで、Cordovaのアプリをデバッグできるようになります。この方式が普及すると、ネイティブにあったような端末の依存性問題も、ディスプレイのサイズやリゾリューション程度になるので、モバイルアプリ開発はかなり改善されるのではないかと期待しています。

また、Chromeは昔とくらべてかなりパフォーマンスがよくなったので、このエンジンを内包することで、パフォーマンスの向上がかなり期待できます。また、Chromeのエンジンは最新のCSSに対応していたりとか、高速なJavaScriptエンジンが使えるというのもメリットとして大きいでしょう。

デメリットとしては、先ほどもご説明した通り、Android 2.Xに対応していないというのがあります。また、ファイルサイズが大きいという点も大きいでしょう。8MBから十数MBぐらい増えてしまいますので、これでは起動時間が長くなってしまいます。しかし、みなさんがもしChromeアプリを使っていて、それでストレスを感じないというのであれば、やっていることはあまり変わらないので、大丈夫ということになります。これはそんなに問題ではないのかもしれません。

f:id:furoshiki0223:20150204170356j:plain

iOS8で、新しいWebViewがでます。これまで、iOSはUI WebViewというブラウザエンジンを提供しており、AppleはSafari以外それを使うことしか許していませんでした。そしてそのWebViewが、iOS8からはWKWebViewに変わります。名前から察しがつくかもしれませんが、WKはWebKitの略です。

私たちが評価してて、このWKWebViewはすごく良いと感じています。例えば、WebGLが標準で使えるようになっていたり、あとIndexDBというクライアント上で扱えるデータベースの機能が、なぜかWKWebViewだけ使えるようになっていたりします。一番面白いのが、今までSafariにしか許してくれなかったJITの実行エンジンを、Appleが開放してくれたことです。sunspiderという有名なベンチマークで動かすと、UI WebViewだとだいたい4秒ぐらいかかるのですけど、WKWebViewだと1秒切るんです。iOS側もハイブリッド開発がどんどん改善が進んでいます。

「JavaScript UIフレームワーク」の進化

次に、ユーザインタフェースを作るためのフレームワークについてです。

f:id:furoshiki0223:20150204170357j:plain

jQuery Mobile」なんかは使われている方は多いのでしょうけど、アメリカだともう使われていなかったりします。最近は、新しいUIフレームワークがかなり台頭しています。

筆頭しているのが、Driftyという会社が作っているAngularJSベースのフレームワーク「Ionic Framework」です。結構スムーズに動くんです。弊社でもやっている「Onsen UI」も同じコンセプトでして、アメリカでもかなりウケがいいです。AngularJSベースのWebComponents、ディレクティブというんですが、そういうものを使ってタグだけで画面のコンポーネントを作って、ビジネスロジックは全部AngularJSのコントローラーで作るようになっています。

3つめが異色ですけど、「Famo.us」というフレームワークがあります。彼らは少しアプローチが違っていて、CSSのGPUが使えるマトリクスとかを駆使して、できるだけ高速にレンダリングできるようにするという、そいういうフレームワークです。

jQuery MobileはjQueryブランドの安心感があるのですけど、PhoneGap1.0が出るよりも前という、CSSも全然無いような時代に作られたフレームワークです。スクリーンのトランジションの遅さとか、ウィジェットのレスポンスなんかが、やっぱり前世代的な感じなんですね。なので、こういったものも、一度評価に入れてみてはいかがでしょうか。

f:id:furoshiki0223:20150204170400j:plainf:id:furoshiki0223:20150204170401j:plain

Cordovaのアーキテクチャの進化

デバイスAPI/ネイティブの機能。3つめのトレンドとして、Cordova Plugin Registryです。

f:id:furoshiki0223:20150204170358j:plain

実は、Cordova 3.4から、かなり大きな仕様変更がありました。Cordovaにはコアの部分と、カメラとか電話帳とかネイティブの機能にアクセスするモジュールの部分に分かれています。従来そのモジュールの部分は、Cordovaの中に含まれてました。それが3.4から、Plugin Registryに分離されました。

これには2つの狙いがあります。一つは、プラグインに分離させてしまうことで、プラグインだけで独自に進化することを促せるということ。もうひとつは、プロジェクトを進めていくと、いらないObjective-Cなどのコードが増えていくので、本当に必要なものだけを取り込めるようにすることです。

結構色んなプラグインが登録されています。

f:id:furoshiki0223:20150204170359j:plain

最後に、我々はCordovaを盛り上げようと思っているのです。しかし、我々だけではやはり弱い所がありますので、是非、一緒に盛り上げていきましょう!今日はどうも、ありがとうございました。

本連載の最後に ーーーー

3回の連載にわけてみましたが、いかがでしたでしょうか。Cordovaを愛し知り尽くした彼は、Cordovaの開発を楽にできるようにと、「Monaca」というツールを開発しています。これを使えば、彼は来年以降もっといいメシが食べれて、Cordovaにコミットするモチベーションが上って、みんながハッピーになれるわけですね!

本記事のソース「Apache Cordovaスーパー勉強会」は割と評判が良かったため、第二回を開催する予定です。よさ気なネタがありましたら、TwitterなどのSNSで、気軽に私に話しかけて下さい。お待ちしております。

(※写真がボケてしまいましたが・・・、左上が田中正裕氏、左下が筆者)
f:id:furoshiki0223:20140719184253j:plain

HTML5ハイブリッドアプリ開発を支えるOSS「Cordova」のこれまでの進化、そして課題とは?

本記事は「HTML5ハイブリッドアプリ開発を支えるOSS『Cordova』シリーズ」の2本目です。前回に引き続き、2014年6月10日に開催された「第1回Apache Cordovaスーパー勉強会」にて、アシアル株式会社の田中正裕氏が行なった講演のダイジェストをお届けします。

Cordova派生の製品がいくつも登場、どのように差別化が進められてきたのか?

元々は、PhoneGapという製品を中心に色んなエコシステムがあったのですが、Cordovaというオープンソースに変わったことで、そこから派生して色んなプロジェクトが各社によって作られています。

f:id:furoshiki0223:20150204170757j:plain

例えば、IBMのWorklight Projectも、Cordovaから派生したディストリビューションです。GoogleのChrome AppsというPC上でアプリを動かすプラットフォームがあるのですが、それのモバイル版「Google Chrome Apps Mobile」もCordovaがベースです。Chrome Appsで作ったアプリはCordovaで動かせるんですけど、そのままじゃ動きません。Chrome Apps用のAPIというのがありまして、例えば、GoogleにログインするためのAPIとか、WebSocketサーバになるような機能とか、そういう拡張をGoogleはCordovaプラグインとして作っています。

最近ではMicrosoftのVisual Studioが、Cordovaに対応しました。Visual Studioで、HTML5を使った、iOSアプリが作れるのです。凄い時代ですね。あと、最近日本でも火がつきつつあるIonicフレームワーク、HTML5を使ってヌルヌルに動くネイティブアプリを作るためのこういうツールも、内部ではビルドエンジンとしてCordovaが使われています。弊社が作っているMonacaとかOnsen UIみたいなツールもあるんですけれど、これもCordovaに準拠しています。

これらのツール/フレームワークは、何が違って何が同じかと言われると、最終的に作られるアプリは全て同じで、何の違いもありません。ただ、各社独自のアドインを開発し入れているという点で、大きく異なります。エンタープライズ向けの製品だと、エンタープライズニーズにあった各種プラグインを作っていたり、Google Chrome Appsだと、先ほど説明したようなプラグインを作っていたりします。弊社のMonacaでも、ネイティブの機能を扱えるようなプラグインを提供しています。

モバイルWebとハイブリッドアプリの違いは何か?

HTML5を解釈するブラウザエンジンについて、モバイルブラウザとCordovaとでは微妙に異なります。

f:id:furoshiki0223:20150204170758j:plain

モバイルブラウザでURLを打ち込んで表示するWebアプリは、iOSだと、Safariと、Safari以外に分かれます。例えば、Safariと、iOS上で動くChromeは、異なるブラウザエンジンで動いていたりします。Appleはモバイルで扱うブラウザエンジンに、特殊なフラグをつけているのです。iOSでは、Cordovaを含むサードパーティベンダの場合、内部的にはWebViewを使ってWebアプリを表示します。SafariはJITなどの機能によって、JavaScriptを高速化させるような仕組み(Nitro)が入っているのですが、iOSのWebViewはそれが無効化されています。

Androidも、微妙にややこしいです。AndroidにもiOSのような標準ブラウザが入っているのですが、Android版のFirefoxやChromeでは、内部的でそれを使っていません。では、iOSと同じようにWebViewを使っているのかといえばそうでもなく、FirefoxはFirefoxの独自のエンジン、ChromeはChromeの独自のエンジンで動いていたりします。そしてCordovaは、FirefoxやChromeが使っていない、Android標準のWebViewを使っています。WebViewはAndroidのバージョンに依存していて、例えば、Androidの4.1、4.2、4.3と、バージョンごとに対応している機能に違いが表れます。対してChromeは、Androidのバージョンに関係なく、Chromeのバージョンに機能の違いがでます。

こうした背景から、Cordovaの対応している機能は、Cordovaのバージョンに関係なく、動作させているOSのバージョン、WebViewの機能に依存します。Cordovaだから対応機能が少ないとか、そういうことはありません。ただ、Cordovaがモバイルブラウザと大きく違うところがあります。それは、JavaScript APIが拡張できること、Same-origin Policyのルールが異なることです。

ブラウザは、JavaScript APIの拡張ができません。しかしCordovaは、自分たちで好きな機能を持ったJavaScript APIのプラグインを作ることで、ネイティブの機能を利用することができます。Same-origin Policy、セキュリティについても、ブラウザの場合はブラウザのルール、HTTPヘッダで指定されたルールが適用されます。対してCordovaは、基本的に自由でどこにでもアクセスし放題です。制限を加えたい場合、config.xmlにて、どの外部URLを許可するかを、ホワイトリスト形式で設定できるようになっています。

結論を言えば、APIレベルではモバイルWebとハイブリッドアプリは同じです。よって「Webアプリ≒ハイブリッドアプリ」ということになります。ではなぜ「ハイブリッドアプリは違う!」と言われているのか。それは「HTML5アプリとネイティブアプリの違い」ここに全てが始終します。

これまで、ハイブリッドアプリが抱えてきた課題は何か?

HTML5ハイブリッドアプリは、これまで説明してきました通り、ブラウザエンジンの上で動くことになります。一方で、ネイティブアプリにはそんなものはなく、OSが直接アプリを動かします。このため、アプリの作りから動作の仕組みまで、全く違っていたりします。

f:id:furoshiki0223:20150204170759j:plain

HTML5アプリを、ネイティブアプリの感覚で作ると問題になります。世界が違うのです。ユーザインタフェース、これが一番よく言われます。HTML5でどうやってネイティブアプリのようなスムーズなUIを作るのか、これが一番私が受けることの多い質問です。そもそも、どうつくればいいのかわからない、これが一番多い悩みではないかと思います。

そして2つ目。やっていてジワジワと感じてくるのが、実行するパフォーマンスが違うという点です。例えばネイティブアプリの開発をした人なら、ビューなんかを10個ぐらい重ねてとか、トランジションでスクリーンを動かしてとか、アクティビティを作ってとか、ネイティブの要領で、頭のなかでやることがイメージできて実装ができるでしょう。しかしこれがHTML5なので、ビューもトランジションもアクティビティも無くて、そもそも世界が違うので、従来のパフォーマンス改善のノウハウが全く使えなかったりします。結果として、画面がもっさりとして、ストレスを感じるということになるのです。

3つ目が、セキュリティです。ここについては、大分改善されています。Webアプリと同じなので、JavaScriptが読めてしまうという問題ですが、難読化の技術がでてきていますね。ただそもそも、ネイティブも別に意図的に難読化をしているというわけではないので、例えばAndroidのclassなんかも、逆コンパイルすれば解読できますよね。

最後に、デバイスのAPIとか、ネイティブのAPIを呼びたいという点です。これについては、さきほども紹介しましたが、JavaScript APIを作って、その中からネイティブのAPIを呼ぶということができます。パフォーマンスも、悪くありません。ただ、AndroidなどのネイティブのAPIを、全てJavaScriptのAPIに紐づけて作るということはしないので、これが悩みに繋がったりします。ビジネスロジックには依存しない、端末に依存する処理だけを、JavaScript APIの呼び出し先でネイティブのコードとして作らなくてはいけないため、このあたりの作り方に、慣れが求められます。

>>【次回(最終回)】HTML5ハイブリッドアプリ開発を支えるOSS「Cordova」はどのように課題を克服し、進化するのか?

HTML5ハイブリッドアプリ開発を支えるOSS「Cordova」はなぜアツいのか?PhoneGapとの違いは何か?

ハイブリッドアプリとは何か?なぜ今、Cordovaがアツいのか?

iPhoneにAndroid、WindowsPhoneと、モバイルデバイスは混沌としており、「ネイティブアプリ」の開発には高いコストが必要とされます。一方で、ブラウザを活用した「Webアプリ」は、パフォーマンスやデバイス制御に大きな制約がつきまといます。このような、ネイティブアプリとWebアプリの互いが持つ問題点を補う手段として、「ハイブリッドアプリ」と呼ばれる開発方法が注目を集めています。

f:id:furoshiki0223:20150204171017j:plain

ハイブリッドアプリの実現手段には、OSSの開発ツール/フレームワークである「Cordova」が有名です。HTML5の活用することで、ひとつのソースコードからiOSやAndroidなどの複数のモバイルOSに対応させることができ、またネイティブアプリが持っているポテンシャルを活かしたアプリ開発ができます。その起源は、2011年にAdobeがNitobi社を買収し、同社が開発していた「PhoneGap」を、Apache Foundationへ寄贈したことから始まります。ApacheではCordovaというブランド名が与えられ、現在はGoogleなどの他社のエンジニアも一緒になって、改善が進められています。

ハイブリッドアプリが騒がれだした初期の頃は、Appcelerator社の「Titanium Mobile」が有名でした。エンジニアの間でも、ちょっとした熱気のようなものがそこにはありました。しかし、AdobeがNitobiを買収し、PhoneGapをOSS化した2011年以降、瞬く間にCordovaへと流れが移っていきました。最近では、OracleやIBM、SAPにMicrosoftと、様々な大手製品ベンダが提供するモバイル開発ツールで採用されています。事実上、エンタープライズ・モバイルのWebプラットフォーム市場では、デファクトスタンダードと呼べるほどの存在感を持っています。

「Apache Cordovaとは何か?」「Apacheへ寄贈後も、Adobe側で未だに維持し続けているPhoneGapとは何が違うのか?」そのことについて、古くからCordovaと繋がりを持つアシアル株式会社の田中正裕氏が、2014年6月10日に開催された「第1回Apache Cordovaスーパー勉強会」にて行なった講演が非常に参考になります。

f:id:furoshiki0223:20150204171015j:plain

本記事では、その講演のダイジェストをお届けします。

Cordovaはどのようにして生まれたのか?

Cordovaとは、カナダのバンクーバーに実在する、ストリートの名前です。そしてそのCordova通りには、Nitobiという会社がありまして、PhoneGapというハイブリッドアプリ製品を作っていました。

f:id:furoshiki0223:20150204171016j:plain

PhoneGapは、Adobeさんに買収されたタイミングで、Apacheに寄贈されることになりました。その際、旧Nitobiの開発チームは、そのOSSに自分たちとゆかりのある名前を付けたいという想いを持ち、Nitobi社があるストリート名「Cordova」の名前を与えました。元々AdobeにはCallbackというプロジェクトがあったのですが、1〜2ヶ月ぐらいでCordovaという名前に変わってしまいました。

僕はエンタープライズの受託開発を行なっているシステム開発会社の人間でして、ハイブリッドアプリは僕たちのようなエンタープライズのエンジニアをハッピーにしてくれると思っています。僕自身も、Nitobi社のPhoneGapの時代から付き合いがあり、OSSとなったCorodovaには積極的にコミットしています。日本の端末ベンダさんとの調整なんかも大変なのですが、自分たちが扱っているうちにバグが見つかりますので、その修正を行なったりして、一緒にCordovaを育てています。

OSSとして開発が進められているCordovaと、買収後にAdobeから提供されるようになったPhoneGapの違いは、とても些細なものです。まずは、その違いについてご紹介します。

Cordovaの「コマンド」にどんな違いがあるのか?

f:id:furoshiki0223:20150204171018j:plain

Cordovaで開発をする場合は「cordova」というコマンドを使います。対して、PhoneGapで開発をする場合は「phonegap」というコマンドを使います。どちらも「node.js」で動作するアプリケーションで、どちらも「cordova libs」というライブラリに依存しています。要するに、どちらのコマンドも、cordova libsというコマンド集を叩いているだけのラッパーです。ただ、phonegapにはそこに+αの機能を追加しています。phonegapコマンドは内部的に、cordovaコマンドを使っていると考えて良いでしょう。

f:id:furoshiki0223:20150204171019j:plain

コマンドの違いを、参考程度にまとめてみました。phonegapコマンドは、「PhoneGap Build」というAdobeさんのビルドシステムを持っており、そことのインテグレーションがされています。具体的に言うと、remoteというコマンドがついてまして、例えば、"phonegap remote build"みたいな感じでコマンドを使うと、Adobeさんの提供しているサーバへソースコードを送り、ビルドされて返ってきます。だから、ローカルにビルドできる開発環境を持っている場合は、CordovaとPhoneGap、どちらでも良かったりします。結果的に出来るアプリは、どちらを使っても同じです。

コマンドの使い方について。ハイブリッドアプリは少しややこしかったりします。ハイブリッドアプリでは、HTML5で作ったソースコードを、シェルと呼ばれる、AndroidやiOSなどの各OS専用のソースコードの中に埋め込み(=prepare)、各OSごとのツールでコンパイルして(=compile)、各OS専用のインストールイメージを作ります。このprepareとcompileをくっつけたのが、buildです。buildできたインストールイメージを、デバッグするためにエミュレーター上で動かしたり(=emulate)、デバイスにインストールして利用したり(=install)、という使い方になります。

Cordovaの「定義ファイル(設定)」にどんな違いがあるのか?

「config.xml」という、アプリケーションの定義ファイルがあります。W3CにはWidgetというスペックがあり、ハイブリッドアプリの標準仕様として定義されています。CordovaやPhongapの、独自の仕様ではありません。

f:id:furoshiki0223:20150204171020j:plain

Cordovaのconfig.xmlには、W3Cで定義しているような設定しかありません。対してPhoneGapのconfig.xmlについては、Adobeさんでネームスペースまで作って、大量の設定情報が追加されています。PhoneGapはCordovaと違って、PhoneGap Buildによるリモートでビルドを行う仕組みがあるのが原因です。リモートだと、iOSやAndroidなどの固有のソースコード(シェル)に一切手をいれることができないので、config.xml側で細かいカスタマイズの指定が行えるようになっているのです。

その他、どんな違いがあるのか?

f:id:furoshiki0223:20150204171021j:plain

CordovaコマンドとPhoneGapコマンドで、バージョンが同期していなかったりします。例えば今の時点では、Cordovaは3.5が使えるんですが、PhoneGapはまだ3.4しか使えません。理由は、PhoneGap Build側が対応していないからです。

ネイティブコードの書ける範囲も異なっていまして、PhoneGap Buildはサーバ上でビルドを実行することになるため、シェルに手を加える事ができません。CordovaだとCordova WebViewというのを使って、iOSやAndroidなどの固有のネイティブのコードを埋め込めるのですが、PhoneGapの場合は、PhoneGapプラグイン・Cordovaプラグインを通じてでないと、ネイティブのコードが埋め込めません。

今の説明は、どちらかと言えばCordovaとPhoneGap Buildです。CordovaとPhoneGapの違いというものではありません。PhoneGapの場合は、「PhoneGap Enterprise」や「PhoneGap Developer App」と呼ばれる開発ツールをAdobeさんが提供していたりするので、そういうのが使えたりします。

>>【次回】HTML5ハイブリッドアプリ開発を支えるOSS「Cordova」のこれまでの進化、そして課題とは?

エンタープライズでも広がる、フルOSSでHTML5-RIAなWeb開発

本稿は、2013年11月16日開催、オープンソースカンファレンス2013 福岡の講演資料の説明です。以下のスライドを使って説明したものを、補足しながら文章ベースに書き起こしました。


HTML5で脅かされたRIA

HTML5の登場で、Webブラウザは単なるドキュメント表示のツールから、アプリケーションプラットフォームへと姿を変えました。もちろんそれ以前から様々な技術は出現していましたが、HTML5のインパクトは大きく、Webブラウザそのもののあり方を変えてしまいました。

2010年以降、色々な事件がありました。特にAppleショックが大きかったと思います。これから伸びる市場でFlashは隅に追いやられ、気がつけばSilverLightもサポート期間を5年から10年に変更し、先が伸びるイメージがありません。

こうした中、プラグインでのRIA開発は、「今後やってはいけない」という印象を業界全体に広げたように思えます。

インターネット上のサービスでは、JavaScriptを活用してインタラクティブなコンテンツをたくさん生み出しています。しかし私たち業務系の人間は、一時的にRIAを実現する手段が失われたように思えます。FlexやSilverLightのようなベンダ製品は使いにくく、だからと言ってHTML5ベースなRIAを作るにもネット上サービスのようなハッカー紛いなことはとてもできません。

この時期、Stackoverflowで面白い記事を見つけました。「HTML5でRIAができるようなツールは何か無いのか?」と。その回答が、Microsoftにお金を払うことで解決されるという旨の記事でした。

実は探すと、ベンダ製品だといっぱいあったのです。注目されていたかどうかは別として、Web技術でRIA、実は作り放題だった。

自力でオレオレフレームワークなんてとてもエンタープライズ開発ではできないから、それこそStruts出現以前のJavaで私たちは既に痛い目をみているから、なかなか手をだせなかった。しかしベンダ製品があるなら、活用しない手はない。

オープン技術だけど結局ベンダ縛り?

f:id:furoshiki0223:20131117173101p:plain

よくよく考えてみればおかしいものです。せっかくのオープン技術なのに、かなりベンダロックインされているような状態です。その要因は技術的未成熟さにあったにせよ、状況は実はプラグインベースでRIAをやっていたころと、何も変わっていないように思えます。もっとオープンな技術をガッツリ使うようなイメージがあったのですが、なんだかんだでベンダ製品専用の技術者を育てられているような感じになっているのです。

当時OSS側は、手法とかツールはいっぱい出てきていたけど、その中から選んでとか、やっぱり難しいという状況。

しかしこれが最近になって改善され始めました。OSSでもようやく、デファクトと呼べるようなものが出現し始めたのです。確定かといえば少し微妙かもしれませんが、開発ツールとしては安定を目指せるものになったように思えます。

ほんの2週間前ですが、このような記事が出てきました。

▼ JavaからHTML5ヘ。業務システムの開発におけるWeb技術の変化と適応事例
http://html5experts.jp/albatrosary/3191/

ゲーム系やネットサービス系だと多く見られたOSS製品を利用した開発ですが、金融系というお固い分野に導入されたのです。OSS製品を活用した開発はJava系だともはや当たり前ですが、これがフロントエンド側でも行われたというのは、一つの革命と言えるでしょう。

2つのデファクト的製品の登場

f:id:furoshiki0223:20131117173412p:plain

そのデファクトというのが2つあると思っています。むしろ、2つ出てきたことに意味があると思っています。

Backbone.jsは、最初はゲーム業界に始まり、その後業務系へ輸入され利用されているという情報が、ネット上のブログでもポツポツと見つかっていました。

どのような業種かは不明ですが、2011年ごろには既に実用的な技術にはなっていたようです。面白いのが、ゲーム系で利用されいたという点ではないでしょうか。

Webブラウザを取り囲む業種は、技術的観点から分類するとゲーム系・ネットサービス系・業務システム系へ分けれると思います。これらの3つの業種は、使っている技術こそ同じだが利用方法、目的が違うという特殊な状態が続いていました。開発のツールも、制作/開発を行う人間のスキルも、全く違う状態に思えます。それが、フレームワークというレベルでまで同じものを使うというのが面白い。

いよいよ、異業種間でのノウハウの交じり合いが生じようとしているように思えます。それどころか、業務系のような汎用的エンジニアの多い分野では、技術分野ごとに職種を分けてしまっている他業種へ、部分的に仕事を奪われてしまうのではないかと危機感さえ感じます。

Gruntについては、最近流行りだした技術です。主に2013年に入ってからではないでしょうか。これまでバラバラのツールを使っていた制作/開発の現場を劇的に変えました。

Javaを扱うオープン系の職種の場合、Gruntの登場は歓迎される存在でしょう。なぜなら、EclipseなどのツールではSPAやRIAを大規模なシステムとして開発する十分なポテンシャルを得ていないという状況だからです。

IDEに縛られずに開発が行えるGruntもまた、ゲーム系・ネットサービス系・業務系と、異なるツール異なる技術を扱うWeb技術の世界では、業種を超え広く利用されるポテンシャルを持ったOSS製品に思えます。

どうやって作るのか?

f:id:furoshiki0223:20131117173819p:plain

Webブラウザ

上記の絵、一番右がWebブラウザです。

HTML5機能を持ったものが良いですが、IEの場合バージョン8でもWebStorageが利用できるため、HTML5機能が殆ど無い8以上でも良いでしょう。最も良いのは10以上で、ここまで来たら何でもありです。

業務系の場合、プラットフォームは単一であることが多く、IEはバージョンで縛れてしまいます。ネット上のメディアはIE8以上、場合によってはIE6以上が前提ですが、業務系はこの点で一歩前を進むことができるお得な業種です。

HTML5の比較的新しい機能を利用したサービスは、2013年ごろからあちらこちらで耳にしました。業務系では、とうに研究段階は過ぎているという感触を得ています。そうなれたのも、標準ブラウザという名目で、IEのバージョンを縛れたという点が大きいでしょう。

ポイントとして、業務系はIEが前提になります。っというのは、IEぐらいしか長いライフサイクルを意識したWebブラウザになっていないからです。HTML5の場合、本当によく仕様が変わります。これから暫くもそうでしょう。こうした中、互換モードの充実さでIEの上を行く製品というのはなかなか出てきません。互換性フラグさえ上げれば、IEがバージョンアップしても多少でもまともに動いてくれる、これは非常に重要です。

Backbone.js

真ん中がフレームワークです。

Backbone.jsと書いていますが、実際にはもっと色んなOSS製品を加える事になるでしょう。特に、jQueryのような幅広いプラグインを持つ製品はなかなか外せません。underscoreは、JavaScriptへより便利な機能を加えてくれるため利用価値が高いです。

このレイヤーでは、Webブラウザを抽象化します。直接Webブラウザの機能へアクセスすることを、ノウハウの無い者が何も考えずにやるのは危険という考え方は、jQueryの流行と共に皆が学んだでしょう。フレームワークは、単にWebブラウザをラップするだけでなく、JavaScriptコードの構造化を助けます。

Grunt

一番左は、開発ツールのGruntです。

開発中は基本的に、Gruntの機能を活用して作業を進めることになります。Gruntは最近では、Webデザイナからネットサービスのフロントエンドエンジニアの間で広がっている技術で、彼らの作業の中心にあるCSSやJavaScriptの制作/開発に必要な様々なツールを提供します。

AltJSと呼ばれる、JavaScriptでは解決されない開発時の問題点を解決してくれる言語の利用を助けたり、CSSのメンテナビリティを高めるSassというフォーマットの利用を助けたり、テストやこれに付随する様々なバックグラウンドタスクをこなすのがGruntです。GruntとSublimeという使い方が最もポピュラーでしょうか。

Yeoman + Bower

Yeomanというツールを使えば、Gruntの設定ファイルからBackbone.js+αのOSS製品をコマンド一つで収集しセットアップしてくれます。Yeomanはテンプレート生成やスキャフォルディングと呼ばれる処理を行うツールです。

BowerはJSライブラリのパッケージ管理ツールです。これもJSライブラリを依存解決し読み込みを行うという動作をします。

YeomanもBowerもインターネットがあることが前提なのに加え、ダウンロードしてくるファイルの内容物、バージョンの固定化が難しいため、要件定義の段階で確定が難しいという問題を抱えています。業務系はどのようなソフトウェアを利用するのか開発の序盤で把握し、リスク管理を行う必要があるため、この特性は適用には厄介な面が多いと感じています。

ただ、Rubyの適用が広がる昨今、この問題はどこかで解決に向かうように思えます。私はこのツール、もう少し様子を見たいと感じています。「まだ」というステータスでしょうか。

アプリケーションデザインが変化している

f:id:furoshiki0223:20131117185212p:plain

業務系では鉄板なWindowOSですが、8.1のリリースから読み取れるのは、Microsoftが将来的にデスクトップ系とスマートデバイス系の技術を統合しようという方向に向かっているという点です。オフィスから、デスクトップ特化を無くそうという方向に向かっています。

こうした背景の中、Web技術の持つマルチデバイスを解決するためのアイデアはかなり活きてくるように思えます。Respond JSのようなマルチでバイズ対応向けのOSSライブラリをMicrosoft側が正式にサポートするぐらいですから、彼らがWeb技術にそのヒントを得ようとしているのは確かです。

MicrosoftはWindows8からWeb技術を使ってデスクトップ・アプリケーションを開発することに積極的です。Webアプリストアの登場もそうですが、Microsoftが提供するプロジェクトのサンプルが、以前はVBとC#とVC++だったところが、C#とJavaScriptに変わっている所に注目すべきでしょう。Web技術が全てというわけではありませんが、今後の戦略の重要な位置付けになっています。

以前はRIAとして差別化されていた技術も、今後、デスクトップアプリとの融合との道で幅広い分野への適用が考えられます。そうなると、今のベンダ縛りの状況は好ましくありません。フルOSSでもリッチなアプリケーションが開発できる、それがちゃんと大規模なものへ適用できるという道を作っておくことは、企業システムをベンダロックインの脅威から身を守るために重要な取り組みです。

OSCのようなイベントに行くと「Windowsを使っているような企業は潰れる!」なんて攻撃的な発言も聞こえてきますが、私はそうは思っていません。短期的には安全だが、長期的には危険な状況という考えです。Windowsに安心するのでなく、Windowsを前提とするのでなく、Windowsを選択の一つと捉える考えを持ち続けるべきでしょう。

Backbone.jsもGruntも、流石にOSSということもありベンダ製品のような安定性を望むのは難しいでしょう。しかし、これらのデファクトに化けた技術が、今後のアーキテクチャやツールのあり方の議論の入り口なったのは確かです。この議論をスタートとして、フルOSS開発の未来と真剣に向き合うチャンスを得られたと感じています。

JavaScriptがマネジメントを必要としている

f:id:furoshiki0223:20131117185257p:plain

JavaScriptの危険性

Java系の開発で多いのが、フロントエンド側を無秩序な状態のまま目を瞑っているという状況を、全く改善しようとしない事例です。クライアントは専門外という理由で、クライアント側で起こっていることから目を背ける人が多いように思えます。

しかし最近、jQueryの流行でJavaScriptコードが増え、JavaScriptが業務ロジックを持っているということも少なくなくなったはずです。jQueryはデザイナの世界ではCSSの延長的使い方がメインですが、業務系ではデザインよりもロジックです。JavaScriptがコードを持つ時点で、何かしらの業務ロジックを持っているのは間違いないのです。

マネジメントの面では、品質評価の指標をJavaという括りだけで考えるのは難しくなりました。Strutsが想定したWebアプリケーションの姿は、時代を経て変化してしまいました。

JavaScriptの問題は、言語構文には業務システム開発に求められる品質の可視化を阻害する機能が多く備わっている点です。システム開発では、テストの妥当性、メトリクスの安定性、様々な品質確保に必要な前提があり、これによって初めてシステムの安全が保証されるはずです。私はこのまま、JavaScriptの持つPMを騙し放題な無秩序さを許すのは危険に思えます。(もちろん、趣味として書くのは好きですが!)

フレームワークやAltJSのような存在は、これから重要な位置づけになってくるでしょう。HTML5の持つ機能性をエンタープライズでも十二分に活用する上で、これらは切っても切れない存在に思えます。

クラス設計の変化

ベンダ製品全般的に言えることですが、最近AjaxやWebSocketのような通信の扱いが変わりつつあります。これまではHTTPであることを前提とした通信を扱うのが基本でしたが、2013年、そしてこれから先、クライアント・サーバ間の通信が何なのかを意識させない世界に変わろうとしています。

クライアントとサーバの間で通信を行う際、例えばMicrosoftの.NETではSignalRのような技術が出てきています。SignalRはクライアントとサーバの間で、「モジュール間通信」を行う仕組み、つまりRPC(Remote Procedure Call)を行うための技術です。SignalRでは、通信レイヤーはWebSocketあたりがベストに思えますが、WebSocketに対応していない環境でもFallBackします。通信は抽象化されています。

Oracleだと、JavaはこれまでJAX-RSを利用してHTTPによる汎用的なサーバアクセスの仕組みを提唱してきました。それがJavaScript側では、Backbone.syncなどのJSライブラリ含まれる機能の普及で、サーバ間との「リソース同期」という形に姿を変えました。ここ最近、Microsoftの少し後ろを走っていたOracleですが、Java Oneで公開された「Project Avator」という技術が公開されたことで、一気に周りと並びました。Avatorの出現で、HTTPとの切り離しという未来は決定的なものにかわりました。JavaScriptエンジンがJVM側にも備わったことで、今のアーキテクチャは更に先進的なものに姿を変えようとしています。

RIAかどうかでなく、フレームワークやAltJSのような技術は必要

ここまでRIAの話をしてきましたが、現在置かれている状況、そして今後のエンタープライズ系の技術の変化を理解したところで、みなさんにも理解できたことがあると思います。

JavaScriptは今後、「アーキテクチャ」を持つのです。大規模なモノ作りで重要なポジションを担うことになるのです。

大規模なモノ作りをする場合に、JavaScriptの持つ問題点とどのように対処すべきかをこれから真剣に考えなくてはいけません。つまり、フレームワークは必要。加えて、AltJSは必要という結論に至ります。

まだまだ発展途上ですが、1つずつ吟味して、JavaScriptから逃げるのでなく、JavaScriptを使った開発を良くする方法について考えてみましょう。

このブログの筆者について

川田 寛

コンテンツサービスの開発や運営代行を専門とする集団「株式会社ブートストラップ」の社長です。ネットではふろしきと呼ばれています。

2009年にNTTグループへ新卒入社し、ITエンジニアとしてクラウド技術・Web技術の研究開発と技術コンサルティングに従事。2015年よりピクシブに入社し、エンジニアリングマネージャー・事業責任者・執行役員CCOなど、様々な立場からコンテンツサービスの事業づくりに関わりました。2021年にメディアドゥへVPoEとしてジョインし出版関係の事業に関わったのち、2023年に独立しています。

関わってきたインターネット事業としては、ECサービスのBOOTH、UGCプラットフォームのpixiv(主に海外展開)、制作ツールのpixiv Sketch、VR・VTuber関連ではVRoid、Wikiサービスのピクシブ百科事典など、10を超える多様なCtoCコンテンツサービス。また、NTTドコモのすご得コンテンツ、メディアドゥのWeb3サービスであるFanTopなど、いくつかのBtoCコンテンツサービスにも関わってきました。

幸運なことに、私はコンテンツに関係する幅広いインターネットサービスのテクノロジー&ビジネスの知識を得ることができました。これを日本のコンテンツ発展に役立てたいと思い、株式会社ブートストラップを創業しました。

このブログでは現在、出版社やIPホルダー、ライセンサーといったコンテンツに関わる人々に向けて、インターネット事業に関するTipsや業界内のトレンドなどの情報を発信しています。私と話をしてみたいという方は、以下のフォームより気軽にご連絡ください。

お問い合わせフォーム