聞いたら一生の宝,プログラミングの基礎の基礎

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

この記事を読むのに必要な時間:およそ 2 分

はじめに

みなさんこんにちは,技術系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制作チームで運用中のサービスに導入するというテーマなので,多少トレンドから古くなっていても実績が多く信頼できるということが重要です。

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

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

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

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

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

フレームワーク名メリットデメリット
AngularJSシンプルな記述が可能
EcmaScript6に対応
HTMLをあまり侵食しない
機能が豊富
学習コストがかかる
独自記法
互換性のない2.0がリリースされる
React.jsVirtualDOM
レンダリングが早い
無駄なファイルが増えない
コードと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をただいま導入準備中となっています。

最後に

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

著者プロフィール

本橋佑介(もとはしゆうすけ)

レバレジーズ株式会社 teratail開発責任者。

フロントエンド,バックエンドの開発に携わりUIデザインなども担当。最近の興味はPostgreSQLとオーディオ。自作アンプ沼にはまらないように戦っている。

コメント

コメントの記入