Webとハイブリッドアプリを両方提供するメリット
Webの拡散性とアプリの継続性のいいとこ取りです。
Webはインストールしなくていいという気軽さから、アプリに比べてユーザを獲得しやすいです。
一方アプリは新規ユーザの獲得が難しい反面、継続率がWebに比べてはるかに上です。
今提供しているサービスの場合、Webとアプリでは、新規ユーザはWebとアプリで10:1ぐらいですが、継続率で1：30ぐらいの開きがあり、実際1年以上提供しているWebサービスに対して、アプリの提供を開始したところ、1ヶ月と経たないうちにリピーター数/Dayをアプリが抜きました。
Apache Cordovaを使えばネイティブコードを一行も書かずにアプリを作ることができ、Webサイトのコードとアプリのコードのほぼすべてを共通化できます。
スマホの使用時間の**90%**はアプリと言われているように、スマホの主戦場はアプリです。
Webでユーザに実際使ってもらい、気にいってもらうことでアプリをインストールしてもらえるようになるのが理想的です。
また、Googleが2015年4月21日からスマホにはスマホ向けの検索結果を出すようになり、その際にWebページがスマホ向けかどうかにより大きく結果が違うようになることを考えると、アプリだけでなくスマホのWebサイトを作るメリットが今後大きくなると考えられます。
#で、一番理にかなっているJSフレームワークは？
SinglePageApplicationでスマホのWebサイトsmartFXとハイブリッドアプリを2つsmartFX、smartFX Virtual Trade提供した経験からズバリ、Backbone.jsです。
Backbone.jsを選ぶ利点
1. 軽い
サイズが20K。依存ライブラリのUnderscore.jsが16KでjQueryが82K。Angular.jsが123Kなので、依存ライブラリを全部合わせるとそんなに変わらないのですが、AngularでもjQueryを使う場合はかなり違ってきます。
ハイブリッドアプリだけで提供する場合は、アプリ内に予めJSを置いておくことができるので、そこまで神経質にならなくてもいいかもしれませんが、Webサイトの場合は、スマホの通信を考えるとJSのサイズの違いは大きいです。
ユーザはSPAということを知らないので、初期表示が遅いとサイト全体が遅いと思われ直帰率が高くなってしまいます。
smartFXでは、Topページ表示時はTopページに必要なJSのみをダウンロードすることでライブラリの小ささを活かして初期表示を速くしています。
(参考: Railsで高レスポンスかつ初期表示も速いスマホ用Webサイトを作る )
また、JSによるレンダリングを行っているページはクローラ用に静的ページを返す必要があり、その際もレスポンスが速いほうがSEO的に有利です。
(参考: SinglePageApplicationにおける問題点と対応 )
2. 速い
Viewをきっちり設計できていれば、モデルの変更に対しては変更部分だけの描画を行うことになり、そうすると速いと言われているVirtualDOMを使ったReact.jsよりもほぼ3倍速い(https://html5experts.jp/hokaccha/13301/) ようです。
3.技術的負債にならない
Backbone.jsは2010年の提供から今年で5年近く経ちますが、コメント、空行ありで今だに1600行ちょっとと非常に小さく、安定的です。
仮に今開発がストップしたとしても、自分で保守できる大きさです。
4.ほぼ素のHTMLが使える
Templateは特に決まりがなく、サーバがRailsであれば、JSTを使ってHTMLに近いejsファイル等を別ファイルとして管理でき、デザイナーと並列で開発することが可能です。
Backbone.jsにまつわる不評について
一番よく言われるのは大規模開発に向かないということです。
これには3点あると思います。
- 機能が少ないため、コーディング量が増える。
- データバインディング機能がないのでイベント地獄になる。
- 制約が少なく自由に書けるため、複数人が開発に関わると人により書き方がマチマチになって保守しづらくなる。
1.に関しては、使わないAPIが豊富の重量ライブラリを使うか、必要最低限の機能の軽量ライブラリを使うかということだと思います。
この批判に関してBackbone.js作者のAshkenasは、プログラマなんだから共通する機能はライブラリ化して整備されていき、開発スピードは変わらなくなっていくという返答しており、その通りだと思います。
2.は、扱うイベントが多いのはそうなのですが、Viewの設計がうまくできていれば、別に不都合を感じないと感じています。
1つの画面は基本的に複数のViewで構成されていて、各Viewはそれぞれ独立したモデルに紐づいているので、画面全体で見ればイベント数が多くても、ViewとModelが結びついているので特に混乱はしません。
またデータバインディングがないと面倒と思うかもしれませんが、反映する側、される側に対して、データバインディングありでも反映される側(Template)は記述する必要があり、反映する処理を書くより、反映される側で見栄えよく表示されるように記述するほうが面倒なことが多く、さらにデータ反映のタイミングで昨今のリッチなアニメーション等の動作をさせるのが難しかったり、デバックしにくくなったりするデメリットのほうが大きいのでは思っています。
3.に関しては、規律を守るためには、校則を増やすのがいいという問題に近いものを感じていて、フレームワークで縛らなくても、開発者自身が保守性の高いプログラムの書き方を知っていたら問題ないと思います。どうしても普通の処理と外れたことをしないといけない時に、フレームワークで縛られている場合は、トリッキーな書き方をしなくといけなくなり、そういうことが重なるとそもそも縛りって何だっけとなる気がします。
そうは言っても初級レベルの人や好みが全然違う人がいると難しいので、状況によります。
まとめ
Angular.js、react.jsが取り沙汰されている今、なぜBackbone.jsなのか。
すみません。
惚れている女がいるのにもっと惚れる女がいるか探すやつがいるかとAngular.jsやreact.jsはほとんど触っていません。
ただバージョンアップにより大幅なAPI変更が行われることが決まっているAngular.jsや、まだまだベストプラクティスが見えないreact.jsと比べて実績豊富なBackbone.jsを選ぶことは今一番理にかなっていると言えるのではないでしょうか？
補足
ハイブリッドアプリだけで出す場合は話は別で、Angular.jsベースのOnsen UIを使えばカスタムタグを使うだけで、ネイティブと同様のUIになるので、お手軽にアプリを作ることができます。