いかにしてJavaScriptを学んだか

まあ、気持ちは分からないでもないっすよ。

いかにしてJavaScriptを教えるか - mizchi's blog

ロートルの無駄話程度に思ってほしいのだが、私は、自身の経験より「Node.jsから」という案は賛成だ。

一方で、おそらく先の文章を書いた人はフロントエンド回りに詳しくてかつ心根が優しいからこそ「黒い画面に抵抗があったり、画面をゴリゴリ動かすのに最初から行きたい人」のことも勘案してcreate-react-appを持ち出したのだと思うけど(あと、先の文章上での学習者=ある程度以上のレベルの人だから、多少は要求する技術レベルが高めでも大丈夫だろう――という前提もあるだろう)、私は傲慢かつ狭量なので、あえてストロングスタイルに徹して「お前はGUIに手を出せるレベルだと思ってるのか? ふざけんな!」と学習者に対して暴言を吐くだろうなあ、例え相手がどんなベテランだろうともJavaScriptのコア言語の素人である限りは。この辺は単なるスタンスの違いでしかない。

Node.js案に賛成する理由は、私自身が8年前にJavaScriptを学んだ時の状況に割と近くて、しかもJavaScriptのコア言語を学ぶという点では結構効果的で、かつ後にフロントエンド開発に放り込まれた際に役立ったからだ。まあ、8年前に手を出したのはNode.jsではなくWindows Script Host上のJScriptだったのだけど。

8年前はまだギリギリECMAScript 3の時代で、Prototype.jsからjQueryへの転換期で、「JavaScript入門≒(現在で言う)フロントエンド・プログラミング入門」だった、牧歌的で郷愁を誘う時代だ。あ、でもInternet Explorer 6が猛威を振るってた頃だから郷愁は無いか。

その頃私は、諸々の理由よりWSH + JScriptで社内向けツールを作ることになったのだけど、フロントエンド開発の経験もないJavaScriptの素人だった。C言語でコードをガリガリ書いていたし、GawkRuby 1.8でちょっとした小ツールは作っていたので、プログラミング経験自体はあった。でもJavaScriptECMAScript)のことは何も知らなかった。周囲は組み込み屋かデスクトップアプリの開発者ばかりで、フロントエンドの経験者は皆無だった。

WSHについては『WSHクイックリファレンス 第2版』という本があったものの、こいつはVBAVBScriptのポケットリファレンス系の本と同等のノリだった。「○○ができる」とか「××するなら△△でOK」といった内容の詰め合わせで、それはそれで助かるものの、JScriptの言語自体のしゃぶり尽くし方など微塵も書かれていない。

JScriptECMAScriptの方言の1つなので、言語本体の仕様や機能についての学習はJavaScript入門書で代用できないかと考えた。

残念なことに、その時代のJavaScript入門書は、例えるなら「『Swift入門』というタイトルだけど中身は『Swift + XcodeによるiOSアプリ開発入門』だった」みたいなもので、どれもこれもその正体はDOMを操作するスタイルのフロントエンド開発の入門書だった。JavaScriptの言語本体については基本的なところしか解説していなかったし、ArrayやStringなどの組み込みクラスの説明は歯抜け状態だったし、DOMやjQueryを始めとするフロントエンド固有の話題とごちゃまぜだった。

これではWSHを念頭に置いたJScriptの言語本体の学習には使えない。

先のSwiftの例に倣うなら、私は『詳解Swift 第3版』や『Swift実践入門 ── 直感的な文法と安全性を兼ね備えた言語 (WEB+DB PRESS plus)』に該当するようなJavaScriptの学習書が欲しかった。でもそっち系の本は『JavaScript 第5版』しか見当たらなかった。『JavaScript 第5版』は、多少なりともJavaScriptに浸った人からすると良書なのだが(実際、後で読み直してそう思った)、JavaScript素人向けには内容も物理的にも重すぎた。

ということで頭を抱えていた時に、世間では『JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティス』が大ヒット。その存在を知った私は『JavaScript: The Good Parts』でJavaScript入門することとなった。割と過激というか、作者の押し付けが強い癖のある本なのだけど、それでも8割ぐらいは鵜呑みしても問題なかったし、何よりも内容がJavaScriptのコア言語に絞られていたのがよかった。

こうして『JavaScript: The Good Parts』で学んだ私は、WSHなのにWSHらしくないJScriptの書き方をするようになった(WSH界隈は割とCやC++の流儀を引きずったままの書き方が多かった)。

で、その2〜3年後ぐらいになぜかフロントエンド開発することになったのだけど、そこでJavaScriptのコア言語について徹底的に学んでいたことが功を奏した。

その時はまだjQueryの時代だった(Prototype.jsは新規開発では使われなくなっていた)のだけど、今も昔も、その手のライブラリやフレームワークの作者はJavaScriptに通じている人であり、JavaScriptの言語仕様を十二分に活かすようなインタフェースになっている。

だから利用者は、まずライブラリやフレームワークを使いこなすためにJavaScriptに通じている必要があるし、同時に不具合などの調査のためにライブラリやフレームワークの中に潜り込んで解析するためにもJavaScriptに習熟する必要がある。

私はフロントエンドの知識・経験はなかったものの、JavaScriptのコア言語について学んでいたおかげで、割とすんなりとキャッチアップできた。でも私以外の人は、組み込み開発とかデスクトップアプリ開発とかの腕利きで私よりも遥かにレベルが上だったのだけど、逆に腕に覚えがあるがためにJavaScriptのコア言語についてロクに学ばずにコードを書いて、片っ端から地雷を踏んでいた。

