第4回　運用開発におけるJavaScriptのフレームワークの選定

はじめに

みなさんこんにちは、技術系Q&Aサイトのteratail開発チームの本橋佑介です。

WebサービスでJavaScriptを利用する際にフレームワークを使うことがスタンダードになって来ていますが、運用中のサービスに適用するのはなかなか難しくためらっていませんか。フレームワーク自体の比較ではなく運用中のサービスにフレームワークを適用する際に何を選定すればいいのか、そこにフォーカスをあてて紹介したいと思います。

なぜJavaScriptフレームワークを使うのか

通常Webサービスを作る場合、RubyではRails、PHPではLaravelなどのフレームワークを利用すると思います。MVCモデルを導入する目的としてビジネスロジックや画面描画などの分離、コンポーネント化ももちろんですが、チーム開発をする上ではコーディングルールの統一や部品の統一化、画面の切り離しによりフロントエンドエンジニアやフロントコーダーとの分業のしやすさを実現することがあげられます。

PHPでは、フレームワークを用いた開発が主流ではなかった2000年代中盤のWebサービス開発においては、Webデザイナーが作成するHTMLファイルを受け取ったプログラマがHTMLソースを分解しループなどの表示処理を当て込んでいく作業が当たり前でした。デザインまで含めたチーム開発をする上では再利用性や各種フレームワークに含まれるコンポーネントが利用できることも重要ですが、Webデザイナー/プログラマ間の作業を軽減しフロントコーディング/ロジック部分の開発に集中できることが何より重要となります。

近年、JavaScriptのフレームワークが多く発表されるようになったのは、各ブラウザ間でのイベントの伝達方法やタグなどの仕様の不一致を吸収するため、日々変わっていくブラウザの仕様に追従するため、またそれらを含めたブラウザやマシンの進化によりユーザのマシンに任せられる処理が増えたことでサーバサイドではなくフロントエンドで処理をすることが多くなりJavaScriptでの開発量の比率が増加したため元来MVCモデルで言うViewであったフロントエンドにMVCモデルを用いる必要が出てきたためと言われています。

Webサービス開発を行っている方にはjQueryでDOMが滅茶苦茶になったり動的に生成されるHTMLがどこで定義されているかソースコードを深く追わないとわからなくなったり、運用していくうちにフロントエンドエンジニアしかテンプレート部分に手が付けられないような経験がある方も少なく無いのではないでしょうか。

そこでJavaScriptのフレームワークの導入によりロジックのコンポーネント化やViewとロジック部分の切り離し、そしてフロントエンドエンジニア/Webデザイナー間でそれぞれ作業する箇所の分離をしチーム開発をしやすくする必要が出てきています。

JavaScriptフレームワークの最近の動向（4つの主要フレームワーク）

まずは対象となるフレームワークの簡単な紹介をしたいと思います。詳細な説明はここでは割愛させていただきます。前述の通りWeb制作チームで運用中のサービスに導入するというテーマなので、多少トレンドから古くなっていても実績が多く信頼できるということが重要です。

フレームワーク名	特徴
AngularJS	Google製フルスタック独自タグでの双方向データバインディング
React.js	Facebook製シンプル Fluxモデル UIの構築に特化
Backbone.js	構造のみシンプルで軽量 jQueryが必須記法が自由, Marionette.jsと供に使う
Knockout.js	シンプル明示的な指定による双方向データバインディング

［参考］teratailでの質問件数

比較・Webサービスのチーム開発における各フレームワークのメリット・デメリット

それでは、Webサービスのチーム開発における各フレームワークのメリット・デメリットを比較し選定してみましょう。選定基準として、以下のものを重要と位置づけています。

プログラミングのできないメンバーへの敷居が低いものであること
現状書かれている記述が残せること
（できれば日本語の）資料が充実している

また、フロントエンドに携わるチームメンバー全員がJavaScriptフレームワークを習得できるのが理想ですが、現実線としてHTMLとCSSが書けるレベルでもそれほど問題にならないことが求められます。

フレームワーク名	メリット	デメリット
AngularJS	シンプルな記述が可能 EcmaScript6に対応 HTMLをあまり侵食しない機能が豊富	学習コストがかかる独自記法互換性のない2.0がリリースされる
React.js	VirtualDOM レンダリングが早い無駄なファイルが増えない	コードとHTMLが同居既存のコードの書き直しが必要
Backbone.js	導入事例が多い構造化に強い jQueryが必須	規約の縛りが緩い同じことを何度も書く必要があるテストしにくい
Knockout.js	独自記法が少ない jQueryと同居可能 HTMLをあまり侵食しない	ModelとViewの分離以外は弱いレンダリングのコストが高い <!-- -->での構文が存在する

以上のメリット・デメリットを考慮した上で、今回の条件ではKnockout.jsを選定することになりました。決め手は小さい依存関係、小さい学習コスト、小さいHTMLへの影響というところです。

レンダリングコストの問題やのコメントをWebデザイナーが消さないかなど懸念点はありますが、それを上回るメリットが有ると判断しました。AngularJSは2.0が出ることで1系の見通しが立たないこと、React.jsとBackbone.jsは初期導入コストが高いことで採用を見送りました。

フロントエンドエンジニアが開発と保守ができるのなら高速なReact.jsが採用されたと思います。私のチームが開発を行っているteratailではKnockout.jsをただいま導入準備中となっています。

最後に

今回は運用中のサービスでの導入という視点で紹介、選定をしてみました。当記事を読んでいる方の技術調査や導入調査の際に参考になれば幸いです。