キャッチアップJavaScript ビルド

ビルドから見る JS の今 /2016 春

Hitoshi Kondokhit@jp.ibm.com

2

JavaScript/HTML 活躍の場が広がっています。

　　 Web アプリ

　　　　　モバイルアプリ（ハイブリッド）

　　　　　　　デスクトップアプリ (Electron, Windows アプリ )

　　サーバーサイド (Node)

　　　　　　 IoT(JSBoard, AWS Lambda, Cold Functions)

　　　　　　　　　　　 Json でストア (NoSQL)

3

JavaScript 史のポイント

サーバーサイド利用含む拡張仕様

統一仕様

ECMAScript

一部実装

進化

V4 で ES2015 対応

初期乱世

DHTMLActionScript

XHR&Ajax で再興

モバイル、 LL の台頭Cordova

大規模開発やデスクトップ向けもMV*

altJS

jQuery

JQM

Prototype

1995

JavaScript

2005

2010

2015

ブラウザ界

Node 界Isomorphic (i8c) な世界へ？

フロントとバックでコード ( 環境 ) 共通化

4

知っていますか？

　本来 JavaScript にコンパイルなどのビルドは必須ではありませんが…

　いまどきの JavaScript アプリではビルドが重要です。

5

なぜなら

Automation– 繰り返し作業はしたくない– 手作業ミスをへらす– ドキュメントとか楽したい 品質をあげて生産性をあげる

– よりきっちりした文法で品質をあげる– より洗練した新仕様で読みやすく– コードミスのチェックで文法ミスに気づく– テスト実行でロジックミスに気づく– デザイナー (CSS) も楽したい

パフォーマンスはどこでも重要– 圧縮– 統合

6

まとめると

　開発 / 運用者が楽をするためにつくる仕組みが発展しています

CONTINUOUS INTEGRATION

7

代謝の激しいフロントエンドを反映し、 JS ビルドの世界も盛り上がっています

このチャートはビルドの現状を追うことで JS の現状をとらえることが目的です– 各ツールの詳細な使い方は Web 上に良いリソースがたくさんあります（一部紹介してます）

このチャートの目的

8

JavaScript ビルド

CSS プリプロセッサー

UT/ 操作テスト 構文チェック

テンプレート処理

altJS コンパイル

ES2015 コンパイル

圧縮 / 難読化

JavaScript ビルドではこんなことをします。

モジュール管理 ( 依存性解決 )

9

ここ数年 JS/HTML/CSS などのフロントエンドリソース向けのビルドツールが盛り上がる

– 2015 あたりから主流は Grunt から Gulp に

JS の進化に伴いビルドに必要なタスクも変わる– プラグイン・エコシステムで最先端のビルド処理に対応– 楽するためにはエコシステムを十分に活用できる活発さが重要

ビルドツール ( タスクランナー )

20132015

10

ビルドツール ( タスクランナー )- Grunt

Node 実装フロントエンド向けタスクランナーのさきがけ– JSON でビルド定義– プラグイン・エコシステムで様々なビルド処理に対応

11

ビルドツール ( タスクランナー )- Gulp

スピードや定義の書きやすさで主流に– ビルド定義も JavaScript ロジックでかける– プラグイン・エコシステムで様々なビルド処理に対応– 処理間の受け渡しを Stream にすることでビルドスピード強化– gulp-babel で ES2015 に対応したビルドコード対応

12

ビルドツール ( タスクランナー )- Fly

Node 提供の ES2015 で記述できるビルドツール– JavaScript ロジックでビルド定義

– ES2015のGeneratorを採用– 関数名 = タスク名になったり、 require いらなくなったり、よりシンプルに

– プラグイン・エコシステムで様々なビルド処理に対応– 新参のためまだ少ないが主要プラグインはかなりカバーされてきている…

13

ここからはビルドツールで実行する代表的なタスクをみていきます

14

圧縮 / 難読化

かつての JavaScript ビルドの代名詞といえば…

Google Closure Compiler による圧縮 / 難読化

