小さいライブラリを採用する

僕がJavaScriptでライブラリを選定する際、迷ったら小さいものを使う。その理由について。

前提

前提として、枯れた環境で大きいフレームワークができるのは理解できるし、メリットも大きい。あるいは言語それ自身と区別できないぐらいに発達したフレームワークに依存するのも理解できる。RubyにとってのRailsとか、ErlangのOTPとか(いや、これは詳しくないけどそうなんだろうなっていう予想なんだけど)。

危険信号

今のJS界隈は動きが早すぎて、何に依存するのも危ない。とくにフレームワークと銘打たれたものは、でかすぎてどれも危険信号を放っている。

数年後、廃れてしまったフレームワークで開発し続けるのは、僕個人としてもあまり関わりたくないし、現場の離職リスクとして数字に出るだろうし、採用後の教育コストの問題になる。だいたいそういうものは元の設計者もいなくなるものだ。プロダクトの死を意味する。

リスク予測

じゃあ何を採用すべきか？リスクのない選択肢なんて存在しないけども、リスクの予測はできる。 そのプロダクトを捨てるときに、どういうステップを踏めばいいか。モジュール化されているか。フレームワークに起因する顕著なボトルネックは存在しないか。テスタビリティがあるか。モジュールが交換可能になっているか。フレームワークとビジネスロジックが密結合していないか。制御フロー以外に介入していないか。あなたの手元で開発・運用するにあたり、フレームワークのレールから外れて、他の環境で再現不可能なパッチを当てていないか。

大事なのは設計思想と設計哲学

っていう問題もあるんだけど、次に大事なのは思想と哲学で、本当に大事なことは、そのフレームワークを通して得た経験を持ち越して次のプロジェクトで強くてニューゲームすることだと思う。根本となる原理さえ学べば、どこへでも持っていける概念を、体で覚えることができるもの。それこそが選択するに足るものだと思う。

これ一発で全部おっけーっていうのは、ソフトウェア開発の歴史が50年ぐらい足りないし、もしかしたら1000年後も開発言語が乱立してるかもしれない。だから大事なのはどのように問題を解決するか、その道筋にガイドを示す発想を体に染み込ませること。

Backboneから学んだもの

たとえば僕はフロントエンドでそれなりにBackboneに投資してきたんだけど、スクラッチのプロジェクトでBackboneを選ぶかというと、たぶん選ばないと思う。その判断基準は、Backboneが提示するアーキテクチャが導く歪みを大体察していて(それらはどうも非常に言語化しにくい)、それを解決するフレームワークが他にあるからで、それらもきっとまた違った欠点があるはずだけど、今よりマシになるという直感がある。

とはいえ、Backboneで学んだクライアントへMVCを導入しようとする姿勢、DOMのコンポーネント化の思想はどこへ言っても使えるものだし、本体が薄かったせいか毎度プロジェクトごとにカスタムしたフレームワーク自体を作るという発想に近くなるので、他のフレームワークが何を解決しようとして設計されたのか、という目線を手に入れやすかったように思う。というわけで、今からBackboneを触ってみてそこで満足できなかったら他のものへ、というステップは悪くない。時間があれば、だけども。

ベストプラクティスをろ過する

ここ最近、いくらかBackboneの学習コストが高いと言ってる人をみかけたんだけど、僕はそれはたぶんその人の勘違いだと思っていて、このフレームワークは本体の学習コストは皆無に等しいんだけど、Backboneそのものがベストプラクティスを提示しないので、各々が他の人の運用パターンから自分のベストプラクティスを構築するコストが高い、ってことだと思ってる。それを今考えたくない人はMarionetteとかChaplinを使えばよい。いきなり突撃するとレールにそぐわない使い方をして爆死すると思うので、そういうのは本プロダクトで採用する前に爆死するぐらい使い倒してほしいという気持ちがある。

貧弱な環境の方が、チューニングのやり甲斐がある

あとこの記事書いた後に付くコメント大体予想ついてるんだけど、じゃあフロントエンドに拘ってなくてスマホのネイティブとかローレベルとか他の環境もやれよっていう話になるとは思うんだが、僕はフロントエンド環境でネイティブのUXに負けたくないということに競技性を見出していて、個人的にそこが楽しい。まだしばらくはここで遊べると思っている。