結局フロントエンドはDOMをいかにJavaScriptとかで操作できるかだと思う

業務でWebpackを使い始めていて、
「なんぞこれ。ビルドツールなのは知ってるけど」
ついで、JavaScriptビルドツールを調べると、でるわでるわ……。

• FuseBox
• Brunch
• Broccoli.js
• Middleman
• Mimosa

そんな折に行き着いたのが以下二件。

• 最近のビルドツールって何なの？ - 檜山正幸のキマイラ飼育記
• 結局VanillaJSである。 - nobkzのブログ

ああ、同じこと考えてた人居たんだ。特にnobkz氏のブログに感動したので、会社で「本日の…JavaScriptビルドツールの……調査結果です」と、社用GitHubアカウントでポエムGistを提出して逃げるようにして退勤してきた自分の本音を色々垂れ流す。

PugやStylusのビルドなら、NPMScriptsで十分だろ

Pug（旧Jade）
Stylus

割と最近思ってることがコレ。

npm-run-allなりyarn-run-allインストールして、npm build なり yarn build なりしたら、全部ビルドできるようにすればいいじゃない。なんだったらCoffeeScript（最近2の開発やってるんですってよ！ お兄さん、お姉さん！）のビルドも加えちまえよ。

って自分は思う。

そして今朝そんな違和感を持って、
「なんか、TypeScriptとかやるのに推奨されてるのかな」
と思ったりしたので、ちょいと確認してると、
React + TypeScript + Webpack
の組み合わせが多いらしい。

「まあ、たしかに言われてみれば、JavaScriptフレームワーク触ってたほうが良い時代っぽいよなあ」とは思うが、何か納得いかないので、言わせていただくとこうだ。

本当にフレームワーク使う必要ある？

大いにある。最近Webブラウザでできることは大きくなり、その分管理するものも多くなった。

そういった観点では確かにフレームワーク使ったほうが良いのかもしれない。

とはいえだ、
「実際やってることはJSONデータ参考にDOM操作するだけでーす」
という事やってるなら、別にフレームワーク使わなくてええやんと思ったりする。

過去にはこんなこと書いてたが、自分が本当にセッション管理とかCGI（？）の知識が深ければ、マイクロフレームワークも使わずに、フルスクラッチで書いてたのかもしれない。

何となく感じるズレ

ここまで書いて、
「あ、やっぱり自分間違ってたわ」
という落ちになるのだが、多分僕は未だに
「JavaScriptはDOMのデータ操作言語」
くらいにしか思っていないからこんなこと書いたのだと思う。

もはやJavaScriptは「Webブラウザ」っていう「GUIフレームワーク」をいじるための言語なのかもしれない。それでも乱暴なことを言うと、JavaScriptはWebでのTcl/Tkなのだろう。と思ってしまう。

正直、開発者がブラウザでやりたいことにJavaScriptが追いついておらず、かつNode.jsが出てきてやれることが（独自実装ながらも）増えて、結果、JavaScriptは今日のような姿になったのかなと思ったりする。

個人的に危惧すること

これは嬉しい話かもしれないし、嬉しくない話かもしれない。

そのうちNode.jsとWebブラウザJavaScriptで書いたWebアプリ開発というのがカジュアルに行わるのだろうなと。

JavaScript得意な人にとってはこれ程嬉しい話はないだろう。しかしながら、私は嬉しくない。なぜなら、私はECMA 262は通読していないし、ましてやPromiseもろくに使えない。むしろコード通りに順次実行される世界しか知らない。

Node.jsを触っていて真っ先に思ったのが、
「俺の知らないところでコードの実行順序を変えるな！」
である。

しかしながら、アプリケーションユーザーはそんなこと気にしない。フリーズしたら「クソ」の烙印がおされ、そのアプリの使用をやめるか、遠ざかるのである。JavaScriptはそれを解決するために、あえて実行順序をずらしてくれるのである。フロントエンドにフォーカスするととても嬉しい話なのだろう。

---

ええい、やめだやめ。

これ以上無駄なことを書いててもなーんにもならん。

自分はアプリ開発者が増えるのは嬉しいが、ザルシステムが量産されるのは嫌だ。かといって自分がザルシステムを作らない保証なんて微塵もないので、結局この話は以下に集約される。

俺、JavaScriptのこと、何も分かってねえ……。