– 空白改行・コメント行除去や関数変数名などのサイズ圧縮によるパフォーマンス向上– あとは一応、アンチデバッグ、アンチウイルス、パターンマッチング回避

?

15

圧縮 / 難読化 – UglifyJS2 など

Node で実装された高速圧縮 / 難読化ツール– Java 実装の Closure Compiler に比較し高速な圧縮 / 難読化

– 難読化：関数や変数名などを短縮化– Angular の DI機能など弊害発生ケースも

– ソースマップ対応 – デバッグツールで圧縮コードに対しブレークポイント設定できる

– CSS に対応した UglifyCSS もあり– HTML もあり html-minifier

16

圧縮 / 難読化 - ネタですが

Sushify– JavaScript のコードを寿司のネタに握り直します。

– 鯖、鮭などお寿司屋さんの湯飲み風に難読化– 日本人にしか読みづらい ?

– 他にも Kaomojify(顔文字 )， emojify(絵文字 ) 、 jojofy( ジョジョ化 ) とか

17

モジュール化

JavaScript(ES5) ではモジュールの概念がないのでコード量が増えると大変

– CommonJS や requireJS など補完する動きが活発に

– Angular など、フレームワーク自体がモジュール化 & インポートの仕組みを提供するケースも

– ES2015 ではこれらの仕様が正式提供される

18

モジュール化に関わるライブラリの関係

JavaScriptサーバーサイド利用含む拡張仕様

統一仕様

ECMAScript

Node 実装をブラウザでも使えるように

非同期モジュールロード仕様

ブラウザ上 JS のパッケージ管理

モジュール仕様あり

Node パッケージ管理

進化V4 で ES2015 対応

npm連携しパッケージング

モジュール仕様あり

ES6 的ビルド

※パッケージ≒モジュール

Node 界

19

パッケージ管理 - Bower

パッケージ管理ツール @ ブラウザ界– jQuery, Angular, React, UI ライブラリなどフロントエンドアプリの利用

パッケージ管理が主体– JS だけでなく、 html/css のライブラリも扱える– bower.json に依存するパッケージを記述– アプリは bower_components に展開されたパッケージをロードして使用

※パッケージ≒モジュール

20

パッケージ管理 - npm

パッケージ管理ツール @Node 界– タスクランナー (Grunt/gulp) ・モジュールシステム (browserify/

webpack) ・テストスイート (karma) などの開発環境系の管理が主体– package.json に依存するパッケージを記述– node_modules に取得パッケージが展開

– Node アプリは commonJS の require によりパッケージをロードできる

※パッケージ≒モジュール

21

モジュールビルド - browserify

Node 界の実装をブラウザ界でも使えるようにする魔法– Node アプリが別モジュールを require しているところを書き換え 1 ファイ

ルにマージ– デバッグ時は sourceMap をそのまま利用できる– 同一ライブラリなどが複数個所でマージされないように (browserify-shim)– npm パッケージが基本だが Bower のパッケージも利用できる (Debowerify)

22

モジュールロード - RequireJS

AMD(Async Module Definition) モジュールの非同期ロードの仕組み

– ビルドではなく、ライブラリが実行時に非同期ロードを実現– モジュールを実行する際、必要モジュールがまだロードされていない場合、非同期でロード

– ビルドしなくても実行・デバッグできる– Node 界の require(commonJS) とは記法も挙動も違います (非同期 )

23

モジュールビルドとロード - webpack

いいとこどりの後発ツール。 npm と連携し設定ファイルでビルド– webpack.config.js の設定に従って node の require 解決し、複数ファイルにマー

ジ– npm パッケージが基本だが Bower のパッケージも利用できる– requireJS 的非同期ロードにも対応– プラグイン (xxloader) により AltJS や CSS 、画像、 JSX なども対応できる

24

モジュールビルドとロード - jspm

パッケージ管理＋非同期ロード＋ ES2015 トランスパイラ– ユニバーサルなモジュールローダー SystemJS を利用

