Qiita の AdventCalendar "JavaScript - Client Side - Advent Calendar 2013" 向けのエントリーです。遅れて申し訳ないです。。
ExtJS についてのエントリーをいくつか書かせていただきましたが、結局 ExtJS ってどうなの？という辺りをまとめたいと思います。
[toc]
過去の記事
- Ext JS サンプルの RSS リーダーを拡張中
- ExtJS: CheckboxModelのselectメソッドで指定したデータにフォーカスするのを避ける方法
- ExtJS: Border レイアウトの代わりに hbox / vbox を使う方法
- ExtJS: チャートでは複数ストアは扱えない
ExtJS とは
一言で言えば、クライアントサイドの JavaScript フレームワークです。デスクトップアプリケーションを構築するためのフレームワークと謳われており、Ext JS だけあれば他にプラグインは要らないほどの高機能ぶりです。
実際に利用していて、グラフ機能が豊富だったり、サーバとの通信が簡易に行えるのが特徴だと感じました。開発は MVC フレームワークに乗っ取って行います。
Google トレンドを見てみる
開発元の Sencha 社の公式ページも充実していて一見よさそうな ExtJS ですが、実際に開発をしていて困ったときに Google 検索をすると、引っかかるのは 2011 年の記事が中心。ふと Google トレンドを見てみると2011年辺りから右肩下がりでした。
今話題の JavaScript フレームワークの AngularJS と比較してみると、なんとも悲しい感じに。AngularJS、分かってはいましたが相当キテますね。（青が ExtJS, 赤が AngularJS です）
ExtJS だけあれば何でもできる！というのは魅力的です。しかし ExtJS ではプロトタイプベースの JavaScript をクラスベースに模しているために独自の雰囲気があり、習熟に時間がかかります。
また、デザイン面で融通が効かずに「ExtJS っぽい」ものが出来上がるのが流行っていない一因かもしれません。
ExtJS を活用できる場面
そんな ExtJS ですが、約1年のプロジェクトで利用してきて、こういう場面で ExtJS は活用できる！という点をまとめました。導入に迷っている方の参考になれば幸いです。
クロスブラウザ対応が必要なとき
ブラウザ互換の問題は ExtJS が吸収してくれるため、アプリケーション側でクロスブラウザを意識する必要はあまりありません。ブラウザ互換の問題があるメソッド（foreach など）は ExtJS が互換部分を吸収したユーティリティメソッドを用意してくれています。JavaScript 組み込みのメソッドをそのまま使う場面があれば、ユーティリティメソッドがないか確認しておくとよいです。
デザイン面を自分で書き換える場合は、ブラウザによって見え方が変わってしまう場合も多いのですが、アプリケーションが全く動かなくなることは少ないはずなので、大きな手戻りにはならないと思います。
多人数で開発するとき
ExtJS はクラスベースのフレームワークであることと、MVC アーキテクチャを採用していることから、多人数での開発に適していると感じました。特にクラスベースであることから、独自クラスを定義してそれを各所で再利用するという、Java などのオブジェクト指向の考え方がそのまま適用できます。
保守期間が長い場合
クラスベースのフレームワークや MVC アーキテクチャであることは、保守を行う場合に有利です。
MVC フレームワークであることから、ロジック面での修正であればコントローラ側を見ればよく、表示上の問題であればビューを見ればよさそうだ…など、プログラムの保守がしやすいです。
オールインワンなフレームワークなので、バージョンアップ時に他のプラグインとの整合性を考えなくてよいことも、保守しやすい一因かもしれません。
サーバとの複雑なやり取りが発生する場合
私が今回携わったプロジェクトではシステムを REST API で構築したため、クライアントとサーバで JSON オブジェクトを頻繁に受け渡す必要がありました。
ExtJS では JSON オブジェクトの処理をモデル側で処理できるため、これだけでも ExtJS を選択する理由になり得ます。
ExtJS を利用しない方が良い場面
一方で、「ここで ExtJS は使わない方がよいかも…」と思うこともありましたので、まとめてみます。
モックアップを作るとき
ExtJS は何もせずともそれなりの見た目になりますが、だからといってモックを ExtJS で作ると大変です。クラスベースのフレームワークであることや、MVC アーキテクチャであることから、モックを作るだけでもコーディングの量が多くなってしまうことが理由です。
ExtJS の検証をかねて…ということであれば良いと思いますが、ExtJS のモックに時間を掛けてしまって他のフレームワークの調査ができなかった…ということにもなりかねませんので注意してください。
保守期間が短い場合
理由はモックアップと同様ですが、ExtJS での構築には時間がかかるため、構築後の保守期間が短い場合は選択しない方がよいと思います。
デザイン要件が多いとき
2つの理由で、デザイン要件が多いときには不向きです。
1つ目は、デザインの幅が狭まること。オールインワンパッケージということで、基本的には ExtJS が提供しているコンポーネントを画面構成に当てはめる作業が中心となります。そのため、独自の動作やデザインを構築しようという方向に意識が向きませんし、そもそも難しいです。
2つ目は、デザインは SCSS で当てるということ。デザイナーさんに作業を依頼する場合も SCSS での作業を依頼する必要があり、Sencha コマンドでのコンパイルをしてもらわなくてはならず、敷居が高いです。また、コンポーネントごとに設定できる SCSS が大量にあり、独自デザインを実現するために、それらをクロスブラウザで試す労力も軽視できません。
…ということで、ExtJS が出来ることから画面を構成することになり、目的と手段が逆になってしまうのがクライアントやデザイナー泣かせのフレームワークです。
描画速度が重要なとき
クラスベースのフレームワークですが、クラスばかり多様していると最終的に生成される DOM が div タグのお化けになり、描画に時間がかかります。
描画速度を上げるテクニックもありますが、DOM 生成まで全て JavaScript で行うフレームワークなので、基本的には処理速度は遅いと考えておいた方が良いです。
雑感
最後に、1年間利用してきた私の雑感を。
- フレームワーク習得に時間が掛かるため、導入に敷居が高い
- 開発がしやすい訳ではないので、それなりに工数が掛かる。どちらかというと後々のメンテナンスが楽なフレームワーク
- 大規模開発向けだが、大規模開発だとデザイン要件もそれなりに多いはずなので、デザインの自由度が低い ExtJS は使いどころに困る
…と書いてて、そりゃ流行らないよなぁと感じますね。。一旦構築してしまえばよいのですが、そこまでが非常に大変です。
Sencha 社で言えば、最近はスマートフォン向けの Sencha Touch の方が隆盛している気がしますが、どうなんでしょう。今度触る機会があればご紹介します。
