先月くらいに「とほほのAngularJS入門」の存在を知ったときは大笑いしてしまったが、流行を超越した存在であるとほほが目をつけたという事実は無視できない事実だと気づき、 AngularJS を見なおしたのでちゃんと基礎くらいは勉強しようと思い直してとほほの写経と CodeGrid の記事を半分弱読んだ。 HTML タグの属性値にミニプログラミング言語みたいなものを書くんでしょ気持ち悪い、という先入観があったのだが最初の悪印象を我慢して乗り越え、 directive を自前で作るあたりの知識を得たところで React との相似に気づいた。
なぜ Angular や React が生まれたのかを改めて考えると、 Backbone では不十分だったからという理由がまず思いつく。それは「一つの Backbone.View の守備範囲はどの程度が適切なのか、について指針に乏しい」ということだったのだと思う。だから何かしらもっともらしい単位にもとづいた、適切に分割されたクラス設計を促す仕組みがフレームワークに求められた、というのが一つ。そして別の視点で、「Web ページにおけるコンポーネントという概念の重要さ」みたいなのも一因なんじゃないか、ということを最近思った。
Web はどんどんリッチになって、素朴なハイパーリンクから埋め込みコンテンツの存在感が増してきている。 YouTube の動画も Twitter のつぶやきも、どこかのページに埋め込まれてその場で再生したりふぁぼれたりする。これを今は各々が工夫して（最終的には iframe とか既存の HTML の枠内でどうにか）実現しているが、 Web の進化の要請に HTML とかがこたえる必要があるよね、という文脈から Web Components が出てきたりしたのではないか、という風に理解している。
で、 Web Components というかコンポーネントそのものだけを使いたいのなら polyfill 使えば済むけども、現実的には Web アプリケーションを作る上で「コンポーネント」という単位を使って設計・実装したいよね、という文脈から、「コンポーネント」をファーストクラスの機構としてサポートするフレームワークが、 Backbone の次世代として登場した。それが Angular と React で、両者の世界観はだいたい同じなのではないか。
ただしそこへ到達するためのアプローチと実装は対称的で、 Angular は HTML を主として HTML の範囲内で物事を表現しようとし、それでは難しい部分を JavaScript で補って物事を実現しようとしている（だから HTML タグの属性を多用したり directive で擬似 HTML タグのようなものを定義したりして、なるべくマークアップに寄せようとする）一方で React はすべてを JavaScript でコントロールしようとし、シンタックスシュガーとして JSX という擬似マークアップを提供することで利便性を補おうとしている。
つまりどちらも、もし Web Components が普及したとしたら、たとえフレームワークとして人気を維持していたとしても今と同じ姿ではなくなっているのではないか。本命の解決策がまだ利用できないので先行実装して補っていた部分が多少なりともあるのだと考えれば、本命が利用できるようになった時点でそこは置き換わるはず。だから Web Components という概念を、その実装が十分利用しやすいとはいえない今からでも理解を深めるために、フレームワークの両雄をどちらも学ぶことによって、違った側面から概念への理解を深める、というのはやってみる価値がある学習なのではないだろうか。
みたいな頭でっかちな理論武装というか言い訳で自己正当化しないと重い腰あげて勉強し始められない自分がどうしようもないな、と思った。あと Angular は directive 作るようになってからがキモというか本番で、みたいな話は Wantedly の相川さんが言ってたことを数ヶ月遅れでようやく飲み込めてきた、要するに単なる受け売りに過ぎない。
頭でっかちついでに、プログラマとして「ものにしたい」言語というか概念、みたいなものについても考えた。プログラミング言語が「ものになった」というのを、
- その言語を主とするプロジェクトを仕事としてこなせる
- その言語でちょっとした実用プログラムを自力で書ける
- その言語の文法や機能のみならずライブラリやエコシステムも含めて習熟し使いこなせる
を満たした場合と定義すると、自分の場合 Perl と Ruby は一応クリアしていると思っていて、 JavaScript はまだ道半ば（Node.js の Stream とかコア機能・概念の理解が乏しいし、 npm はおろか標準ライブラリの利用ですら知識がおぼつかない）だという自覚がある。その他いろんな言語を触ったことはあるけれど、どれもものにはなっていない。
で、じゃあ今後どういう言語をものにしたいか？と考えると、思いつくもの全部ものにしたい気になってきてどうしようもないので、言語という単位ではなく、「どういう概念を会得したいか？」ベースで考えてみると、
- 型（静的型付け）
- 平行処理
- Lisp のマクロ
- ポインタ
あたりが、会得しないままプログラマ人生が終わったら後悔するだろうなぁ、と思い浮かんだものだった。
こうしてみるとあまり選択肢はなくて、 Lisp のマクロは Lisp を|で学ぶしかないし、ポインタは C なり C++ なりで学ぶしかないし、並行処理はプロセスではなくスレッドを意図してるのでこれはスレッドのある言語ならなんでもよさそうだからあえて言語を選ぶこともなさそうだ。
問題は型で、そもそも Perl でプログラミングを学んで Lisp にずっと憧れている身としては、おれはもう強い動的型付けの言語にズブズブだからなぁ、と諦めたくなるけど、しかしやっぱり教養としてちゃんと勉強したうえで会得しておきたい。やっぱり Haskell とかなのか、それとも型推論をあえて避けて修行と思って Java で型をちゃんと書く訓練とかをしたほうがかえって身につくのか、など、なんともいえない。
みたいなしょうもないことを深夜から明け方にかけて書いているうちに眠くなってきてしまって、こんなことして一晩無駄にする暇があったらプログラム一行書くとかマニュアル一ページ読むとかしたほうがよっぽどマシなのに書かずにはいられないのはなんか呪いっぽいな、と思った。
