2016年に使った&来年使いそうな JavaScript 関連のものと所感
2016年に使った&来年使いそうな JavaScript 関連のもの
以下のカテゴリでなんとなく書いてみます。去年と比べて大きく変わらないかんじです。動きの早かった 2, 3年前から、年々、動きはゆっくりになってきているというのが個人的な印象。
トランスパイラ
2016年に使った:
Babel。各ブラウザの JavaScript エンジンで ES2015~ES2017 の実装が進んでいるので、関わっている案件のブラウザのシェア次第なところもありますが、ES2015~ES2017 の仕様だけトランスパイルしたいのであれば、再来年あたりから要らなくなるんじゃないかな、という気持ち。
来年使いそう:
静的型付けがメインで、ES20XX から ES5 へのトランパイルは副次的ですが、TypeScript。先日、久しぶりに触ったら( v2.1 )、v1.6 か v1.8 の頃に触って微妙だな、と思った諸々が改善されていました。
- サードパーティの型定義ファイルの取得がそれ用のツールではなく npm でできるようになった
- 別ファイルに定義された型情報を参照するために reference タグを書く必要がなくなった
- async/await を es5 target でダウンパイルできるようになった ( 以前は、いったん es2015 に変換した後に babel でさらにトランスパイルをしないとダメで、ビルドチェーンが複雑になるからスルーしていた )
- targetに esnext, es2015, es2017 が指定できるので、型宣言だけ抜いた JavaScript ファイルが生成できる。やめたくなったらすぐにやめれる
- Visual Studio Codeとの連携が良くできている ( 最近 Visual Studio Code 使っているので )
ビューライブラリ/フレームワーク
2016年に使った:
Vue。既存のサービスでのちょっとした UI の実装から、SPA のフルスクラッチの実装まで幅広く使いました。良さは色々あるんですが、以下の3点が大きいです。
周囲だと React , Redux を使っている人もちらほら。React、良いと思うんですが、今の会社のワークフローだと HTML を JSX に手で書き換える作業が発生するので、個人的にそれがつらいので選択していません。( React に限らず、Vue も含めたコンポーネント指向のライブラリを使うとどうしても二度手間感が否めないワークフローなので、来年はそこを改善したい、と思っていたり )
今年の9月末にリリースされた Vue v2.0 で パフォーマンス改善 & Server Side Rendering もできるようになったので、特別 React を選ぶ理由がなくなったというのもあります。
来年使いそう:
今年と同じ感じ。新しいライブラリを実戦で使うことは今のところなさそうですが、Shadow DOM v1 や Custom Element v1 の実装が Chrome や Safari で進んでいる背景も踏まえつつ、https://github.com/skatejs/skatejs のような WebComponent のAPIを薄くラップしたライブラリはウォッチしておこうと思っています。
モジュールバンドラ
2016年に使った:
Browserify。それなりの規模のプロジェクトだと生成されるファイルサイズが大きくなる以外は不満はなく。ビルドにかかる時間も watchify を使えばだいぶ短くできます。ただ、開発が活発ではなくなっているのと、モジュールバンドラとしては Webpack を使う人が増えて、Browserify を使う人が減ってきているような気がするのが気がかり( ソース: The State of Front-End Tooling 2016 - Results - AshleyNolan.co.uk - Blog and Portfolio for Ashley Nolan )。
来年使いそう:
Browserify でもまだ困らないとは思うんですが、Webpack2 を検討しています。理由はビルドにかかる時間が短い、コード分割(と動的ローディング)、Tree Shaking で生成されるファイルのサイズを減らせるというあたりです。ただ、先日のブログ( JavaScript のサイズを減らすことと効率良くキャッシュさせるためのメモ - kitak.blog )の最後に書いたようにツールの自由度が高く plugin と loader の使い過ぎが後々の負債に繋がりそうな予感がするので、いったんは JavaScript のモジュールバンドラとして使い、stylesheet や画像は扱わないつもりです。
タスクランナー
2016年に使った:
npm-scripts(yarn run も含む)。npm run ほにゃらら で browserify のコマンドを実行したり、コマンドをパイプで繋いだり、複雑になってきたら JavaScript で書いたスクリプトを node で実行したり、シェルスクリプトを実行しています。
数年前からあるプロジェクトや一部のタスクは Grunt を使ってます。Grunt、今でもメンテはされているので、使っている Grunt プラグインが全くメンテされなくて業務に支障が出るとかがないのであれば、既存のプロジェクトで急いで違うツールに乗り換える必要はなさそうです( 時間があれば乗り換えてもよさそうですが )。
来年使いそう:
多分、これまでと変わらず。
パッケージマネージャ
2016年に使った:
Yarn。リリース日に触ったらパッケージを git リポジトリの url で指定すると動かなくて、しばらく様子見していたんですが、一ヶ月ぐらい前に触ったら修正されていて、それ以来使っています。体感ですが、パッケージのインストールが非常に速い。その他、npm の生成する package.json と互換性があったり、バージョン固定の仕組み( npm shrinkwrap はバグやハマりどころが多かった )など、諸々鑑みて、使わない理由がない。
来年使いそう:
多分、今年と変わらず。
テスティング
2016年に使った:
あんまりこだわりがないので昔から使っている Karma(テストランナー) + Jasmine(テスティングフレームワーク) + PhantomJS。
来年使いそう:
来年使うものというより、よっぽど強い理由がないのであれば、使っているビューライブラリやフレームワークが、自身のテストに使っていたり、ドキュメントで推奨しているものを使うのが無難だと考えています。
所感
最近、心の中でふつふつと思っていたことです。
動き早い？
冒頭にも書きましたが、年々、落ち着いてきているような気がします。今年に関して言うと、去年から耳にしていた・ある程度使われていたものが今年になって、改善・改良されて、さらに使われるようになったというところではないでしょうか。それは、The State of Front-End Tooling 2016 - Results - AshleyNolan.co.uk - Blog and Portfolio for Ashley Nolan の結果にも現れています。
とはいえ、上で書いたカテゴリだけでも 6つあって(他にも色々 Lint とかあるんですが ESLint が当たり前になっているので省きました)、JavaScript を普段書かない人からすると、学ぶべきことがたくさんあるように感じる、適当にググったら、過去に広く使われていたものや「それぞれのツールを組み合わせてみた」みたいな記事が大量に出てきて、あたかも動きが早いように感じるのではないでしょうか。
実際のところ、全ての案件で上のカテゴリのツールやライブラリ全てが必要なわけではありません。極端な例をあげれば、公開期間が数週間のキャンペーンページだと、(マサカリ飛んできそうですが) jQuery 互換のライブラリを npm で入れて、ES5の仕様でシュッとコード書いて、ファイルを concat (これもいらなくなりつつある), uglify しておしまいということもあります。自分が必要なものを理解して、選んで使えばいいだけです。なので、コンテキストをすっ飛ばして「React, Redux, Webpack, ... このスタックでやっとけば間違いない！」 みたいな記事を見ると、眉をひそめたくなります。
個人的に、JavaScript やその周辺のことを学び始めた人が自分の作っているものや関わっている案件に対して、必要なものを適切に選ぶことができるガイドやYes/Noチャートのようなものが世の中に足りないんじゃないかな、と感じています。
あとは、2016年にJavaScriptを学ぶとこんな感じ – Medium Japan – Medium に書かれているような普段 JavaScript を書いている人がそうじゃない人に「イマドキはこれだから！」とその人がやりたいことに対して過剰なものを押し付けたり、不安を掻き立てるようなことをしないということですね...(自戒もこめて)
新しいライブラリ・ツールとの向き合い方
落ち着いてきているように感じるとはいえ、新しいライブラリやツールは次々と出てきます。そういったライブラリやツールとはどう向き合えばいいのか。個人的には次のような感じでやっています。
- README を読んで、それが何を解決するかやどのカテゴリに属するかを考える
- 良さそうであれば sandbox プロジェクトで試す
- そのプロジェクトが作られて2, 3年未満の場合は2, 3年経つまで放置
- 2, 3年経っていたら、それを使うことで生産性が数倍向上しそうか(ちょっと向上するぐらいだったらやめる)、その間にあったリリース内容やコミュニティの発展、直近のWeb標準やプロコトルの進化や発展で不要にならないか等を鑑みて実戦に投入するか判断
2, 3年というのは、けっこう適当なんですが、新しく出てくるツールは大抵 2, 3 年の内に消えているように思うので、2, 3 年生き延びたのであれば、今後も存続し、実戦で使うに耐えうるクオリティになっているだろうという考えです（yarn, 今年出てきたやつやんとツッコミ受けそうなんですが、package.json そのままで npm を置き換えればいいだけなので例外）。一時期、新しいものを使うのが正しいと思っていた時期もあったんですが、kintoneフロントエンド開発 モダン化への道 のスライドやロードマップ指向とエコシステム指向 - アンカテ を読んで、いわゆる中心部のレッドオーシャンを避けるようになりました。白洲次郎が、ツイードは2, 3年雨ざらしにして着ろと言っているように、JavaScript 関連のツール・ライブラリも2, 3年様子見するぐらいがちょうどいいんじゃないでしょうか（ツイード着たことないですが…）。
おしまい。