– ES2015 modules, 　 AMD, 　 CommonJS などに対応するローダー– ES2015 で書ける ( トランスパイル )– ES2015 のモジュール機構 (import/export) を使える– 開発中はビルドしない状態で実行・デバッグできる– パッケージ管理もできる

25

トランスパイル　 AltJS と ES2015

JavaScript をラップした言語で書いて JS に変換– LL 的すっきりしたコードに– 型チェックでバグ減らす

EcmaScript 2015 次期言語仕様– 未サポートブラウザでも動作するように現仕様 (ES5) に変換– より洗練された将来性のあるコードで開発できる

AltJS

ES2015(ES6)

JavaScript(ES5) コードは自由すぎる or 冗長すぎる

26

トランスパイル - AltJS

JS が Ruby,Python 的な簡潔なコードでかける– () とか {} とか ; とか省略してインデントで– クラスと継承– アロー式 etc..

27

トランスパイル - AltJS

JS が型付言語に– 型定義とインターフェース、コンパイル時の型チェック– クラス、継承、 import etc..– ES2015 仕様もサポート

28

トランスパイル - EcmaScript2015 (EcmaScript6)

JS が準拠する言語仕様– 次期標準として 2015/6 に公開– クラス、継承、 import 、 Promise 、アロー式 etc..– 各ブラウザは順次対応中

https://kangax.github.io/compat-table/es6/

ES2015 でコード開発して変換するためのトランスパイラ– バベルことでブラウザの対応状況を気にせず次期の洗練された API が使える– babelify で import/export->require->browserify で結合

29

各 AltJS と ES6 の関係

JavaScriptECMAScript5

トランスパイル トランスパイル

トランスパイルwith

Extend(互換 )

サポート

AltJS と ES6 、カバー範囲は被る– 特徴は異なる →　用途や採用予定ライブラリとの関係から選択

30

CSS プリプロセッサー

CSS はメンテナンスしにくい– Not DRY / ロジック組めない　→　無駄に大きくなるし、ミスしがち

ファイルは分割して @import できるけど…– パフォーマンス考えると JS と同じくビルドでマージしたい。

　　　　　　　　　 less, Sass, stylus

31

CSS プリプロセッサー : AltCSS

CSS をラップしてメンテナンスしやすく (AltCSS)– 80% は同等の機能を提供

– 変数、制御構文、式、関数でロジック組める – Mixin 、ネスト 、 import ファイルの連結、圧縮 – コンパイルして css を出力

– 多数の Editor 、 IDE がサポート – compass, Bourbon (Sass プラグイン ) 、　 nib (stylus エクステンション )

– ベンダープレフィックス、 Sprite 、 Grid etc..

32

CSS プリプロセッサー : PostCSS

次期 CSS 仕様の先取り +独自エコシステム– Babel 的に CSS4 を先行サポート (cssnext プラグインパック )– less, Sass, stylus 的 CSS 拡張 (PreCSS プラグインパック )– 独自のプラグインシステムによるエコシステム

– 後方互換 (Autoprefixer) 、ショートカットや、圧縮 (cssnano) 、 lint など

– コンパイル超速– less から Sass になった Bootstrap は次期 v5 で PostCSS移行かも

33

CSS プリプロセッサー : Autoprefixer

ベンダープレフィックス自動付与ツール– ブラウザの独自 / 先行拡張用のベンダープレフィックスを付与してくれる

– -webkit-linear-gradient/-moz-linear-gradient とか– CSS3導入期に各ブラウザごとに増殖– 時とともに必要なくなれば外すこと

– ここ一年開発停止中の compass に替わる…– Autoprefixer は Can I Use のデータベースから最新状況反映– PostCSS, node などいろんな実装で提供

34

Linter

JavaScript (HTML CSS) はコンパイルしなくてよい– コンパイルチェックを通らないので単純ミスが発生しやすい

コードをチェックすることで品質向上– 構文ミスチェック– プロジェクトのコード標準化– エディタ組み込みのケースも多し

35

Linter - JSHint / JSLint / JSCS

