Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (13)
Similaire à JavaScriptトレンド総括（2014）
Similaire à JavaScriptトレンド総括（2014） (20)
Plus de VOYAGE GROUP
Plus de VOYAGE GROUP (20)
JavaScriptトレンド総括（2014）
- 2. 今回のスコープ • 最先端ではない • 「トレンドの少し後ろ」が目標 • エンジニア向き（「JSに触ったことがある」前提） • キーワードと経緯を拾う • 基本はクライアント側の話 • ブラウザ互換性の話はしません
- 3. 始めに（前提）
- 5. なぜビルドするのか • ファイルを連結したい • CoffeeScriptをJSに変換したい • デプロイ環境に配置したい
- 6. ビルドするには • Grunt, gulpといったタスクランナーを使う • Makeで頑張る人もいる • Rakeで(ry
- 7. ビルドすることで • コード解析ができる • 依存解決ができる • コード改変ができる
- 8. 言語そのもの
- 9. ~2013 • CoffeeScript、TypeScriptなど、 プリプロセスしてJSを生成し実行するAltJSの 登場 • AltJSデバッグ用途でsource mapの誕生 • 構文・機能として有用なものを ECMAScript言語仕様にフィードバックする流れ
- 11. 次世代言語仕様: ES6 • 現在標準化作業中（2015年夏?まで） • Promiseなどは既に普及開始 • プロダクション投入は時期尚早 • AltJS式の変換ツールはあるが…… • https://6to5.org/ • ビルドスクリプト程度ならば導入可能？
- 12. AltJS • 現実に使える物は2~3種類 • 付加価値とは何か？ • 静的チェック（TypeScript） • ES6でも良いケースもあるよね？ • CoffeeScriptの糖衣構文はES6に類似のものが多い • AltJSとしてのES6
- 13. 個人的なAltJSを使うケース • それなりの規模のプロダクト: TypeScript, 生JS • インターフェースが実装されているかを静的に検証したい • TypeScript以上のツールの出現を夢見て, 生JSで頑張る. またはClosure Compilerを使う. • 細かい規模ユーティリティ: 生JS • ビルドせず実行したいから生で書く • 書き捨て: CoffeeScript, ES6変換ツール • 書き捨てなので楽に書きたい・メンテナンスは考えない
- 14. プログラミングパラダイム
- 15. ~2013 • JavaScriptは非同期処理が多い • イベント駆動が多い • コールバックのネストは地獄になる
- 17. 非同期処理は大別して二つ • 「値がどこかで決まる」 • 例: 外部のJSONを取得する • 「連続的な値を取り扱う」 • ストリーミング, WebSocketなど
- 18. Promiseで決着 • 「値がどこかで一意に決まるもの」を表すMaybe, Future型 • jQuery.DeferredもPromise一派のひとつ • ES6入りにより、APIが大統一化された • ライブラリを導入し、今すぐ使える • https://github.com/jakearchibald/es6-promise
- 19. 2015年の非同期処理 • 「値が一つに決まるもの」はPromiseで決着 • 連続的な値を取り扱うものは未決着 • 古典的なコールバック • 連続的な値を無限リストと看做す （例: Rx）
- 20. 関連資料 • JavaScript Promiseの本 • JavaScriptでPromiseを使う場合, 一度は読んでおきたい • github:jakearchibald/es6-promise • ES6 Promise準拠のpolyfillライブラリ
- 21. 関連資料 • WHATWG Stream Standard • WHATWGにて策定中のStream API仕様 （2015年1月時点で実装処理系無し） • 連続的な値の取り扱いは、将来はこれに大統一？ • RxJS • C#のReactive Extensions系統のAPIを持つライブラリ
- 22. モジュール・パッケージ管理
- 23. ~2013 • JavaScriptには名前空間・モジュール化の 仕組みが無い • 仕組みが無いので、ちょっとしたことで 破綻する • 一方、Node.jsはCommonJSスタイルの モジュールシステムを持っている
- 25. 従来のJSのモジュール依存管理 • クライアント • オレオレツール • ファイルを連結 • AltJSの助けを得る • AMD (RequireJS), Closure Tools • Node.js: CommonJSスタイル
- 26. browserifyの躍進 • 元々はNode.js向けコードをブラウザで動かす ためのツール • CommonJS形式のファイルを依存解決して 一つに結合したものを作る • これはブラウザ上の依存管理に使える！
- 27. npmエコシステム • Node.jsのモジュール配布・管理の生態系 • 正確にはパッケージ管理システム • 類友: Ruby gem, Python pip • browserifyのメインターゲット • クライアントJSの管理にもpackage.jsonを使う • bower.jsonが死んだ訳ではない（CSS用途などで生き残っている） • npm, bower以外は死んだかも
- 28. 2014年末日現在のモジュール依存管理 • CommonJS (browserify/webpack) • 古式ゆかしい依存順でconcat（AltJSと組み合わせて） • ES6 Module: 今は止めておけ • AMD（RequireJS）:往時に比べればマイナー化 • 非同期読み込みにwebpackなどの選択肢が出来たため • Closure Toolsなど独自生態系
- 29. テスト
- 30. ~2013 • JavaScriptもテストを書く必要がある • QUnit, Jasmine, mochaなど色々な テストフレームワークがあった • UIの自動テストにはSelenium ***を使う
- 31. 2014 • ユニットテスト: mocha+power-assert強い • テストランナー：好きなの使えよ • UI自動テスト: WebDriverありきで
- 32. ユニットテスト • 「mocha+何かしらのassert」が楽 • assert()さえ覚えればテストが書ける • power-assertは構文解析するのでAltJSとの組み合わせが 面倒なケースあり • Jasmine, QUnitも死んではいないが…… • Jasmineが↓のJestの基盤になるなど、裏方化・派生元としての利用が多い • 全部モック化するJestも出てきた
- 33. テストランナー • コマンド一発でテスト対象ブラウザを起動しテストを 流すツール • 好きなの使えよ • testem/karma以外に、まともに動くものが現実的に無いので二択 • testemもkarmaも、機能的差異は特にない • クライアントJSのユニットテストもNode.jsで 済ませる派閥もある
- 34. E2Eテスト（UIの自動テスト） • WebDriverが標準化されている（作業中） • Selenium WebDriverのアレです • WebDriverプロトコルに従ったものを 選ぶのが無難 • protractor, Selenium WebDriver, testium • WebDriverプロトコルのDriverさえあれば、どんなブラウザ（UA）でも 操作できる
- 35. PhantomJSはリスクでは仮説 • 根本的に人間のユーザーが存在する ブラウザではない • 実環境では無いので、テストツールとしての信頼性どうなの？ • WebDriver経由で操作するのがリスクヘッジ的に 良いのでは？ • ついでにWebKitベースではあるが古い • 少なくとも1.xは2013年半ばのブランチがベース • ついでにバグが多い
- 36. アプリケーションライブラリ
- 37. ~2013 • 栄華を極めたjQuery帝国 • JavaScriptと言えばjQuery • Angular.js, Backbone.jsなどの MVCフレームワークの流行
- 38. 2014 • 従来に比べてjQueryの存在価値の低下 • オールインワンなフレームワークの退潮 • 小規模ライブラリの組み合わせの前進 • browserifyの躍進が影響
- 39. jQuery帝国の衰退 • DOM互換ライブラリの必要性の低下 • IE8が落とせる今、互換層はそこまで必要ではない • jQuery.Animationさえあれば十分？ • 優れたDOM操作ライブラリの登場（React, Vue, Ractive) • 10年近い寿命に必然的に伴う、道具としての負債化 • 流行りすぎてしまったが故の玉石混淆 • “近年においてはjqueryプラグイン=低品質とほぼ同義である” という見方も
- 40. Angularどうなの • 楽に速く作る為のツールとしての評価が高い • 良くも悪くも「JS on Rails」 • 全部乗せ故に、コード資産含めたロックイン度が高い • 社内システムや管理画面に向いているので、 受託開発系では一定の人気を誇る • 2への移行が不安視？
- 41. React.js • ただのビュー（DOM操作）ライブラリ • 2015年1月現在、最優の一つではある • コンポーネント化が主眼 • アプリケーションをよりよく設計/管理するための道具 • ReactのVirtual DOMは裏方技術 • 本当に速度が欲しければ生DOMを書け
- 42. 総括 • 流行り廃りなので審美眼が大切 • jQueryは過去の負債遺産になりつつある • 単機能ライブラリが増え、組合わせが簡単に
- 43. アプリケーション設計
- 45. 「たかがJS」だが最低限の設計は当たり前 • Ajax黎明期のベタ書きコードに直面した俺達は • 保守性を考慮して設計するのは当然に • jQueryプラグインが嫌われる理由のひとつ • WebにおけるUIを実装する言語が他に無い現実と向き合う • ModelとViewを分けるだけでも結構変わる
- 46. Single Page Applicationどうなの • やると設計はスッキリする • サーバーのREST APIとやりとりする疎な構成にできる • メモリリークやパフォーマンスと闘う面はある • モバイルでは死活問題 • デスクトップ限定なら「程度による」問題 • サイト・サービス全部を1ページにするのは面倒 • 麻疹の一種なので、ほどほどに
- 47. Flux話題だけど、どうなの • 要約 • 「注文の多いMVC」程度に考える • 時代の流れを語彙に反映したオブザーバーパ ターン
- 48. 総括 • 流行り廃りなので審美眼が大切 • どんなスクリプトでも、最低限の 処理ドメインの分割をする • 現在、注目を集めているのはFlux • 過去の歴史を、時代に合わせてアレンジして 輸入していると考える
- 49. まとめ
- 50. JSパラダイムの方向 • 標準化トラックに乗ったものは「上がり」 • 標準化の過程でAPIが整理・統一される • 流行る（よほど筋悪でなければ） • 「長い物に巻かれろ」 • 標準化の流れに身を任せた方が将来的に楽をしやすい • それ以外の物は審美眼が必要