Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

JavaScriptトレンド総括(2014)

866 views

Published on

  • Be the first to comment

JavaScriptトレンド総括(2014)

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

×