JavaScriptトレンド総括(2014)

695 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
695
On SlideShare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
10
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

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が整理・統一される • 流行る(よほど筋悪でなければ) • 「長い物に巻かれろ」 • 標準化の流れに身を任せた方が将来的に楽をしやすい • それ以外の物は審美眼が必要

×