JavaScript コードチェックの元祖 (JSLint) と定番 (JSHint)– 必要十分で高速な静的チェック– JSHint/JSCS はチェック対象の設定可能– 様々なエディタにも組み込みあり

もちろん csslint や htmllint, jsonlint もある

36

Linter - ESLint

ES2015 対応のプラガブル Lint– ES2015 にも対応できる豊富なルール– プラグインによるルール・エコシステム搭載

– React JSX 記法– ES2016以降の構文チェックすらあり– カスタムルール

– エラー箇所が特定しやすい

– Shareable Config で設定を npm パッケージとして共有

37

MV* フレームワークとビルド

JavaScript アプリの複雑 / 大規模化

MV* 的な構造化によるメンテナンス性向上が求められる時代に

画面 (view) とデータをバインドするフレームワークが次から次に出ています– 構造化だけでなく幅広く機能提供し囲い込むのが流行り– テンプレート部分はビルドが必要なケースあり

38

MV* フレームワーク史のポイント

20102016

View-Model バインド

双方向バインド多機能提供UI エコシステム

ロールによる構造化 VirtualDOMパフォーマンス追求

集中と軽量化パフォーマンス追求

一方向データフローメンテナンス性追求

ES2015 対応

Isomorphicフロント / バックでのコード共通化

39

MV* フレームワークとビルド - Angular

構造化とデータバインドを中心に多用な機能提供– Model<->View の双方向でデータバインド

– dirty-checking バインドデータ量がパフォーマンスに直影響– DI によるモジュールの注入や Router による SPA遷移などいろいろ提供– ng- の UI モジュールがコミュニティで多数公開– テストフレームワークや開発ツールなどの提供

– 次期 2.0 では双方向バインドの廃止によるパフォーマンス改善など大転換– ng- などの独特の指定方法を排除し、コンポーネントとして汎用定義– AltJS 、特に TypeScript を推奨

– ビルド時にトランスパイル

40

MV* フレームワークとビルド - React

2015 大ヒットの View 主体のフレームワーク– VirtualDOM:DOM ツリーの差分更新でメンテナンス性とパフォーマンスを両立

– Flux: データの流れを一方向にして役割を明快にするアーキテクチャ– 実装は乱立しているが Redux が大ヒット中

– JSX:JS とテンプレートは無理して切り離さず JS モジュール内にカプセル化– コミュニティで React コンポーネントが多数公開

– JSX 記法で記述したテンプレートをプリコンパイル : Reactify

41

MV* フレームワークとビルド – Riot, Mithril, Aurelia

ここまでのフレームワークの弱点を克服する新世代– VirtualDOM など優れた仕組みは継承

– Mithril 　 : MV* のフルスタック FW– モデルの変更ではなく、イベント終了をトリガーにすることで描画高速化– JSX ライクな MSX で View をコンポーネント内にカプセル化 : Mithrilify

– Riot : React のように View に特化した軽量 FW– HTML のコードブロックに JS を埋め込む形でコンポーネント (.tag) 作成– .tag は riot.mount でロードするか、 Riotify などでトランスコンパイル

42

MV* フレームワークとビルド – Riot, Mithril, Aurelia

– Aurelia : CoC を基本思想とする Angular2.0 ライクなフルスタック FW– Angular2同様に一方向バインドがデフォルト– ES2015 サポート : Babel でのトランスパイル– 依存性解決は jspm を採用– UI エコシステム

43

参考：ライブラリ選定にあたって

選定のポイント : できる限りリアルタイムの情報を調査

– 将来性につながる情報のチェック– バージョンアップ状況や仕様サポート状況、ライバルとの関係など– 旧バージョン / 現バージョンの情報量、 google trends や更新頻度

