SPAがネイティブアプリをぶっ壊す:HTML5/Javascriptが変えるWebの未来

  • 896
    いいね
  • 4
    コメント
この記事は最終更新日から1年以上が経過しています。

はじめに

タイトルは半分釣りですが、半分本気で考えてもいます。
近い将来、Webアプリが今のネイティブアプリの市場を超えてくる、と仮説を立てています。
ぜひ、先人のみなさんのご意見やお考えを教えてください。

SPAについて

SPAとはなにか(What)

歴史

佐川夫美雄さんのイベントレポートの一部が、非常にまとまっていてわかりやすい部分でしたので、まず引用させていただくこととします。

RIAはアプリケーション利用者に対し高い評価を得ましたが、2010年のAppleショックにより衰退の方向へ向かいます。具体的には2010年にSteve JobsがFlashを激しく批判したことに端を発します。プロプライエタリ(Proprietary Software)なFlashよりオープン性のあるHTML5を推進するようになりました。2011年にはMicrosoftがWeb開発者に対してSilverlight戦略を後退させ、AdobeもモバイルFlashの開発を中止しました。そして2014年HTML5正式勧告です。この流れにより、HTMLでWebアプリケーションを作る方向に向かいました。
RIAに代わる技術、実用的SPAについて考える~第7回エンタープライズ×HTML5ナイトセミナー~

このような流れの中、だいたい2013年ころからSPAに関連する記事やコメントが盛り上がりを見せ始め、去年や今年になると、日本の周囲の中でもSPAを使ってWebアプリを構築した人が多く出始めてきました。

おおまかにいうと、SPAライクなアプリケーションは
1. Javaアプレット
2. Flash
3. SPA
という流れの中で進化してきました。この時期になってSPA盛り上がりを見せてきたのも、ひとえに
HTML5を中心としたWeb APIの進化や、コンパイル型言語にも引けを取らないほどのJavaScriptの進化に
起因するところが大きいです。

現状

ですが、正直SPAの普及はまだまだ、というのが個人的な印象です。まだ揺籃期にあるのではないかと
思います。

小規模であれば、サンプルも経験者も増えてきたので結構な機会に目にすることが増えてきました。
関連図書が増えていることから、興味を持って学習されている方も多くなってきた印象です。

ですが、中規模、大規模で開発されてきた知見を蓄える企業はGoogleなど一部を除いて
まだまだなのではないでしょうか。中規模以上でSPAを用いた開発をするとなると、
モジュール設計からかなりの注意を持って設計しなくてはいけませんし、
セキュリティ、ハイパフォーマンスを意識したコーディングができる人は
僕が尊敬している人も何人かいらっしゃいますが、全体として数は多くはありません。

そもそもJava Script自体がハードルが低い言語、でも本当に極めるにはかなり学習が必要な
言語であるため、本当に動く、メンテナビリティを保ったままスケールアウトできたプロダクトを
手がけた経験を築ける場が本当に少ないことがそもそもの理由だとも思います。

ネイティブアプリはユーザとしても開発者にとってもホットで人気な開発基盤であるため
アプリ開発のスタートアップも数々出ています。ですから、SPAは現状では主流には
まだなれていないと思います。

なぜSPAか(Why)

SPAのメリット

デプロイが簡単

プロダクトが完成したら、それをサーバにアップロードするだけで公開できます。
Webサイトを公開した後で誤りを見つけたとしても、そのページのHTMLファイルや
スクリプトの一部を書き換えるだけで瞬時に修正することができます。

これは審査を必要とし、リジェクトされる可能性もあるネイティブアプリとは異なります。
もちろん、デプロイに慣れていない初心者がデプロイに時間がかかってしまうという場合はありますが、
基本的にはデプロイは非常に簡単です。

ネイティブアプリを上回る機能開発がかなり進んでいる

あなたがWebアプリではなくネイティブアプリを選ぶ理由はなんでしょうか?
「プッシュ通知ができるから」という意見が多いのではないでしょうか?
しかし、実はPush APIというものがあり、ブラウザでもネイティブにプッシュ通知機能が
サポートされる日は近いです。

現在はChromeが先進的にサポートしていますが、まだまだ仕様がたびたび変更する
段階ではありますが、近い将来ネイティブアプリに負けないプッシュ通知が普及することは
間違いないでしょう。

クロスプラットフォームである

基本的に、iOS向けに書いたアプリを低コストでそのままAndroidで公開はできません。
Objective-C / Swiftで開発するチームと、JavaなどでAndroidアプリを開発するチームは
どの会社でも別のことが多いかと思います。

