Más contenido relacionado
La actualidad más candente (20)
Similar a キャッチアップJavaScriptビルド - ビルドから見るJSの今/2016春 (20)
キャッチアップJavaScriptビルド - ビルドから見るJSの今/2016春
- 5. 5
なぜなら
Automation
– 繰り返し作業はしたくない
– 手作業ミスをへらす
– ドキュメントとか楽したい
品質をあげて生産性をあげる
– よりきっちりした文法で品質をあげる
– より洗練した新仕様で読みやすく
– コードミスのチェックで文法ミスに気づく
– テスト実行でロジックミスに気づく
– デザイナー(CSS)も楽したい
パフォーマンスはどこでも重要
– 圧縮
– 統合
- 15. 15
圧縮/難読化 – UglifyJS2など
Nodeで実装された高速圧縮/難読化ツール
– Java実装のClosure Compilerに比較し高速な圧縮/難読化
– 難読化：関数や変数名などを短縮化
– AngularのDI機能など弊害発生ケースも
– ソースマップ対応
– デバッグツールで圧縮コードに対しブレークポイント設定できる
– CSSに対応したUglifyCSSもあり
– HTMLもあり html-minifier
- 16. 16
圧縮/難読化 - ネタですが
Sushify
– JavaScriptのコードを寿司のネタに握り直します。
– 鯖、鮭などお寿司屋さんの湯飲み風に難読化
– 日本人にしか読みづらい?
– 他にもKaomojify(顔文字)， emojify(絵文字)、jojofy(ジョジョ化)とか
- 19. 19
パッケージ管理 - Bower
パッケージ管理ツール@ブラウザ界
– jQuery, Angular, React, UIライブラリなどフロントエンドアプリの利用パッ
ケージ管理が主体
– JSだけでなく、html/cssのライブラリも扱える
– bower.jsonに依存するパッケージを記述
– アプリはbower_componentsに展開されたパッケージをロードして使用
※パッケージ≒モジュール
- 20. 20
パッケージ管理 - npm
パッケージ管理ツール@Node界
– タスクランナー(Grunt/gulp)・モジュールシステム(browserify/webpack)・
テストスイート(karma)などの開発環境系の管理が主体
– package.jsonに依存するパッケージを記述
– node_modulesに取得パッケージが展開
– NodeアプリはcommonJSのrequireによりパッケージをロードできる
※パッケージ≒モジュール
- 21. 21
モジュールビルド - browserify
Node界の実装をブラウザ界でも使えるようにする魔法
– Nodeアプリが別モジュールをrequireしているところを書き換え1ファイルに
マージ
– デバッグ時はsourceMapをそのまま利用できる
– 同一ライブラリなどが複数個所でマージされないように(browserify-shim)
– npmパッケージが基本だがBowerのパッケージも利用できる(Debowerify)
- 22. 22
モジュールロード - RequireJS
AMD(Async Module Definition)モジュールの非同期ロードの仕組み
– ビルドではなく、ライブラリが実行時に非同期ロードを実現
– モジュールを実行する際、必要モジュールがまだロードされていない場合、非同
期でロード
– ビルドしなくても実行・デバッグできる
– Node界のrequire(commonJS)とは記法も挙動も違います(非同期)
- 23. 23
モジュールビルドとロード - webpack
いいとこどりの後発ツール。npmと連携し設定ファイルでビルド
– webpack.config.jsの設定に従ってnodeのrequire解決し、複数ファイルにマージ
– npmパッケージが基本だがBowerのパッケージも利用できる
– requireJS的非同期ロードにも対応
– プラグイン(xxloader)によりAltJSやCSS、画像、JSXなども対応できる
- 24. 24
モジュールビルドとロード - jspm
パッケージ管理＋非同期ロード＋ES2015トランスパイラ
– ユニバーサルなモジュールローダーSystemJSを利用
– ES2015 modules, AMD, CommonJSなどに対応するローダー
– ES2015で書ける(トランスパイル)
– ES2015のモジュール機構(import/export)を使える
– 開発中はビルドしない状態で実行・デバッグできる
– パッケージ管理もできる
- 28. 28
トランスパイル - EcmaScript2015 (EcmaScript6)
JSが準拠する言語仕様
– 次期標準として2015/6に公開
– クラス、継承、import、Promise、アロー式 etc..
– 各ブラウザは順次対応中
https://kangax.github.io/compat-table/es6/
ES2015でコード開発して変換するためのトランスパイラ
– バベルことでブラウザの対応状況を気にせず次期の洗練されたAPIが使える
– babelifyでimport/export->require->browserifyで結合
- 31. 31
CSSプリプロセッサー : AltCSS
CSSをラップしてメンテナンスしやすく (AltCSS)
– 80%は同等の機能を提供
– 変数、制御構文、式、関数でロジック組める
– Mixin、ネスト、importファイルの連結、圧縮
– コンパイルしてcssを出力
– 多数のEditor、IDEがサポート
– compass, Bourbon (Sassプラグイン)、 nib (stylusエクステンション)
– ベンダープレフィックス、Sprite、Grid etc..
- 32. 32
CSSプリプロセッサー : PostCSS
次期CSS仕様の先取り+独自エコシステム
– Babel的にCSS4を先行サポート (cssnext プラグインパック)
– less, Sass, stylus的CSS拡張 (PreCSS プラグインパック)
– 独自のプラグインシステムによるエコシステム
– 後方互換(Autoprefixer)、ショートカットや、圧縮(cssnano)、lintなど
– コンパイル超速
– lessからSassになったBootstrapは次期v5でPostCSS移行かも
- 33. 33
CSSプリプロセッサー : Autoprefixer
ベンダープレフィックス自動付与ツール
– ブラウザの独自/先行拡張用のベンダープレフィックスを付与してくれる
– -webkit-linear-gradient/-moz-linear-gradientとか
– CSS3導入期に各ブラウザごとに増殖
– 時とともに必要なくなれば外すこと
– ここ一年開発停止中のcompassに替わる…
– AutoprefixerはCan I Useのデータベースから最新状況反映
– PostCSS, nodeなどいろんな実装で提供
- 34. 34
Linter
JavaScript (HTML CSS)はコンパイルしなくてよい
– コンパイルチェックを通らないので単純ミスが発生しやすい
コードをチェックすることで品質向上
– 構文ミスチェック
– プロジェクトのコード標準化
– エディタ組み込みのケースも多し
- 35. 35
Linter - JSHint / JSLint / JSCS
JavaScriptコードチェックの元祖(JSLint)と定番(JSHint)
– 必要十分で高速な静的チェック
– JSHint/JSCSはチェック対象の設定可能
– 様々なエディタにも組み込みあり
もちろんcsslintやhtmllint, jsonlintもある
- 36. 36
Linter - ESLint
ES2015対応のプラガブルLint
– ES2015にも対応できる豊富なルール
– プラグインによるルール・エコシステム搭載
– React JSX記法
– ES2016以降の構文チェックすらあり
– カスタムルール
– エラー箇所が特定しやすい
– Shareable Configで設定をnpmパッケージとして共有
- 39. 39
MV*フレームワークとビルド - Angular
構造化とデータバインドを中心に多用な機能提供
– Model<->Viewの双方向でデータバインド
– dirty-checking バインドデータ量がパフォーマンスに直影響
– DIによるモジュールの注入やRouterによるSPA遷移などいろいろ提供
– ng-のUIモジュールがコミュニティで多数公開
– テストフレームワークや開発ツールなどの提供
– 次期2.0では双方向バインドの廃止によるパフォーマンス改善など大転換
– ng-などの独特の指定方法を排除し、コンポーネントとして汎用定義
– AltJS、特にTypeScriptを推奨
– ビルド時にトランスパイル
- 40. 40
MV*フレームワークとビルド - React
2015大ヒットのView主体のフレームワーク
– VirtualDOM:DOMツリーの差分更新でメンテナンス性とパフォーマンスを両立
– Flux:データの流れを一方向にして役割を明快にするアーキテクチャ
– 実装は乱立しているがReduxが大ヒット中
– JSX:JSとテンプレートは無理して切り離さずJSモジュール内にカプセル化
– コミュニティでReactコンポーネントが多数公開
– JSX記法で記述したテンプレートをプリコンパイル : Reactify
- 41. 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. 42
MV*フレームワークとビルド – Riot, Mithril, Aurelia
– Aurelia : CoCを基本思想とするAngular2.0ライクなフルスタックFW
– Angular2同様に一方向バインドがデフォルト
– ES2015サポート : Babelでのトランスパイル
– 依存性解決はjspmを採用
– UIエコシステム
- 43. 43
参考：ライブラリ選定にあたって
選定のポイント : できる限りリアルタイムの情報を調査
– 将来性につながる情報のチェック
– バージョンアップ状況や仕様サポート状況、ライバルとの関係など
– 旧バージョン/現バージョンの情報量、google trendsや更新頻度
– エコシステムが十分に活用できるか？(情報量、プラグイン数、Doc）
– パフォーマンス重視？開発規模により開発生産性重視？実績重視？
– アプリの特徴を前提に自前検証が一番かもしれませんが…
– 定番TODOアプリでのベンチマーク http://matt-esch.github.io/mercury-perf/
- 45. 45
UT – Jasmine他
＊Unit以後の主流JS テストFW
– アサートモジュールやテストダブルを含むオールインワン・テストFW
– テストダブル：Spyでモック作成や関数の実行チェック
– angular-mockなどMV*FW側でmockが提供される場合も
– Jasmine-nodeでNodeでもテストコード実行できる
– 他にMocha系(sinon, power-assert)も人気
- 46. 46
テストランナー - Karma
テストFWやブラウザを指定し実行するテストランナー
– ES2015にも対応できる豊富なルール
– JasmineのテストコードをES2015で書いて、トランスパイルして…
– プラグインによるエコシステム搭載
– レポート、browserifyなどの事前処理
– カバレッジ取得(karma-coverage)
– 様々なブラウザランチャー
– 様々なテストFWプラグイン
– Angularと特に相性良し
- 47. 47
操作テスト – Selenium
業界標準の画面操作テストツールSeleniumと仲間たち
– マルチブラウザ、マルチ言語、 10年超実績の定番
– JSON Wire Protocolでブラウザを操作
– クライアントAPI実装が多数存在(レコードツールもあり）
– WebdriverJS：W3C標準 Web Driver仕様の実装
– WebdriverIO : ES2015対応 Generatorでテストが書ける
– Appium : Android, iOS向けドライバー
– Protractor
– WebdriverJSベース。Angular向けの拡張機能+αを提供