– エコシステムが十分に活用できるか？ (情報量、プラグイン数、 Doc ）

– パフォーマンス重視？開発規模により開発生産性重視？実績重視？– アプリの特徴を前提に自前検証が一番かもしれませんが…

– 定番 TODO アプリでのベンチマーク http://matt-esch.github.io/mercury-perf/

44

UT/ テスト

ビルド前にテストを流し問題のないことを確認する– ユニットテスト：コードレベルでのテスト– 画面操作テスト： End2End 環境でのユーザー操作のテスト– カバレッジ取得 ：メソッドや分岐などの視点でテストでのカバー率をチェック

動作仕様としてテストコードから作成する： TDD

45

UT – Jasmine他

＊ Unit以後の主流 JS テスト FW– アサートモジュールやテストダブルを含むオールインワン・テスト FW– テストダブル： Spy でモック作成や関数の実行チェック

– angular-mock など MV*FW側で mock が提供される場合も– Jasmine-node で Node でもテストコード実行できる

– 他に Mocha系 (sinon, power-assert) も人気

46

テストランナー - Karma

テスト FW やブラウザを指定し実行するテストランナー– ES2015 にも対応できる豊富なルール

– Jasmine のテストコードを ES2015 で書いて、トランスパイルして…– プラグインによるエコシステム搭載

– レポート、 browserify などの事前処理– カバレッジ取得 (karma-coverage)– 様々なブラウザランチャー– 様々なテスト FW プラグイン

– Angular と特に相性良し

47

操作テスト – Selenium

業界標準の画面操作テストツール Selenium と仲間たち– マルチブラウザ、マルチ言語、 10 年超実績の定番– JSON Wire Protocol でブラウザを操作– クライアント API 実装が多数存在 ( レコードツールもあり）

– WebdriverJS ： W3C標準 Web Driver 仕様の実装– WebdriverIO : ES2015 対応 Generator でテストが書ける– Appium : Android, iOS 向けドライバー

– Protractor– WebdriverJSベース。 Angular 向けの拡張機能+α を提供

48

他にもいろいろ

実行トリガー– Wath

JSDoc– jsdoc (gulp-jsdoc)

画像最適化– imagemin, spritesmith

キャッシュ対策– rev-replace

49

参考資料

各公式サイトは特に記載してません。

フロントエンド ビルドツール比較http://b.hatena.ne.jp/entry/s/speakerdeck.com/bevacqua/front-end-ops-tooling

Gulphttps://speakerdeck.com/axross/gulpwoshi-utobi-nu-gadekiruyo-kantannashao-jie-tohanzuonhttps://speakerdeck.com/cognitom/gulp-dot-js-cheatsheet

Flyhttp://www.slideshare.net/deepblue_will/new-generation-build-system-fly

50

参考資料

各公式サイトは特に記載してません。

Autoprefixerhttp://kojika17.com/2014/01/autoprefixer.html

PostCSShttps://speakerdeck.com/jmblog/postcss-tohahe-ka

Uglifyhttp://www.peterbe.com/plog/advanced-closure-compiler-vs-uglifyjs2http://www.slideshare.net/hasegawayosuke/javascript-51570525

Webpackhttp://liginc.co.jp/web/js/149577

Browserify などhttp://tsuchikazu.net/javascript-module/

51

参考資料

各公式サイトは特に記載してません。

jspmhttps://speakerdeck.com/guybedford/package-management-for-es6-modules

altJShttp://www.slideshare.net/NeilGreen1/type-script-vs-coffeescript-vs-es6

Darthttps://docs.google.com/presentation/d/1cETXGhfPb6M2ugRjciWLBL4HjOLcXPu2e3RHkHDRoEI/edit

less, sass, stylushttp://www.slideshare.net/verekia/deep-dive-into-css-preprocessors

52

参考資料

各公式サイトは特に記載してません。

Lint系http://www.sitepoint.com/comparison-javascript-linting-tools/http://qiita.com/mysticatea/items/f523dab04a25f617c87d

Jasminehttp://www.slideshare.net/itokami1123/javascript-jasmine

Jasmine と Mochahttps://gist.github.com/taichi/4482819

Karmahttps://speakerdeck.com/sebarmeli/karma-js-test-runner

Seleniumhttp://www.slideshare.net/NozomiIto/osssselenium

53

Thanks