基本トピック
上級トピック
その他
Mithrilと他のフレームワークの違い
JavaScriptのフレームワーク同士で比較しても数多くの相違点があります。それぞれのフレームワークのメリット、欠点を評価するのは骨の折れる仕事です。
このページではMithrilと他のよく使われるフレームワークの違いについて説明します。中には関連しているが、まだまだ若いものもあります。
コードサイズ
Mithrilと他のフレームワークの違いの中で、もっとも分かりやすいものはファイルサイズです。Mithrilはgzip圧縮された状態で7.8kb前後で、他のライブラリへの依存もありません。
gzipされたコードが小さいのがアピールポイントというのは、非圧縮時にとても大きくなることを隠しているように見えるかもしれません。非圧縮のJavaScriptはページロードのたびにパースと評価が行われます。いくつかのフレームワークでは環境によっては数10msにもなりますが、このコストはキャッシュできません。
このコストは、シングルページアプリケーションでは影響は小さくなりますが、複数タブで同時に開かれたり、性能の低いデバイスで実行される場合はそうではありません。
ホームページのパフォーマンステストでは、Mithrilと他の有名なフレームワークで、コードのパースと評価にかかる時間の比較をしています。すでにご覧になられたとおり、大げさではなくて、gzipされたサイズ以上のパフォーマンスが出ている事がわかります。
ドキュメンテーション
もう１つの比較ポイントはドキュメントです。人気のフレームワークのほとんどは、最低限のドキュメントしか提供していませんが、多くの人は便利なサンプルが欠けていると感じていたり、上級のトピックは外部の情報まかせになっていたり、場合によっては基本的な情報すら外部の方が詳しかったりします。
これは特に、過去の大きな変更があると問題になります。StackOverflowで見つけた解答が最新版のフレームワークでは動作しないということがあります。
Mithrilは、github上で見ても、ソースコードそのものよりもドキュメントの方が大量にあります。また、自動生成のドキュメントはひとつもありません。
すべてのAPIは人間に読みやすいように書かれており、サンプルコードもたくさん書かれています。すべてのドキュメントが人の手で書かれているため、ドキュメントに知りたい情報がきちんとかかれているというメリットがあります。ドキュメント生成ツールではインタフェースやコールバックのパラメータなどが抜けがちです。
また、ガイドのセクションでは、すべての部品をどのように組み合わせていくかという内容もカバーしています。
Mithrilのビルドシステムは、過去のバージョンのコードとドキュメントをすべてアーカイブします。過去のバージョンの情報がなくて困ることもありません。
Mithrilはまだまだ若いのですが、良いドキュメントを提供することに対してどれだけのコミットメントをしているかを理解してもらえれば幸いです。
アーキテクチャ
アーキテクチャ面でみると、Mithrilが他のフレームワークと大きく異るのは、拡張する元となるベースクラスを提供していない点です。
よく言われることは、ライブラリと異なり、フレームワークはどのようにコーディングをするかを指示してくるものであると言われます。この意味では、Mithrilは本当はフレームワークではないと言われる可能性があります。
決まった設計のパターンでプログラマを拘束して、画一化された実装をさせるのではなく、Mithrilは従うべきイディオムのパターンを提供し、必要であればツールを提供するというアプローチをとっています。これにより、開発者はフレームワークにロックインされることなく、オープンなコードベースを得ることができます。
これに関連する他のフレームワークとの違いとして、これらのフレームワークはよく、考えつく限りの便利なメソッドが満載になったフレームワーク固有のベースクラスを提供していて、開発者のクラスにこれを継承させます。実際に使うかどうかにかかわらず、JavaScriptではこれらのユーティリティメソッドもすべて子クラスにコピーされます。
Mithrilの必要な時に必要なツールだけを提供するアプローチでは、コアのMVCパターンを実装するときに、隠れたパフォーマンスのコストを負わされることはありません。また、フレームワークに対して、特定のパターンに対する特殊なシンタックスを覚えさせるような無用なラーニングカーブはありません。
ビューレイヤーパラダイム
有名ないくつかの古いフレームワーク(jQueryやBackboneなどは特に)は、ビューのレイヤーに対しても、より手続き型寄りのパラダイムを採用しました。開発者が毎回、開発対象ごとにビューレベルのコードを手書きしなければなりません。
「すべてを描画する」ルーチンに加えて、パフォーマンスを向上させるために、部品を追加する、削除するといったコードの実装が必要で、コード量がとても大きくなります。リストを表示するコードを実装するときは、毎回この作業が必要です。
Mithrilのビューレイヤーは宣言的なコードになるように設計されていて、よりHTMLに近くなっています。表示するコードを書くだけですべて完了します。通常、このような設計の決定は折衷案になりがちです。アプリケーションコードの複雑さを減らそうとすると、パフォーマンスのコストが必要になったりします。しかし、ホームページのパフォーマンス比較が示す通り、Mithrilではこの両方を達成しています。
特定のフレームワークとの比較
注意: このセクションの説明にはバイアスがかかっているかもしれません。そのまま鵜呑みにせずに、参考程度にお読みください。
jQuery
jQueryはどこでも使われ、巨大なエコシステムを構築しましたが、それ自身はMVCフレームワークではありません。
MVCパターンをjQueryを使って実現するための共通の書き方といったものは存在しません。そのため、この足りないところを補うために数多くのフレームワークが作られました。
言い換えると、MithrilとjQueryの書き方は大きく異なっています。Mithrilは宣言的なスタイルでDOM関連のコードを書くことが可能で、コードの複雑さは低減されています。それに加えて、共通のアプリケーションの構造を提供しています。
他に大きく異る点は、データの取り扱いです。jQueryはDOMをデータ構造のための箱として使いますが、Mithrilはデータをそれと分離したモデルレイヤーに分けようとします。
Backbone
Backboneは当初、jQueryベースのアプリケーションの構造化をする目的で設計されました。開発者に対するBackboneのセールスポイントの1つは、既存のjQueryの知識を活かした上で、コードをきちんと構造化するための「ついたて」を提供するというものです。
BackboneとjQueryとの組み合わせたスタイルを使う場合、Mithrilではビューコードの記述に宣言的なスタイルが強要されるため、大きくことなります。
他に異なる点としては、Backboneはワークフローに関しては関与しません。アプリケーションを組み立てていくための手順に関しては特に定めていません。これはフレームワーク適用の柔軟性を高める点では悪くないのですが、開発チームのスケーラビリティやコードベースの探索のしやすさの点で理想的とはいえません。
Mithrilはこれとは対照的に、このガイドで示しているようなアプリケーション開発のパターンを共通言語として広めようとしています。それにより、「質の悪いMVCもどきのパターン」が広まるのを防ごうとしています。
技術的な側面での大きな違いは、Backboneがイベント駆動に重きをおいている点です。Mithrilはこれとは対照的に、「どこから来たのか分からない」といった種類の問題を避けるために、オブザーバパターンをなるべく避ける実装になっています。イベントからイベントへ、長いチェーンになっていると、何がコードを起動しているトリガーになっているのか理解が難しくなることがあります。
「リアルタイム」を標榜するアプリケーションでこの問題をこじらせると、条件判断を間違えてイベントのトリガーが循環し、無限ループができてしまってブラウザが応答しなくなることもあります。
それ以外の違いとしては、フレームワークがターゲットとしている層です。BackboneはjQueryに慣れている人にアプローチしています。MithrilはサーバサイドMVCフレームワークの経験を持っている人が親しみやすいように設計されています。
Angular
AngularはGoogleにより開発が行われているMVCフレームワークで、宣言的なビューとテストしやすさに重点が置かれています。サーバサイドのMVCフレームワークのある人がすぐに使いこなせるように作られている点など、多くの面でMithrilと非常に似通っています。
一番大きな違いは、AngularとMithrilのテンプレートです。AngularのテンプレートはHTMLの中に定義するという、伝統的な方法を取っています。この方式は静的なテキストを作成するのは書きやすいというメリットがありますが、HTMLの文法を密結合してしまっている欠点がありますし、デバッグもしやすいとは言えません。
もう1点、Mithrilホームページを見て分かるように、Angularは他のフレームワークよりもパフォーマンスで引けを取ります。巨大なAngularのアプリケーションのパフォーマンスは厳しいものがあり、それに対応しようとするサードパーティ製のライブラリもいくつかあります。経験から見ても、Angularのパフォーマンス向上させるのは難しいです。
MithrilはAngularからの学びにより、控えめな実装で複雑さを下げ、プロファイリングしやすい実装にしています。
AngularとMithrilの大きな違いといえば、フレームワークの複雑さです。Angularは数々のサブシステムを持ち、パーサ、動的スコープシステム、デコレータなどより多くのプログラミング言語によるロジックを含んでいます。Mithrilはそれとは対照的に、よりクラシックなMVCをサポートするのに必要な機能だけを備えています。
Ember
Emberは伝統的なMVCフレームワークだけではなく、さまざまな大量のヘルパーコードを含む、非常に大きなAPIセットを提供する広範囲に渡るMVCフレームワークです。
EmberとMithrilの一番大きな違いは、このアーキテクチャの違いに収束します。広範囲に渡るため、急峻なラーニングカーブを持ち、幅広くベンダーにロックインされます。
Emberはまた、アプリケーションのアーキテクチャがどうあるべきかを厳しく規定しています。そのため、裏で何が起こっているのかが不透明で見通しにくくなっています。
React
ReactはFacebookによって開発されたコンポーネントエンジンです。ReactはMithrilと似たようなアーキテクチャを持っています。DOM操作がテンプレートシステムのボトルネックであるという考えを共有し、仮想DOMツリーを持って差分だけを実際のDOMに反映するという実装を持っています。この比較はしやすいです。
見た目で一番大きくことなるのは、ブラウザ上でそのままは動作しないJSXという文法です。Mithrilのコンパイルしていないテンプレートはそのまま動作します。どちらもコンパイルは可能ですが、Reactのコンパイル済みのコードには仮想DOMエレメントごとの関数呼び出しが残っています。Mithrilのテンプレートは静的なJavaScriptのデータ構造になるため、関数呼び出しはありません。
他に違う点といえば、Mithrilは単なるテンプレートエンジンではなく、MVCフレームワークとして統一的に動作するように作られているため、アプリケーションコードに再描画命令を挟み込んでMVCフレームワークのパターンを逸脱することなく、非同期通信のネットワークアクセスなどを探知して適切に再描画行う再描画エンジンを提供しています。
また、そのように広い範囲をスコープに入れているにもかかわらず、MithrilのファイルサイズはReactよりも小さくなっています。
Knockout
Knockoutはデータバインディングにフォーカスしたライブラリです。これは伝統的な意味でのMVCフレームワークではありませんが、Knockoutが推奨しているスタイルに従ったコードは、ビュー・モデルと似たコンセプトを持ちます。
Knockoutのビュー・モデルはモデルとコントローラレイヤーを1つに融合させるものです。それに対して、Mithrilははっきりと2つのレイヤーを分離しています。
また、Angularと同様にテンプレートがHTMLに書かれるため、Angularのテンプレートと同じ利点・欠点があります。
Vue
Vueは比較的新しいテンプレートエンジンですが、パフォーマンスのベンチマークでは目覚ましい結果を残しています。
これは完全なMVCフレームワークではありませんが、Angularのテンプレートと似ています。ディレクティブやフィルタなど、機能に対して同じ用語を使っています。
Mithrilともっとも異なる点は、ViewがInernet Explorer 8以下では動作せず、代替のない機能を利用している点です。MithrilはPolyfillで補完できない機能は使ってないので、もしIE6以降ののブラウザやBlackberryに対応させる必要があれば、足りない機能を補間して対応させることができます。
Vueの実装は巧妙に配列のメソッドをハイジャックします。JavaScriptの配列をきちんとサブクラス化することが難しくなるため、抽象化の漏れに直面することがあります。
Mithrilではこのように「魔法」の型を避ける実装になっています。