JavaScriptにはむしろもっと抽象化がもたらされるべき - Qiitaという記事で、もう少し踏み込んだ話を書いてみました。
某所でReact.js界隈の人に聞きたいというフレームが発生したのだが、はてなブックマークでコメントしたらIDコールされたので、反論をここに書くことにした。(最近は技術系記事はQiitaにしか書いてないので)。
あくまで僕が考えるなので、JavaScript界の人達が本当はどう思っているかはわからない。そもそもJavaScriptを本格的にさわり始めたのごく最近なので、JavaScript界では異端かもしれない。
元記事では論点(感情)が複数ごちゃまぜになっていたので僕は辛口のブコメを書いたのだが、論点をごちゃ混ぜにするのは意図的にやってるのならばただの詭弁だ。なので、まずは元の記事での論点を整理する。
- jQuery (or フレームワーク?)
- 言語採用
- React.js
- SPA
- 保守コストについてどう考えるか
jQuery
jQuery は、ブラウザごとの差異を吸収してDOM操作をする為のライブラリだ。僕もjQueryは不要だと考えるのだが、それは何故か？大抵のケースでは、直接DOM操作を行うという原始的なことをしなくても、Knockout.jsでもAngularJSでも好きなものを使えばいいからだ。原始的なコードと、フレームワークに従ったコード、どちらが技術的負債を生み出すかは言うまでもないだろう。フレームワークの要不要に関しては、それこそ、Ruby, Python, PHP ラブな人の方が理解していると思うのだが。
どうしても、DOM操作をしなければいけなくてなおかつペラ1程度のページいじるなら jQueryでもなんでも使えばいいのでは？フレームワークが不要でjQueryだけ使うみたいな事例がどれくらいあるのか？それはもうその人のエンジニア人生次第だろうから、僕があれこれ言う事でもないので好きにすれば良い。
言語採用
僕も以前はCoffeeScriptを使っていたが、今は完全にES2015(ES6と呼ぶのはやめましょう)に移行している。
トランスコンパイラを使うのって、結局「将来的には全部ES6になるのだから、今のうちからES6で書いておけば将来のメンテナンスコストとかも減ってうれしいよね!」っていうことなんだと思います。
今のJavaScriptにおいて標準仕様はES2015なのだから「将来的」ではなく現在の話だ。ES5という負の遺産を使い続ける事は技術的負債を生み出すだけなので積極的にES2015に移行すべきなのだ。
型が欲しいならTypeScriptかFlowTypeを使えばいいし、そうじゃないならよほどの事が無い限りはES2015を使えばいい。
JSX
JSXはあくまでコンポーネントをJavaScriptのクラス(ES2015のclass)に当てはめる為のトリックにすぎない。JSXはES2015やTypeScriptを、特殊な糖衣構文の拡張を行っているだけに過ぎない。別に新しい言語が登場したわけではない。
JSXが嫌なら他の手段はいくらでもある。
React.js
React+Reduxを実際に触ってみると何が違うかはわかるだろう (過去にReact+Redux入門という記事を書いた)。Reactのサンプルコードを読むだけだと単に面倒くさいと感じるのかもしれない。旧来のJavaScriptはDOMをホゲってあれこれするものだったが、ReactはVirtualDOMを使って管理モデルを抽象化しましょう以外の何者でもない。
少なくともReact+Reduxはある程度の規模があって活きてくる。ペラ1のウェブサイトを作る程度なら他のフレームワーク、たとえばKnockout.jsみたいな軽量ライブラリを使う方がよほどいい。
習得コストに関しては、普通のエンジニアであればさほど難しいものでもないだろう。古いJSの常識にとらわれていると大変だが、たとえばネイティブアプリケーションの開発をしたことがあるような人であればさほど違和感を覚える事もなくすんなりマスターできるはずだ。
僕自身はwebrxというRxJS系の(Knockout.jsみたいな)ライブラリを愛用しているがある程度の規模になってくると、Knockout.jsやwebrxのような単純なMVVMライブラリではしんどくなってくる。そこでReact+Reduxという事になる。
一部、ブコメで勘違いしている人もいたが、React.jsはSSR(サーバーサイドレンダリング)という技術を使う事で、静的ページの生成は可能なので検索エンジン問題も生じないし、ブラウザサイドでJSが切られていても問題は無い。
SPA
SPA (Single Page Application) という単体のページでJSによって遷移するというアイデアが何故有用か？それはJavaScript開発コストが急騰しているのが原因だ。
従来の考え方ではサーバーサイドメインでブラウザサイドはおまけだったが、これはDRY原則を保つの困難になる
という問題が生じる。オブジェクト指向において重要な「関心事」がサーバーサイドとブラウザサイドで引き裂かれてしまうのだ。
これを解決する手段は二つある。
- サーバーサイドをJavaScriptにしておいて、ブラウザとサーバーでそれぞれ同じライブラリを読み込むようにする
- サーバーサイドをAPI専門にしておいて、遷移をブラウザ側で管理する
どちらを採用するかは好き好きだが後者の方が望ましいと考える人達がSPAを採用するわけだ。
(追記: サーバーサイドをプレゼンテーション(Node.js)とAPI(任意の言語)に分離するのも手だが、実質2と同じ)
SPAにはJS遷移のため、検索エンジンにヒットしないという問題もあったが、それを解決するのがSSR(server side rendering)だ。SSRで静的ページの生成が可能だし、Reactは最初からSSRが考慮されている。
保守コスト
枯れた技術は本当に低コストで長い年月の保守・運用は可能なのだろうか？
たとえば枯れた技術と言えばJavaだ。僕はJava6の案件を見ていた事があるが、サポートが既に終了したJava6は大量のセキュリティホールを抱え込んでいたが、それは無視されていた。当時の上司はとにかく最新のJava (Java8) へのアップデートを渋っていたものだ。何故か。移行にはコストがかかるからだ。バージョンアップはこまめにしていれば、まだマシな方だ。それでも言語の大きな改変により痛みの伴うバージョンアップはそれなりの確率で発生する。僕はRuby1.8から2.0移行もPHP5.2から5.3移行も体験している。
次に枯れた技術の習得は、必ずしも、新規技術の習得に比べて低コストなのだろうか？個人的には疑わしいと感じる。たとえば、今の時代、新規でJava Tomcatの習得をするのは容易か？残念ながら僕には容易ではなかった。それなりに苦痛を感じながらあれこれ調べ回ることになった。個人の資質次第で、枯れた技術と新規技術の習得コストは変わる。それに、なんやかんやで古い情報は淘汰されてしまう。古い書籍は簡単に絶版になるし、ウェブの情報も古い情報は埋もれやすい。
また、枯れた技術で追加開発を行うコストは本当に低いのだろうか？開発が既にストップしているならいいが、そうじゃない場合、仕様変更、仕様の追加、そういった追加開発は普通に生じるだろう。この時、枯れた技術での開発コストはどうか。
追記1:
JavaScript界隈の話題がこれだけ賑やかになる大きな理由として、「ブラウザ環境で使える言語が他にないから、仕方なくJavaScriptを使っている」層の多さがあると思います。
元々サーバーサイドの人間なので気持ちはわからなくもないんですが、個人的にはRuby, Python, PHPなどでHTMLレンダリングを行うというのが筋の悪い古いやり方になっていくと考えています。理由は上にも書いた通り、サーバーサイドとブラウザサイドでのDRYの破綻です。無理して複数の言語がサーバー・ブラウザ入り交じった複雑な開発を続ける位なら、サーバーサイドをNode.jsにするか、APIに専念させる、あるいはサーバーサイドをプレゼンテーションとAPIに分離する、などのアーキテクチャを採用する方がよほど楽でしょう。
ウェブ開発のコストを考えるなら、Node.jsの採用をそろそろ本気で考えてもいいのでは？と思います。
自分自身、よく使う場面が「HTML自体は別途フレームワークやシステムで生成しているもので、インタラクティブな部分だけJavaScriptで補う」というような流れになっています。そのような場合だと、(薄いものでも)フレームワークを入れること自体にかかるコストが多くなってしまうので(とりわけ、もともとjQueryが入っていると、別途で入れるフレームワークと干渉しないかの検証も必要となる)、生DOMやjQueryで書いて済ませるのがいちばん合理的、ということになります。
DOM直接いじる(かjQuery使う)位なら軽量ライブラリ入れる方がマシだと思います。jQuery検証コストがライブラリ・フレームワークを使わずに生DOMいじるコストを上回るなら仕方ないでしょうが、新規に設計するならそんな事もないでしょう。既存のプロダクトなら、JS界の流行廃りなんて気にしなければいいでしょうし。
追記2:
ブコメで、いくつかjQueryでいい案件もあるのでは？との事なのでそれに対する反論。僕自身のスタンスは元から「コスト次第」だと言ってるが、jQueryでちょうど良いコストになる案件が果たしてあるのかどうか。
まず言えることは、ウェブアプリケーション全体を見たときに、ある程度以上の規模のドメイン知識が存在するようなものであれば、フレームワークを導入した方がいいだろう。さんざん書いている通り、サーバーサイドとブラウザサイドでデータやロジックの重複が生じるからだ。ここに関して突っ込みも入ってないが、反論を持つ人はいるだろうか？
次に、データ・ロジックともに重要視されないようなページであれば「本当にJavaScriptは必要なのだろうか？」という疑問が生じるが、jQueryでもなんでも好きにすればいい。僕は全くもってそういうものに興味が湧かないし、僕の人生に関わるとも思えない。どうでもいい話だ。
最後に
僕は直接DOMをいじるのはコスト面で見て見合わないと思っているので、webrxなりReactなりのライブラリ・フレームワークを使うべきだと考える。