結局VanillaJSである。
上記のブログに刺激されて私もフロントエンドというかJavaScriptに対する思いを綴ったポエムをば。しかし、なんか書くのダルいので、大分大雑把にかくぞ。
さて、さっそく結論を述べよう。今のフレームワーク論争やらに対する解決策はVanillaJSを使うってことである。
フロントエンドSPAのフレームワークについて
まず、今のほとんどのフレームワークが使えないってのはそのとおりである。その話してみよう。その理由は、「フロントエンド」 ってのは一括りにできないからである。「ハッカーと画家」のとある言葉をアレンジして言えば「フロントエンドはユーラシア大陸のようなものである」。フロントエンドが関わる範囲が大きすぎるのである。ヨーロッパもあればアジアもあれば中東もあるという感じである。
範囲が大きすぎて、フレームワークとして扱えるほど技術が抽象化できないのである。だから、そもそもすっげーReact+Reduxに乗っかれるところもあれば、そうでないこともある。フロントエンド一般じゃなくて、もしそれがSPAの範疇だとしても、SPAのすべてのプロダクトで抽象化できない。というか、できていないと言った方が正しいのだ。
フロントエンドで難しいことやろうとすればとことん難しくできるし、フロントエンドで簡単にやろうと思えば簡単にやれる。だから、複雑なところたとえば、フロントエンドSPAやらであれば、フレームワークのことやAltJSやTypeScriptを考える人が多いだろうし(僕はそれでもVanillaJSで書くのだが)、そのクライアントのところでゴチャゴチャしないんだったら、jQueryとかでいい(僕はそれでもVanillaJS…)という考えもいるだろう。
また、フロントエンドのSPA自体の話を考えてみると、あれはフロントエンドでGUIをちゃんとやろうとすることだと思っている。そしてGUIは難しい。
GUIは難しいってのは、僕はツイッターとかで何度も言ってきたと思うけど、改めて言うと、まずその非同期性、GUI のアプリケーションや操作などの状態管理、ユーザ行動の非決定性、そして速度やらと戦わないといけない。また、そのUIデザインと実装を分けて考えることはできない面もある。インタラクションをきちんと考えると難しい。
そのようなGUIに大して設計、実装技術の歴史はあった。GUIの設計や実装の歴史を調べてみると、実際に昔から発展してきた。しかし、Webが台頭してくると、GUIの文脈は引き継がれず、Webが独自に発展していった。そうして、フロントエンドSPAの時代になり、またクライアントサイドMVCであったりとかフロントエンドはそういった議論になっていった。僕から見れば、それらは、昔のGUIの設計や実装技術をやりなおしているようにしか見えなかった。
だから、
ウェブフロントエンドの技術の進歩と興亡の速度には目を見張るものがある。
ということに大しては、違和感しなかくて、そもそも既視感がありありとあって、「進歩」しているようにはまったく思えなかった。(ただ、その中でも、WebのSPAだから出てくる問題もあってそこは、今までに無かったことはあった。)
また、フロントエンドSPAのフレームワークを見ていくと、僕にはただのWebアプリの延長としてか考えてない人達が多くて、そもそもGUIとしての実装を思ってない人が多い。だから、そういう人達と議論しても議論がまったく噛み合わないことが多い。サーバーサイドレンダリングをしたいだけの人達が多い。そのUIやらインタラクションを考えずに。だから、はっきり言っておこう。当たり前なのだが、フロントエンドとバックエンドの技術は異なるのだと。
まずその人達と会話すると「フレームワークの選定」から始まる。僕としては、おいおい、なんでいきなり、「どのフレームワークを使うか?」になってるんだ、いきなりフレームワークに乗っかる前提になっているだ? という思いになる。まず、設計の話をしろよと。設計してから、フレームワークをどのフレームワークにすべきか、そもそも使うべきか使わないか、などを考えるべきである。
さっきも言ったがフロントエンドはバックエンド程抽象化されてないのだ。だから、「デファクトのフレームワーク」だとか、「無難なもの」なんて無い。もちろん、僕はフレームワークをつかうなと言っているわけではない、いろいろ設計した上で、フレームワークにのっかれると思えば乗っかればいいのだ。しかし、設計もなくフレームワークにただ乗っかると、結果、フレームワークの設計と、自分たちのアプリケーションが合わないなんてことが多発する。そういう人達をたくさん見てきた。
僕はVanillaJSを使う。「VanillaJSを使う」という意味は、まず設計から始まるってことを言いたいのである。フロントエンドSPAについて必要なのは設計である。設計した上で、その「プラグイン」として、フレームワークやライブラリを利用するのだ。
また、おすすめしたいのが、フレームワークの実装を読むことである。また、フレームワークを自作してみよう。そうすると他のフレームワークの実装がより理解できる。自作した上で、他のフレームワークを利用することも多々あるのだ。むしろ、そのお陰で上手い乗っかり方が分かる思う。
「デファクト」に頼るな。JSの「トレンド」「デファクト」ってのは、多数の人達が「使っている」にしか過ぎない。JSの人達は、すごい人達ばかりじゃなくて、阿呆もいる。玉石混合なのだ。「デファクト」は単純にマーケティングが上手くいったとかしょうもない理由でデファクトになっていることが多い。だから、デファクトのフレームワークが一番素晴しいなんてことないし、安定しているなんてことはない。むしろ、安定していないからこそ「トレンド」がコロコロ変遷するのだ。
「トレンド」がコロコロ「変遷」する。と言った。ここで、僕は「進歩」したとは言ってないことに注意したい。トレンドが変遷することと、フロントエンドが進歩したを同じではないのだ。言うが、フロントエンドの技術はまったく「進歩」していないと思う。トレンドが変化しているだけなのだ。
jQueryじゃなくて、なぜVanillaJSなのか?
さて、jQueryを使い続ける、って結論の人達が多いのだが、僕はjQueryを使わない。というか使う必要が無いと思っているのだ。
以前、
なんてVanillaJSの入門記事を書いたのだが、そのコメントで書いたことを引用する。
たとえば、jQueryは速記記法であり、また、ブラウザ間の違いを吸収したJSのライブラリで、以前はデファクトスタンダードなライブラリで、DOM APIを学ばずjQueryだけ学習するということがことが起っていました。しかし、その分オーバーヘッドもあり、また、HTML5になり、ブラウザ依存度が低くなり、DOM機能も便利になった今、「jQueryが前提」という考えはとても技術的選択の視野を狭くする、もったいないものです。そもそも、フロントエンドエンジニアであるならば、DOM APIは知っておくべきじゃないでしょうか。
ということである。
もちろん、既に書かれたjQueryのコードを今更Vanillaにしろなんてことは言わないし、たぶん僕もそんなことはしないような気がする。しかし、今後フロントエンドのコードが肥大化するのであれば、まずVanillaにすると思う。
「脱jQuery」というのは、多くの人達は「フレームワークの利用」を考えるだろうが、僕は文字通り「jQueryをつかわないようにする」ってことをやると思う。「jQueryもなく、そこに設計されたVanillaJSのコードがあるようにする」ってことである。そうした上で、フレームワークの利用を検討するというのは考えてもいい。
ぺちぱーエンジニャーからのフロントエンドに対する思い - 虚無愛好部活動記録 こちらのほうで
結局jQueryはVanillaJSの便利なラッパーでしかなく、つらいつらいDOM操作の悪夢に悩まされるのはJavaScript使う以上どれでも変わらないでしょう。それなら記述量の減るjQuery使えばいいじゃん派です。
僕としてはjQueryを使っても、記述量はそこまで減らないし、DOM操作をするんだったらそもそも、VanillaJSでええやんって感じだし、なので、jQueryはVanillaJSの便利なラッパーではない。という意見である。「お前のなかではそうなんだろ」と言われそうではあるが。
設計しろよということ
結局僕は、jQueryも嫌ってはいないし、フレームワークを嫌ってはいない。設計されてないゴチャゴチャしたコードが嫌いなだけなのだ。
本来、ソフトウェアエンジニアである以上、設計することは当然なのだが、何故か、サボっている人達が多いのだ。サボってサボってサボりまくって、コードをごちゃごちゃにしている。本来であれば考えないといけないことを、考えずに過ごしている人達が多いのだ。本質的なことを考えずに、最新のトレンドだからだとか、騙し騙しコードを書いているのだ。
書くの疲れたので辞めにする。ああ、僕も丸くなったものだ。
@nobkz 丸くなったのぶかずさん、、、大人になるってザンコク、、、
— インターネットも届かない闇 (@no_maddo) 2017年5月5日