Webは、クロスプラットフォームです。かつ、スマートフォンを持っていないユーザーに
リーチすることもできます。ひとつのプロダクトを作った時にアプローチできるユーザーの
ボリュームが圧倒的に違います。

もちろん、ブラウザごとに細かい仕様が異なり、ベンダープレフィクスや未実装の仕様などを
気にする必要はありますが、同じプロダクトをiOSとAndroidで作るコストと比べれば
微塵なものです。

近年HTML5/CSS3/JavaScriptのサポートと機能開発がかなり進んできている

これについては単純にネイティブアプリ側を量的比較をすることはできないかもしれませんが、
少なくともフロントエンジニアの方であればご存知のように、近年のHTML5/CSS3やサーバサイドスクリプト
のNode.js、Socket通信を容易に実現できるSocket.ioやWeb RTC技術をサポートする機能の進化の
スピードには目を見張るものがあります。

昔であればJavaアプレットやFlashで作らざるを得なかったものが、SVGの登場も相まって
ハイパフォーマンス&ハイクオリティなグラフィクスレンダリングでゲームやインタラクティブな
サイトを作ることができるようにもなってきています。

オンラインアプリの「脱オンライン」化

これは先ほどのWeb APIの進化ともかかわっているのですが、
- オフラインでの作業を可能にするAPIの開発・進化
- 高速かつ効率的にレンダリングされるHTML生成とDOM
- マルチコアプロセッサやギガバイトのRAM普及といったハード面での進化
などによって、今まではサーバ側、データベース側で行われていた数々の処理が
クライアントサイドで実現されるようになってきました。

今まではキャッシュやクッキーしか使えなかったところが、5MBまでのデータをオリジンごとに保存できる
Local Storage API、Indexed DBの登場などのおかげでもあります。これによって、今までは
DOMやレンダリング、CSSによるレイアウト装飾などしかできなかったところが、ビジネスロジックや
HTML生成などもできるようになってきました。

Michael S. Mikowskiは、その著『シングルページWebアプリケーション(p69)』で、

SPAクライアントはデスクトップアプリケーションのように応答性が高いという人もいるが、もっと正確にいうと、適切に記述されたSPAクライアントはデスクトップアプリケーションそのものである

とまで言い切っている。

SPAのデメリット

初期レンダリングに時間がかかる

必要に応じてコンポーネントをレンダリングさせるとはいえ、初期ページではモジュールを読み込んだり
DOMを生成したりと、初動が遅くなりがちです。Googleの検索一覧ページみたいに、一度ヘッダーを表示したうえで
検索結果を後からレンダリングさせる、といった工夫もできますが、サイトのテーマや構成によっては
どうしても初動の立ち上がりが遅くなってしまうこともあるかと思います。

JavaScriptの高い技術が必要

正確にいうとこれはデメリットではありませんが、サーバ側が行う処理をクライアント側で実現したり、
オフラインでも動作する機能を実装したり、レンダリングをノンブロッキングでユーザーエクスペリエンスを
低減させないようにしたりなど、考慮すべき点がかなりあります。JavaScriptはハードルが低く
誰でも書ける言語である反面、ここまで考慮してプロダクトを作れるプロになるまでには結構時間が
かかるのではないでしょうか。

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

では一方のネイティブアプリとの違いはなんでしょうか。
SPAのメリット/デメリットと相反することばかりですが、
改めて書いてみます。

ネイティブアプリのメリット

インストール後はサクサク動く

普通に一つのアプリをインストールするのには、数十秒、ネット環境によっては
数分から数十分かかることもありますが、一旦インストールが終われば
サクサク動きます。

もちろんFacebookやTwitterのようにリクエストを必要とするアプリもありますが
ゲームなどはローディング時間も短いものが多いです。ネット遅延によるユーザビリティを
大幅に変えることはありません。

しかし、これも先ほど述べたように、JavaScriptの進化によって今まで不可能であった
処理がどんどんブラウザ側に移行してくることによって差異が縮まりつつあります。

検索によるリーチがしやすい

仮にあなたが素晴らしいSPAを作ったとします。それを全世界中に向けて
意気揚々と公開したとします。さて、マーケティングや広告にお金をかけられる
大企業ならまだしも、そうでない中小企業や個人によるプロダクトが社会に認知されるには
どれくらいの時間と労力が必要でしょうか?

もちろん、いいものを作ればそれは投資を呼び、口コミを招き、スケールアウトする可能性は
多分にあります。しかし、一般的にGoogle検索よりiTunesストアやAndroidアプリ検索
したほうが検索数は少なく、よりユーザにリーチできると思います。

