「JavaScript ライブラリをまとめてみるぜ」から1年経って…
昨年2016年5月、技術ブログの Corredor に、「JavaScript ライブラリをまとめてみるぜ」という記事を書いた。
当時はまだレガシーシステムを保守する前職に就いていて、フロントエンドの最新技術に付いて行きたくて、調べたことを書いていた。
1年経った今、自分は転職してフロントエンド開発をバリバリやっている。この記事に挙げた技術も実際に使用しまくっている。
そこで、この1年間でこれらの技術動向がどう変わったか、もしくは自分の捉え方がどう変わったかを書いてみようと思う。
パッケージ管理系
パッケージ管理を行うツール群、以前の記事ではこう書いていた。
名前 要る？ 概要 Node.js (のーど・じぇーえす) ○ JavaScript なのにサーバが立てられたりする。npm が付いてくるからまず入れる。 npm (えぬ・ぴー・えむ) ○ JavaScript ライブラリのバージョン管理ツール。Node.js を入れるとついてくる。もうなんか必須くさいし頑張る。 Bower (ばわー) ○ フロントエンド系のバージョン管理ツール。npm との違いは扱うツールがサーバサイド (npm) かクライアントサイド (Bower) か (どっちにもあるツールもある)。Twitter 製らしい。npm でインストールする。
Node.js は v6 系が LTS (安定版) になり、現在は v8.2.1 が最新版。業務では v6 系を使っていて、もう v5 系以下は見もしない。
Electron アプリを作ったりする時や、Json-Server みたいな簡易サーバを立てたりする時に、Node.js に頼っている感がある。
npm は相変わらず機能が多く大変だが、だいぶ理解してきた。これを書いた頃は package.json のことも npm install --save-dev のこともよく分かっていないレベルだったが、ちゃんと使いこなしている。個人で小さなパッケージを作って公開とかしてみたい。
Bower も使ってはいたが、もう見なくなった。Bower の必要性は、ビルド時に JS や CSS のライブラリのファイルを Concat するために必要だったのであり、Gulp なんかでどのファイルを引っ張ってくるか知るためのものだったと捉えている。ES2015 や TypeScript、SASS (SCSS) で import しておけば、ビルド時に Webpack が自動的に解釈してくれたりするようになっているので、最近は使わなくなった。
JavaScript を楽に書けるようにしてくれる・コンパイルする系
名前 要る？ 概要 Babel (べーべる) ○ JavaScript の次期標準仕様みたいな ES2015 (ES6) っていう構文で書いたものを、最近のブラウザが分かるレベルに置換してくれるツール。時代を先取りするなら先取った構文で書いておいて、このツールで置換すればいいじゃん的発想。意図が違うけど役割的には AltJS の一種と見なせるかも。 TypeScript (たいぷすくりぷと) △ AltJS とかいうヤツの一種。JavaScript に型の概念が付くよ的な。コレで書けって言われるまで覚えない。 CoffeeScript (こーひーすくりぷと) × TypeScript の仲間。Atom エディタの見栄えはコレで設定されてる。もう覚える気はない (そういえば一瞬「Dart」とか聞いた記憶もあるけどココらへん…？)。
Babel (ベーベルというよりはバベル) は ES2015 を書く時にお世話になっている。Browserify だの Babelify だの、なんだよ Preset って！とか色々あったけど、とりあえず理解できている。
TypeScript、まさかの現在使用中。というのも、業務で Angular4 を触っているので、ほぼ自動的に TypeScript で書くことになっている。ES2015 を触っていれば基本構文はほぼ同じ。型定義は結構面倒。Java における Eclipse のように、import を自動保管してくれたりするプラグインがイマイチ優秀でないので、いちいち手で import しないといけないところがある。型定義やアクセス修飾子を書けるだけあって、JavaScript というよりは Java に近い感覚。window につくグローバル変数が解釈されず独自にインターフェース書いたりしないといけないのも結構だるい。絶賛勉強中。
CoffeeScript は業務利用なし。Atom エディタのカスタマイズで触る程度。
JS をビルドしたりする系
名前 要る？ 概要 Browserify (ぶらうざりふぁい) ○ フロントエンドで Node.js 向けのモジュールを使えるようにし、必要な JS ファイルをガッチャンコして1つの JS を吐くヤツ。シンプルめなモジュール管理用のビルドツールってところか。 Webpack (うぇぶぱっく) △ 用途は Browserify に近いが、Browserify と違って複数の JS ファイルも吐ける。CSS のビルドもやれるようなので頑張れば Browserify と Gulp を捨てられるっぽい。機能が多そうなのと一つひとつ勉強したいのでコイツは少し後回しにしよう。 Gulp (がるぷ) ○ タスクランナー。定義したタスクを回してくれる。上のような直接 JavaScript ファイルをカキカキしてブラウザ F5 すれば反映されるような感じではない環境になるので、開発中は都度ビルドとかさせながら画面表示とか見るんだけど、そういうのを自動化できるヤツ。 Grunt (ぐらんと) × Gulp の先輩。もう Gulp でいいと思ってる。これは覚えないことにした。
Gulp・Browserify は少し前まで業務でもよく使っていた。個人的には今も好き。
Webpack は Angular CLI を使って Angular プロジェクトを作ると、裏側に Webpack が居るので少し勉強した。Gulp から移行すると、設定ファイルの書き方が宣言的であまり慣れず。
Grunt は更新が1年くらい止まっているようで、もう終わりかなー。
フロントエンドのアレコレ系
名前 要る？ 概要 React.js (りあくと) ○ View 操作するライブラリ。仮想 DOM とコンポーネント化って考え方で、jQuery 的な黒魔術にならずにインタラクティブな画面が作れる感じ。 JSX (じぇー・えす・えっくす) △ React 書いてるときに HTML を混ぜ込んだみたいなコードを書く、アレのことらしい。アレを解釈させるためのヤツっぽい。特に意識せずとも React 触ってればいいんでしょ多分。 Angular.js (あんぎゅらー) × HTML に JavaScript を埋め込むっぽい書き方をする View のライブラリ。React でもうこれはいいかな。 Vue.js (びゅー・じぇーえす) × Angular よりシンプル、って感じ。 Backbone.js (ばっくぼーん) × Angular みたくフルスタックじゃない使い方もできるよ的な、クライアントサイドで MVC を分けるライブラリ。Underscore.js もこの辺？ jQuery (じぇーくえりー) △ なんだかんだ使うんでしょまだ…
React.js は趣味で触ってた。コンポーネント指向は上手く作っていくと一つひとつがシンプルにまとまるから分かりやすくなる。当初の人気っぷりからするとだいぶ落ち着いた？
AngularJS、この当時は「1系と2系って何となく別物になった、Struts みたいなことでしょ？」程度の認識だったのだが、今はガッツリ案件で使っている。AngularJS と表記するのが1系、Angular と書くのが2系から4系以降。使ってみて分かったのが、Angular のフルスタックなフレームワークはチーム開発に向いているということ。「コンポーネント (1系ならコントローラー) はこう作って」「サービスはこう作って」という決まりが多く、これによって開発者ごとの実装方法に差異が発生しにくい。Angular CLI によってファイルの雛形も自動生成されるし、ますます開発者ごとに自分勝手なことはしづらくなっていて、統一感が生まれてチーム開発に大変向いている。
ただ、Angular4 以降は毎週パッチバージョンがアップデートされ、半年ごとにメジャーバージョンアップするという方針になっていて、新機能や破壊的変更に追随していくのが大変。公式のドキュメントも、一番分かりやすいとは云われているけど、そこからの発展形をどうしていけばいいのかが分かりにくい。ググる時も Angular4 の情報ではなく AngularJS の情報が出てきたり、見つかったと思っても Angular2 の話で Angular4 では使えなくなっている方法だったり、とにかくググラビリティが低い。Angular そのものの理解を深めないとまともには実装できず、しかし理解を深めるための文献が少ない・古くて使えない、というのがかなり難点。
Vue.js は巷では軽めのフレームワークで未だ人気。Backbone.js は使っている案件も散見されるが、もう下火。ちなみに Underscore.js は全く関係なく、これは Map の filter とかができる汎用ライブラリ。上位互換のライブラリに Lodash というものもあり、これも案件で使っている。
jQuery を使う案件も未だ見かけるが、「もうゴリゴリの DOM 操作は止めようね」な流れにはなっている。Angular を使う場合は自動的に純粋な DOM 操作ができなくなるので、jQuery をそのまま使うことはなく、jQuery チックな DOM 操作を行う Bootstrap のコンポーネントなんかも、Angular 向けにラップされたパッケージを使ったりする。これからどうなるんだろう。
CSS 関連
JS ライブラリから離れるけど、CSS 関連も npm パッケージとして扱うことが多く、もはや「JS と CSS は別物」という時代では完全になくなった。
生の CSS に近い記法である、SCSS を使うのが多いかも。Angular CLI も対応していて、勝手にコンパイルしてくれて楽チン。LESS は使っている案件は見たことない。
最近はほとんどベンダプレフィックスも必要なく、「IE11 すらも無視で！」「Edge なんか知るかよ！」という仕事が多く、大変助かっている。今年2月に自分が退職するまで、IE8 対応とかやってた前職はホントどうしてるんだろうな…。
機能的には便利になった CSS 界隈だけど、仕事をしていて思うのは、HTML の文書構造を意識した CSS 設計ができる人間が恐ろしく少ない。HTML 側に適当に class を増やしたら、メインの CSS ファイルの最上部に随時追加していって、カスケードも継承関係も全く無視、不必要なプロパティを記載していたりして「分かっていないまま書いている」人間が多い。JavaScript すらトランスパイルするのが当たり前になって、「分からなくてもエラーで弾かれる」やり方に慣れていると、「コンパイルもエラーで表示できないことも起こらない HTML」と、「よほどでない限りトランスパイルも失敗せず、文書構造を考慮した Lint がしづらい CSS」に対して、脳内 Lint、脳内トランスパイラを正しく備えた開発者は思いの外少ない。本当の「フロントエンジニア」を名乗るのに必要なのは JS の知識力よりも HTML・CSS の設計力じゃないか？ とすら思うほど。
自分は生の HTML・CSS を約20年触ってきたし、Strict・Valid 厨だから、なぜか HTML・CSS だけ雑に書こうとする人間が多くて物凄くイライラしている。勉強しろ。
自分の周りでは Bootstrap ベースの案件が多く、<button type="button" class="btn btn-lg btn-primary"> のように「何回『ボタン』って書くんだよ！！」みたいなコードも、少しは慣れてきた。CSS にも「フレームワーク」「ライブラリ」が台頭してきた結果、以前ほど「見た目を表した名前ではなく論理的な名前を…」みたいなことは云われなくなり、「ライブラリとして大きなボタンを提供するには btn-lg って名前付けるしかないじゃん」ってな風潮。グリッドシステムは Excel 方眼紙を彷彿とさせて嫌う人もいる一方、row と col の概念も理解せずデタラメに使っているバカも散見される。
以上
1年間、JS ライブラリを色々扱ってきて、仕事にしてきて思ったのは、こんなこと。
- それぞれのツールに対する知識はなんとでもなる。
- どれだけそのツールの API (使い方) を知っているか、という知識量は、突き詰めれば暗記モノということなので、決まりを全部正確に覚えられればよく、自分の推測は要らない。暗記型の文系でも出来る。
- ただし暗記は「全てを」「正確に」覚えないといけない。プログラミングは通常の口頭会話とは違い、「ほら、アレだよ、何かこう…」という曖昧なアウトプットでは理解してもらえない。曖昧なコードをアウトプットすると必ずバグが生まれるので、見聞きしたことを正確にアウトプットし直せるように、正確なノートを残せる力が必要になる。頭に定着させる力というよりは、頭に残すのはインデックス (索引) だけで、正確な情報はノートに記録しておくのだ。
- フレームワークやライブラリを使う時は、その「思想」を受け入れること。
- フレームワークは「枠組み」なのだから、思想が縛られていて当たり前 (むしろ勝手な思想を縛るためにある)。
- 自分の好き嫌いでモノを語るのは不要なこと。フレームワークのやり方に対して自分の思想をぶつけたくなるようであれば、距離を置くこと (そのフレームワークを使うのを止めるか、あなたがその仕事を辞めるか)。
- ツールで自動化できることは自動化する。自分の頭は自動化できないところに使う。
- JS の Lint、コード整形は自動化できる。レビューで「空行が」「インデントが」なんて指摘に時間を使わないようにする。自動化するためには初期投資として時間をかけるべき。
- HTML・CSS の論理的な構造だとか、ビジネスロジックの分割単位だとか、そういうことは自動化できない、「設計力」「論理的思考力」の問題。これは設計に関する原則やベストプラクティスを豊富に蓄えておき、それらを正確に組み合わせてアウトプットできるか、という能力なので、日本語 (母国語) ができない人には一生まともにできない。また、それらをチーム内で共有し強制させていくには、相手に理解して従ってもらうよう説明・説得しないといけないので、相手のレベルに合わせた客観的な視点を持てていない人間はこれができない。
いずれのポイントでも必要なのは、「概念を把握すること」「概念化して理解すること」という、概念化の力かなと思う。「要するにこういうこと」という要約による概念化、「別言語でいうとアレ」みたいな抽象的な結びつけが豊富であるほど、頭の中のインデックスが増えるので、「別のフレームワークにはこういう機能があったから、このフレームワークにもそういう概念は提供されているはずだよな」なんていう API の調べ方ができるようになったりする。応用が利くというのは、概念を理解しているかが直結してくるので、常に概念を理解することが大事。