albatrosary's blog

UI/UXとエンタープライズシステム

JavaScriptフレームワークについて個人的な思い - 当時を振り返りながら

HTML5 Experts.jpでエンタープライズ特集が組まれたことは承知だと思います。やはり注目すべきところはJavaScriptフレームワークの見解ではなかったかと思います。JavaScriptフレームワークについては人それぞれ考えがありますので、一概にこれとは言えませんが、私が感じているところを記載したいと思います。

 

世の中の動向と以前の判断

Googleトレンドを見る限りではAngularJSのひとり勝ちのように思えますが、身の回りの案件ではBackbone.jsが多いのではないかと思えます。１年半前にHTML5プロジェクトを行ったときに選定で残ったのが

  • Backbone.js
  • AngularJS
  • Sencha Ext JS

でした。最終的に利用したのはBackbone.JSだったのですが理由がjQueryベースで入り易かったということが上げられます。AngularJSは独特な記法であったことと、まだ早いのではと思い見送りました。Sencha Ext JSに関してはコンポーネントそのものは良かったのですがフロント開発においてデザインが入れ辛いというのは問題なので（お客さんに怒られるので）見送りました。

そうしてできたのがHTML5 Experts.jpの記事です。まだお読みでない方は是非見て頂けたらと思います。

 

JavaからHTML5ヘ。業務システムの開発におけるWeb技術の変化と適応事例 | HTML5Experts.jp - 2013/11/07 

 

さて既に2014年夏も終わりに近づいて来ましたが、Google I/Oも終わり、Web標準/ECMAScriptの動向もあり、JavaScriptフレームワークも大きく変わろうとしていると思います。もし以前行ったシステムをもう一度JavaScriptフレームワークの選定から行ったら何を選ぶかを考え、個人的にJavaScriptフレームワークの見解として思うところを記載したいと思います。余談ですがECMAScriptについてはブラウザの適合表がありますのでリンクします。

 

Backbone.js

概要

Backbone.jsそのものが悪いというわけではありませんが、Backbone.jsはその名の通り枠組みしかなく、ベストプラクティスと呼べるものが存在しません。ベストプラクティスが無いためmarionettoなど入れるプロジェクトが多いと思いますが、それでも誉められるような構造化されたコードを書いている人が少ないように思えます。ベストプラクティスが無いのでプロジェクト毎にルールを決める必要があります。うまくいくプロジェクトもあればうまく行かないプロジェクトも多くあるようです。

  • 枠組みのみ提供
  • Backbone.js + αが必要、ルールを作り統制できれば問題なし
  • jQuery、requireJSの恩恵によるところが大きい
  • CoffeeScriptの作者同じ
  • ベストプラクティスが無い

外部リンク

 

KnockoutJS

概要

実際に本番導入したことはありませんが、常に候補に上がります。KnockoutJSのWeb Componentsには期待するところもありますので今後も情報として追いかけるつもりです。鈴木健太氏が日本語訳サイトを展開するなど色々なところで使われている。Microsoft Japanの松崎剛氏による解説(ブログ等)も多くあります。

  • 双方向バインディングのみ実装で軽量
  • 想像以上に実績が多い
  • いざというときに役に立ちそう
  • Visual Studio/Windows Azureともばっちり
  • Web Components実装に期待

外部リンク

 

Ember.js

概要

AngularJSと肩を並べWeb標準をいち早く実装しています。実装のスピードではAngularJSを上回ると思います。ただ中々手を出すことが無く遠目で見ている状態です。チャンスがあったら触ってみたいフレームワークです。Ember.jsを使うときのコメントを頂きましたので追記します。「Ember.js使うなら素でやるよりはember-cli使うと楽になれます（コマンドで必要なの生成してくれるので書くのが減る、という意味でも）」だそうです。Ember.jsについては早い段階で一度味見をしてみたいと思ってます。

  • いち早くWeb標準を取り入れる勢い
  • 少しモジュールが大きい
  • 触るチャンスがない

外部リンク 

 

AngularJS

概要

ディレクティブ、フィルター、サービス等どこに何を書くか明確になっているため比較的綺麗にコーティングできると思います。Backbone.jsもルールを決めれば綺麗に書けますがAngularJSの方がより整えて記載することができると思います。Web標準やECMAScriptを意識した構成になっているためWeb ComponentsやObject.observe()を実装すればより理解が深まります。テストやセキュリティまで考慮していてそう言った意味で「フルスタック」と呼ぶことが多いです。

  • テンプレートがHTMLベースなのでデザイナーでも入り易い
  • Web標準、ECMAScriptを積極的に取り入れている
  • フルスタックフレームワーク
  • モジュールが疎結合なので分担作業が行い易い

外部リンク

 

Sencha Ext JS

概要

Senchaはオールインワンで開発環境からすべて整っています。しかし昨今のエコシステムにはまったくのれていないのでいざという時は一苦労します。YUI Interfaceが開発を終了しSenchaの動向が気になっていましたがはっきり申しまして、Sencha社から出たYUI Interface終了の記事に関する見解にはがっかりしました。なぜAngularJS単体と比較したのか疑問で「エコシステム」を理解していないためではないかと思えてならないからです。もしSencha社のコメントが「Web Componentsを意識」とか「Web標準との関係性、方向性」が記載されていたらまだ期待はありましたが、とても残念でなりません。

Senchaに関しては構造そのものもが１世代前のものと感じています。例えば独自のクラスシステムですが、今はTypeScriptやCoffeeScriptの方が数段優れてますし、コンポーネント指向とも言われますが、Web Componentsのそれとはまったく定義が異なります。テンプレートをJavaScriptで書かせるのもモダンな開発では評価できないところです。Senchaの経験があっても他のフレームワークへ技術移転できないのも問題です。

  • RIA(Proprietary Systemとしての)に近い印象
  • 良くも悪くもオールインワン
  • Web標準、ECMAScriptとの関係が不明
  • エコシステムに入っていない

外部リンク

 

JavaScriptフレームワーク比較の外部リンク

JavaScriptフレームワークの比較サイトは多いですので、是非こちらも参考にしてください。

 

最後に

JavaScriptフレームワークとしてこれからも追いかけるものの条件としては、Web標準、ECMAScriptとの関係だと考えています。これらをうまく取り入れようとしているフレームワークを使うことでエコシステムの枠組みに入りアーキテクチャとしての理解、フレームワークの乗せ変え等比較的行い易くなるのではと思います。そう言った意味で次のフレームワークには注目していきたいと考えております。

  • KnockoutJS
  • Ember.js
  • AngularJS

そして１年半前が今の状況なら間違いなくAngularJSを選択したと思います。その時々でプロジェクトにあったフレームワークを選ぶことが重要かと思います。このブログを書くことでHTML5 Experts.jpの読者が安易にBackbone.jsを選ばず自身で技術評価や情報収集しプロジェクトに導入されることを期待します。中には記事を読んだだけで経験の無いコンサルタントが様々言うこともありますが鵜呑みにせず対処して頂きたいと思います。