Angularが好き
ボクは本当にAngularが好きで、もはや恋するレベルに達していて、今ではもう実案件に使っている。
イカ理由。
- APIがほんっっっっっとうに糞
- 趣味の問題といえばそうでもあるが僕は糞だと思う
→ 趣味には口を出しません。そう思うならそうです。
- 実装が黒魔術
- 良識あるJSエンジニアなら Function.prototype.toString() しない
- 実際に一部のクロージャが破壊されてて挙動が直感に反する
- DirtyCheckの実装、表面的にもDirtyな挙動として現れるのでデータバインドとして何も嬉しくない
→データバインドだったり、Web Components のような、未来にnative実装されるAPIを包括的に実装しようとした結果の１つだと思ってます。
もっといい方法はあるのかもしれないですけど、Angularではこうしてるよっていうのが現状なのかなと。
上記で毒づく程不満はないです。
→ここだけ凄い気になったんですが、そんなことはないみたいです。（気になる方はtweetを追っかけてみてください）
Object.observe() が AngularJS だけのために先行実装されたということはないそうです。確認できました。
— Eiji Kitamura (@agektmr) 2014, 10月 6言ってしまえば Object.Observe(O.o) が実装されて困ることって無いですよね？嫌なら使わなければいいだけの話。むしろ実装されたことによって、未来の技術を先にお試し出来る、と捉えることができるし。
O.oをつかってデータバインドさせるなら今のうちに勉強しておくと、未来の自分に投資できます。
Angularのデータバインドが嫌いなら、Chromeに実装済みのO.oを利用して自身で作ればよいのです。
- Angularの内部モジュール同士が密結合
- DI, module, factory, それぞれ大きなテーマなのに密結合
- 使いはじめるとAngularをやめることが困難
→これもフルスタックが故の問題かもしれないです。個別にモジュールを選べるなら疎結合でないとダメですけど、フルスタックなのでその辺は密になっても別に。。。
何言ってもフルスタックなので内部モジュールは密結合でもいうほど気になりません。もちろん疎結合になるなら、より良いとは思いますが。
- パフォーマンス面で他フレームワークに対して長所を持たない
- というか基本的にAngularでSPA作ると上述のDirtyCheckの問題で悪化する。その解決策がObject.observeを政治的に前倒しするってのも気に食わない。
- 何をやるにもググって解決しなければならないぐらいには一貫性がない
- 中身が黒魔術 + 設計が一貫してないから解決するためにこうする、っていう直感が働かない
- 検索で各MVWとの比較で検索数一位だから流行ってる！みたいな意見あるけどこんな歪な設計するとググらないとなんもわからん。Railsみたいなまともな規約もないし。
→これは元々Angularの設計思想で、パフォーマンスを「超」意識しないといけないようなサービス、Webアプリには向いてません、と明言しています。
あと、canvasなどを扱ってアレコレしちゃおうってのもAngularの思想には今のところないです。
なので、よく「0.1秒レスポンスが遅れると売上が○%落ちた」みたいなサービスには確実に向いてません。
これを目的にAngularを採用するのであればやめましょう。お門違いです。
ただし、O.oでAngularが実装されるようになれば、その点もある程度はクリアできるのかなと期待をしています。期待なので叶うかは別ですが。。。
- JavaScriptのノウハウが生かせない
- Angular流儀を強制されて他のモジュールと繋がらない
→Angularで扱えるように、ラッパーを作りましょうっていうのがナレッジになってます。
この辺はたしかに癖があるので、慣れるのに大変かもしれませんし、ラッパー作るの大変かも知れません。
あえていうなら、安易にjQueryプラグインを導入するな！です。わかってて使うのだよ、ということです。
とはいえ、メジャーなものはAngularでラップされていたりするので、極端なもので無い限り心配する必要もないかなーと思ってます。
- 最後に
MEANの話は出なかったけども、中の人がdisられたってちょー凹んでたので、反論というかなんというか。
ま、なんか今回はdisり方が雑だなーって思った。むしゃくしゃしてやった感否めず。
お財布みつかるといいね。