ともかく、以上の経験があるので、例え将来的にフロントエンド開発に進むことが既定路線であったとしても、JavaScriptのコア言語の学習においては、フロントエンド開発とは異なる実行環境(つまりNode.js)でも全く問題ないと考えている。

むしろ、コア言語の学習とGUI開発を積極的に切り分けるべきで、そのためにもブラウザではなくNode.jsを処理系として採用するほうが良いだろう。

私はネイティブアプリ(それも伝統的なデスクトップアプリ)開発の経験という名の呪縛もあって、JavaScriptのコア言語の学習にて「黒い画面に抵抗があったり、画面をゴリゴリ動かすのに最初から行きたい人」を最初から考慮するのは筋が悪いと考えている。学習者がどんなベテランでも、「コア言語の素人」から抜け出せていない限りは、あえてGUIは外すべきだ。GUI回りはコア言語の活用スキルがある程度確立してからでも遅くない。

まず、JavaScriptは他の一般的なプログラミング言語以上に「使い手の器量」が問われる言語だ。個人的には、方向性こそ違えども、C言語並みに器量が問われると思っている。それだけ自分の足を撃ち抜きやすい。

これは、私が『JavaScript: The Good Parts』からJavaScript入門した変人だからという理由だけではない。先にも書いたが、C言語C++でデスクトップアプリを作ってきたベテランが、徒手空拳で昔ながらのDOMを直接操作するスタイルのフロントエンド開発に特攻して、地雷原でスペランカー先生ばりに即死していくのを5〜7年前に見てきたからでもある。

いや、みんな組み込み開発とかデスクトップアプリ開発とかの腕利きだったのよ。だけど、逆に腕に覚えがあるがために、JavaScriptのコア言語についてロクに学ばずにコードを書いて、片っ端から地雷を踏んでいたなあ。

逆に私は、プログラマとしてのレベルこそ低かったもののJavaScriptのコア言語について学習済みだったので、地雷回避は容易だったし、それほどCやC++に引きづられたJavaScriptのコードは書かなかった。どちらかといえば嬉々としてクロージャとか使っていたほうである(当時はまだC++11のラムダ式とか使える環境じゃなかったので、JavaScriptの後にC++のコードを書いた時に「関数オブジェクトを別途定義しなくてはならない」という現実に閉口した記憶がある)。

そういう経験があるので、JavaScriptの学習では、まずは範囲をコア言語に絞って徹底的に叩きこむべきだと思っている。柱を立てる前に土台固めが重要なのだ。

JavaScriptとは5年も無縁で、当時と今とでは全てが変わっていることは承知している。でも、JavaScript後方互換性を有しながらバージョンアップしている以上、ECMAScript 3の頃から抱えているコア言語の地雷は依然として埋められたままだから、JavaScriptは今(ECMAScript 2015)でも「使い手の器量」が問われる言語だと思っている。そりゃあ、varに対するletやconstのような代替機能は追加されているけどさあ……。

次に、冷静に考えると、JavaScriptを学ぶためにReact(もしくはAngularなどを含むお好きなライブラリやフレームワークを各自で当てはめてほしい)に一歩踏み出すということは、例えば伝統的なデスクトップアプリ開発でいうなら「C++を学ぶためにQtを学ぶ」とか「Javaを学ぶためにJavaFXを学ぶ」ということである。でも本来、言語とGUIツールキットは別物のはずだ。言語の学習とGUIツールキットの学習は分けるべきだろう。

ユーザがGUIにしか接したことがない現代、学習の初期からGUIを操作できることは、プログラミング初心者にもベテラン開発者にも訴求力があるだろう。プログラミング初心者はとっつきやすいし、ベテラン開発者はGUIから逃れられないからだ。

JavaScriptが「片手間の言語」だった時代には、確かにJavaScript(というかフロントエンド)文化圏はそれが容易な世界だった。直にDOMを操作することが許容されていたからだ。

でも今はもうそんな牧歌的な時代ではない。フロントエンドでのGUI開発は、デスクトップアプリ開発にてGUIツールキットを使うのと同等だ。GUIツールキットは、言語とは別に学習する必要がある。

だから、そろそろフロントエンド開発の文脈でも、「JavaScript入門」という名の「JavaScriptのコア言語+GUI操作」の抱き合わせ商法は撤廃してもよいころだと思う。で、撤廃するにあたり、ブラウザに代わるJavaScript処理系としてNode.jsは良い選択肢となる。

というかそもそも8年前ですら「フロントエンド開発」という括りで本を一冊に集約した副作用でJavaScriptのコア言語の解説が中途半端になっていた訳で、GUI側がよりヘビーとなっている今ではもっとアカンでしょうに。

まあ、こんなことは先の文章を書いた人は当然ながら知っているはずである。知った上で、しかし、あえて「黒い画面に抵抗があったり、画面をゴリゴリ動かすのに最初から行きたい人」のことも考慮しているのである。その傍証として、学習範囲をなるべくJavaScriptのコア言語に近い領域に留めるために制約を設けている。AngularよりもReactを選択している点や(「AngularはAngularの世界観が強くて、おそらくJSのルールなのかAngularなのかの区別がつかないし」というあたり)、ReactはReactでもcreate-react-app縛りを提唱している点がそれだ。で、そういう制約を考えられる程度には、フロントエンド方面の知見を色々と持っている人である。

逆に私は、そこまでフロントエンドの知見を持っていない(それどころかここ数年JavaScriptとは無縁の浦島太郎である)ので学習者をフォローできないだろうし、過去の経験より「例え学習者がベテラン開発者だったとしても油断はできないぞ」というバイアスがあるので、最初からGUI回りをスッパリ切り捨てるだろう。

結局は、その程度のスタンスの違いでしかないのだ。大騒ぎするほどのことではない。