スマフォ利用時間におけるアプリ利用時間が長い

データは今手元にありませんが、自分のスマフォ利用状況をイメージしてみてください。
単純に、iPhoneの標準のSafariとアプリ、どっちがより多く使っていますか?

モバイル上のブラウザで定期的にアクセスするページをブックマークしていたり
定期的にアクセスしたりするユーザーは、アプリを日常的に使うシーケンスより
圧倒的に少ないと思われます。

ネイティブアプリのデメリット

インストールに時間がかかる

使う前からそのアプリの評判や口コミから期待が高いアプリに対しては、ユーザーは
しっかりインストールしてくれます。しかし、使ってみないと良さも悪さも
わからないようなアプリを、何分も待ってわざわざインストールするでしょうか?

この「インストールに時間がかかる」がためだけにユーザーを獲得できていないアプリも
一定数あることが仮説として挙げられます(検証には実データが必要ですが記事レベルなので省きます)

プラットフォーム依存型である

このデメリットは大きいと思います。せっかく作ったアプリも、規約や言語の仕様変更によって
リリースできなくなることはよくあります。また、ガイドラインに準拠したつくりをしないと
そもそもリリースできない、リジェクトされてしまうという可能性も多々あります。

公開に時間がかかる

このリリース/リジェクトという所作も結構曲者で、いちはやく作ったものをユーザーに届けたくても
数日や一週間程度待たなくてはいけません。また、不本意にリジェクトされてしまうこともあります。

バージョン管理が大変

バージョン管理も大変です。Webアプリならバグをフィックスしたものをサーバーに上書きしてアップロード
してあげればいいだけですが、アプリはそうもいきません。

デプロイ(アップデート)に時間がかかる

上記とも連携しているのですが、更新やパッチをあてたものを公開する場合、すぐに
ユーザーに届けることができません。数日の差かもしれませんが、ユーザーは一秒たりとも
待ってはくれません。

SPAの作り方(How)

Framework

Angular.js

https://angularjs.org/

Backbone.js

http://backbonejs.org/

Polymer

https://www.polymer-project.org/1.0/

React.js

http://facebook.github.io/react/

Aurelia

http://aurelia.io/

事例

Google Maps

https://www.google.co.jp/maps

Google Keep

http://www.google.com/keep/

Offline Gmail

https://chrome.google.com/webstore/detail/gmail-offline/ejidjjhkpiempkbhmpbfngldlkglhimk?hl=ja

Cordova(PhoneGap)を使ったネイティブアプリ事例

http://qiita.com/takeshy/items/18a902289c05de044d50

さいごに

補足

SPAをどこで学ぶのか(Where)

必読記事

Evolution of the Single Page Application — Part 1 of 2

http://paislee.io/evolution-of-the-single-page-application/

Evolution of the Single Page Application — Part 2 of 2

http://paislee.io/evolution-of-the-single-page-application-2-of-2/

Single page apps in depth

http://singlepageappbook.com/goal.html

SPAを構築するときに知っておいた方がいい7つの課題

http://blog.mitsuruog.info/2014/01/spa7.html

「SPAを構築するときに知っておいた方がいい7つの課題」は課題ではない

http://albatrosary.hateblo.jp/entry/2014/01/15/121608

RIAに代わる技術、実用的SPAについて考える~第7回エンタープライズ×HTML5ナイトセミナー~
https://html5experts.jp/albatrosary/4939/

ベストスライド

なぜSingle-page Application(SPA)なのか SPAの通信技術は? バックエンドは? JavaScriptフレームワークは?

http://www.slideshare.net/sagawafumio/single-page-application-30482357

Spa のための web サーバ構築ノウハウ

http://www.slideshare.net/kotsutsumi/spa-web

Single Page Application by Eduardo Lundgren

https://speakerdeck.com/eduardolundgren/single-page-application

React & Go Single Page Apps by Tsusyoshi Higuchi

https://speakerdeck.com/tyshgc/react-and-go-single-page-apps

Reusable Component UI Design by Tsusyoshi Higuchi

https://speakerdeck.com/tyshgc/reusable-component-ui-design

情報収集

One Page Love

https://onepagelove.com/gallery/application

おすすめ書籍

『シングルページWebアプリケーション ―Node.js、MongoDBを活用したJavaScript SPA』

『入門 React ―コンポーネントベースのWebフロントエンド開発』

『実践Node.js プログラミング (Programmer's SELECTION)』