AngularMaterial VS Polymer - UI部分だけそれぞれで実装・比較して分かったこと

あるWEBアプリをAngularMaterialを使って実装しているが、最近Polymerが1.0になったので、実験的にUI部分をPolymerで実装し直して比較してみることにした。

ここに分かったことをまとめておこうと思う。


UIコンポーネントの数

AngularMaterialの方がベーシックに使えるものが多い。最近ではFAB Speed Dialなどのコンポーネントが増え、益々充実してきている。Polymerにもgoogle-mapなどのコンポーネントが増えてはいる。


UIの動作速度

Polymerの方が速い。PolymerはアニメーションにWebAnimationを使用しているが、AngularMaterialはngAnimateに依存しているからだと思われ。


レイアウトのしやすさ

Polymerの方が分かりやすい。Polymerではvertical, horizontalとするところを、AngularMaterialではrow、columnとなっている。


レイアウト処理の軽さ

Polymerの方が軽いのではないかと思われる。Polymerではレイアウト関連の指定は「class="layout horizontal"」のように全てCSSのclassだが、AngularMaterialでは「layout="row"」のようにタグのアトリビュートで行われるので内部でカスタムタグの処理をしているだろうから。


ライブラリとしての扱いやすさ

AngularMaterialの方が扱いやすい。ngAnimate、ngAria、ngMaterialの各モジュールとCSSをひとつ読み込むだけでたくさんのUIコンポーネントを使うことができる。逆に言えばムダが多い。bowerのコンポーネントの数で言えば３つだ。

一方、PolymerはHTML importの仕組みによって必要なコンポーネントを必要なだけ組み込めるようになっているのでムダが少ないが、小さいファイルをたくさん読み込む必要がある。例えばFAB一つ使うだけでもbowerのコンポーネントは３つでは済まない。


起動速度

AngularMaterialの方が速い。参考までに、今回のアプリでは10回平均の起動時間（msec）はこのようになった。

	AngularMaterial	Polymer
PC	1132	1665
PHONE	4892	6435

このように、PolymerはAngularMaterialに比べて約1.3〜1.5倍の起動時間がかかった。

原因として考えられるのは、依存ファイル読み込みのオーバーヘッド。AngularMaterialは読み込むファイル数が少ないがPolymerはとても多い。

解決策として考えられるのは、ファイルのconcatだが、HTML importの仕組みだと怖くてヘタにconcatするわけにもいかないし、concatする勇気があっても慎重にファイルの依存関係を調べる必要があり面倒過ぎる。

特にモバイルのような遅いネットワークでは、読み込むファイルの数が多いということは相当なオーバーヘッドになり、悪くすると数倍の起動時間が必要になる可能性もある。


AngularJSとの統合のしやすさ

これはもちろんAngularMaterialの方が統合しやすい。Polymerのコンポーネントはそのままではng-changeなどのマッピングができない。マッピングするためにはこのライブラリを使う。

GabiAxel/ng-polymer-elements

ただ、このライブラリを実際に使ってみたところ、paper-toggle-buttonのng-changeにマッピングされたメソッドでそのpaper-toggle-buttonのON/OFF状態を調べたところ、完全に状態が逆になっていた。


結論

特にPolymerのUI動作速度は捨てがたいが、AngularMaterialも我慢できないほど遅いということは無い。どちらかというと起動速度の方が問題なので、現状のAngularMaterialを引き続き採用することにした。