tkiryu’s blog

本ブログの内容は個人の意見です。所属組織の公式見解ではありませんのであしからず。

ASP.NET Core を始める際に知っておきたい Web フロントエンドツールの種類と最新トレンド

npm webpack yarn Grunt Gulp Bower Browserify Visual Studio 2017 npm-scripts ASP.NET Core ES2015 ES6

– この記事は2017/02/15(Wed)現在の情報に基づいています –

Web フロントエンドツールの種類

Web フロントエンドは流行り廃りが速く、ライブラリはもちろんのこと、ビルドツールも様々なものが次々に生まれキャッチアップしきれない、とよく言われます。しかし実は、そのツールが何を解決するためのものなのかというポイントを押さえておけばそれほど焦る必要はないと思っています。なぜなら、実はそれらツールが解決したい課題自体にほとんど変化がないからです。

Web フロントエンドのツールが解決したい課題は主に３つ

  1. ライブラリの管理
  2. ファイルのコンパイルやサーバー起動などのタスクを実行
  3. JavaScriptモジュールの依存関係をまとめる

です。

1.ライブラリの管理　⇒　パッケージマネージャー

言わずと知れたパッケージマネージャーです。ライブラリの管理が役目ですが JavaScript のと言えばこの２つです。

  • npm
  • Bower
    (番外編)
    • JSPM
    • Yarn ※ 最近話題になっている npm と互換性のあるパッケージマネージャー

npm はもともと Node.js 上で動作するライブラリを管理するためのもの、Bower はブラウザ上で動作するライブラリを管理するためのものです。

少し前までブラウザのライブラリ管理には Bower が主な選択肢でしたが、モジュールバンドラー（後述します）の登場によって、Node.js スタイルのライブラリでもブラウザで実行可能な形式に変換して使用できるようになったため、npm さえあれば Bower が無くても困らない状況が生まれました。 他にも

  • ES2015(ES6) の import 構文による JavaScript のモジュール機構を使ったコーディングスタイルが主流となりつつあること。
  • Angular(旧称 Angular 2) などの最新フレームワークのパッケージが Bower ではホストされていないこと。
  • npm の登録パッケージ数が圧倒的。

などの要因もあり、現在では Bower よりも npm が好まれれる傾向があります。

ちなみに、npm と Bower のパッケージ数を比較したチャートを掲載しておきます。いかに npm が数で圧倒しているか分かります。おそらく npm にあって Bower にないパッケージはほとんどないと思います。

http://www.modulecounts.com/ f:id:tkiryu:20170214032633p:plain

2.タスクの実行　⇒　タスクランナー

Web フロントエンドで実施すべきタスクは多岐にわたります。JSファイルやCSSファイルの minify、 concat、画像の最適化、TypeScript や Babel のトランスパイル、開発用サーバーの起動、などです。これらのタスクを手動で実行するのはとても手間がかかります。そこで、タスクを自動実行してくれるツール、タスクランナーが必要となります。

  • Grunt
  • Gulp
  • npm-scripts (番外編)
    • Broccoli

昔は Grunt、その後は Gulp、そして現在は npm-scripts を使うのが主流となりつつあります。npm-scripts は npm 自身が持っている仕組みなので npm さえ入っていれば使えます。なぜ Grunt や Gulp が敬遠されるようになったのか、以下の記事が参考になります。

qiita.com

自分も以前はプロジェクトで Grunt や Gulp を使っていましたが、すこしアップデートしただけで突然動かなくなったということがよくありました。その経験から、今では極力 npm-scripts を使うようにしています。npm-scripts については以下の記事が非常に参考になります。

ics.media

3.JSモジュールの依存関係をまとめる　⇒　モジュールバンドラー

もともと JavaScript は言語仕様としてモジュールという仕組みは持っていませんでした。そのため、ロジックごとに別ファイルに切り出したり、モジュールパターンを使って名前空間を工夫したりして、頑張ってモジュール化を行っていました。

その後登場した Node.js には独自のモジュール機構があり（もともとは CommonJS 仕様に沿った実装だったけど独自に進化） require 構文を使って別モジュールをインポートすることができるようになりました。しかし require 構文はブラウザでは使えません。

さらにその後 ES2015(ES6) で import/export 構文が策定され、正式に言語レベルでモジュール機構がサポートされることになりました。しかし、仕様として決まっただけで、現在のブラウザの実装ではまだ import 構文を使用することができません。

そこで登場したのがモジュールバンドラーです。モジュールバンドラーは、require 構文および import 構文でインポートされたモジュール間の依存関係をまとめあげ、ブラウザ上で実行可能な１つのJSファイルに出力する機能を持っています。このおかげでもともと Node.js 用に書かれたライブラリでもブラウザ上で使うことができるようになったのです。

  • Browserify
  • webpack

Browserify が先に登場し、webpack が後発です。Browserify はエントリーポイントとなるJSファイルを１つしか作れないのに対して、webpack は複数のエントリーポイントに応じたJSファイルを出しわけることができます。

例えば画面A、B、Cがあったとして、Browserify の場合は、画面A、B、Cに対して１つのJSファイルしか出力できません。厳密には、Gulp などを併用することによって、それぞれ異なるファイルを出力するようにすることもできなくはありませんが、そのための環境を構築するのが複雑になります。対して webpack は、それ自身の仕組みで、各画面に応じたスクリプトファイルを簡単に出力することができます。そのため現在では webpack を使うのが好まれています。

以下のグラフは npm trends にて両者の比較を行った結果です。1年前は Browserify の方が優勢でしたが、ここ最近では webpack がダウンロード数で圧倒しており、Browserify の倍近くに迫る勢いです。webpack がいかに人気があるか分かると思います。

http://www.npmtrends.com/ f:id:tkiryu:20170207032537p:plain

そして今、どのツールを使うか？

  • パッケージマネージャー：npm ※あるいは Yarn
  • タスクランナー：npm-scripts
  • モジュールバンドラー：webpack

が現時点において最もメジャーな Web フロントエンドツールスタックだと思います。

それじゃ ASP.NET Core 始めよう・・・

と思いきや、Visual Studio 2017 の ASP.NET Core のプロジェクトテンプレートを見てみると、

  • パッケージマネージャー：Bower(デフォルト)、npm を選択可能
  • タスクランナー：なし(デフォルト) 、Grunt/Gulp を選択可能
  • モジュールバンドラー：なし

という現状で、現在のトレンドに合っていません。

次回

ということで、次回は ASP.NET Core プロジェクトで、npm, npm-scripts webpack を使用した最新のフロントエンドビルド環境を作るところから始めてみたいと思います。それでは。