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.

ES6 in Practice

25,168 views

Published on

Firefox Developer Conference 2015の講演資料
http://www.mozilla.jp/events/devcon/2015/tokyo/

ES6 Modulesの現状確認がメインです。

Published in: Technology
  • Be the first to comment

ES6 in Practice

  1. 1. ES6 in Practice @teppeis Firefox Dev Conf 2015 Nov 15
  2. 2. Hello! • Teppei Sato, @teppeis • Cybozu, Inc. / kintone
  3. 3. kintone.com
  4. 4. MUST BUY! https://gihyo.jp/dp/ebook/2015/978-4-7741-7477-8
  5. 5. いまES6を正しく使うために • ES6, ES7, ECMAScriptとは • ES6 Modules • ES6 ≠ Babel • TypeScript • Rollup • HTTP/2
  6. 6. ほとんど
 Modulesの話に
 なっちゃいました :)
  7. 7. ECMAScript
  8. 8. ES6
  9. 9. ECMAScript • ざっくり言えばJavaScriptの仕様 • Ecma Internationalが標準化 (ECMA-262) • ISOでも標準化 (ISO/IEC 16262) • TC39 (Technical Committee) が策定 • メンバーは全ブラウザベンダーとWeb関連企業
  10. 10. ECMAScript 6 • 2015年6月に公開されたESの最新仕様 • ES5から6年ぶりの大幅改定!
  11. 11. New syntax • Arrow Function • Classes • Modules • Block Scope (let/const) • Extended Object Literal • Default Params • Rest Params • Spread Operator • Destructuring • Iterator • Generator • Template Literal • Tail Call Optimization
  12. 12. New built-in classes and objects • Promise • Map • Set • WeakMap/WeakSet • TypedArray • Symbol • Proxy/Reflect
  13. 13. Improvement of existing classes • String • RegExp • Array • Object • Math • Number
  14. 14. ES6 compatibility table https://kangax.github.io/compat-table/es6/
  15. 15. ES6 or ES2015? http://blog.cybozu.io/entry/9081
  16. 16. ES6 or ES2015? • 正式にはECMAScript 2015 • 来年以降、ES2016, ES2017と
 年次リリースされていくため(後述) • でも、慣れ親しんでる&短いので
 ES6もまだまだ使われてます
  17. 17. ES.next
  18. 18. The TC39 Process: Annual • 機能単位で仕様を策定 • 各仕様提案の策定は5段階のStage Stage 0: Strawman (idea) Stage 1: Proposal (problem, solution and demo/polyfill) Stage 2: Draft (initial spec) Stage 3: Candidate (review and feedback) Stage 4: Finished (two implementations at least) • Stage 4を毎年ES201Xとしてリリース
  19. 19. Stage 0: Strawman • アイデアレベル • GitHubにPRすれば誰でも提案可能 • Send PR to github.com/tc39/ecma-262 !
  20. 20. Stage 4: Finished • 仕様公開の準備完了 • 2つ環境で実装済み
  21. 21. ES2016?
  22. 22. ES2016 (ES7) はどうなる? • 2016年6月に公開予定 • 主にES6のバグ修正 • 2016年1月のTC39 Meetingの時点で
 Stage 4になっている提案 • Array#includes はFF, Chrome, WKで実装済み • 他は exponential operator (**), async/await, SIMD
  23. 23. ES7言うな問題 • ES2016(ES7)にはほとんど新機能入らない • ES6以降の提案仕様をまとめてES7と言いがち • ES7 Decorator, ES7 Object.observe… • ES.nextと言おう • ブラウザに実装されてもキャンセルされる場合も
  24. 24. @domenic said spec version numbers are bullshit es6, es2015, es2016… who cares? you should not. http://www.slideshare.net/domenicdenicola/the-state-of-javascript-2015
  25. 25. ES6 Modules
  26. 26. Good Points • 1ファイル 1モジュール • staticで宣言的なsyntax • strictモード • 循環参照に対応
  27. 27. Syntax
  28. 28. Default export/import // export.js export default function() { return "foo"; } // import.js import foo from "./export.js"; foo();
  29. 29. Named export/import // export.js export function foo() { return "foo"; } export class Bar {} export var baz = "baz"; // import.js import {foo, Bar, baz} from "./export.js"; foo(); new Bar(); console.log(baz); // "baz"
  30. 30. Mixed // export.js export default function() { return "Default"; } export function foo() { return "Named"; } // import.js import def, {foo} from "./export.js"; def(); // "Default" foo(); // "Named"
  31. 31. Defaultがオススメ • ES6 ModulesはDefault Exportが
 最も使いやすいようにデザインされている • Named Exportは、バインディング名を知らな いとimportできない • まずはシンプルな1module 1exportから
  32. 32. Static and Declarative
  33. 33. Staticであるメリット • 実行前にパース時点で依存関係がわかる • 実行前に各種SyntaxErrorを投げられる • Browserify系バンドルツールを書きやすい • 最適化しやすい
  34. 34. 重複したexport default SyntaxError! // export.js export default function() { return "foo1"; } export default function() { return "foo2"; }
  35. 35. 存在しないモジュールをimport SyntaxError! // import.js import foo from "./missing-module.js";
  36. 36. 存在しないバインディングをimport // export.js export function foo() { return "foo"; } // import.js import bar from "./export.js"; SyntaxError!
  37. 37. 注意: • default exportのプロパティと
 named exportは異なる
  38. 38. Default export property // export.js export default { foo: "Default Property" }; export var foo = "Named"; // import.js import def, {foo} from "./export.js"; console.log(def.foo); // "Default Property" console.log(foo): // "Named"
  39. 39. Strict Mode
  40. 40. Script or Module • ES6では実行前にScriptかModuleか指定 • Moduleの場合: • 強制strictモード ("use strict"; 不要) • トップレベルthisはundefined (非window) • トップレベル変数がグローバルにならない
  41. 41. Strict mode in Modules // in module console.log(this); // undefined var foo = 1; // module local, not global // Error! with (obj) {} // Error! var obj = {a: 1, a: 1};
  42. 42. ところで
  43. 43. Script or Module、 どうやって指定するの?
  44. 44. そもそも、 ブラウザからどうやって モジュール読むんだっけ?
  45. 45. Node.jsからは?
  46. 46. モジュール名の識別子は Node/CommonJSと同じルール? 拡張子.jsは不要?
  47. 47. 既存のCommonJSモジュール と相互運用できる?
  48. 48. 動的にモジュールを読むときは? RequireJSみたいにフックできる?
  49. 49. まだです… https://flic.kr/p/4ZaDRz
  50. 50. ES6 Modules • ES6で最も熱望された機能 • ES6で最も実装が遅れそうな機能 • 半分しか仕様が決まってない
  51. 51. ES6 Modules • ES6で定義 • Syntax • Semantics • ES6で未定義 • Loader • Dynamic API
  52. 52. whatwg/loader
  53. 53. github.com/whatwg/loader • ブラウザのローダーを中心に議論中 • Dave Herman (Mozilla)
  54. 54. ブラウザでの読み込み方法(案) <!-- external file --> <script type="module" src="./path/to/module.js"></ script> <!-- inline --> <script type="module"> import foo from "./path/to/module.js"; foo(); </script> <!-- 従来の普通のscript要素ではmoduleを使えない -->
  55. 55. 識別子(案) // 相対URL import foo from "./path/to/module.js"; // 絶対URL import foo from "https://example.com/path/to/module.js";
  56. 56. jsc shellでES6 Modules体験 • JavaScriptCoreが初期実装 (Constellation++) • http://nightly.webkit.org/ • Download the latest binary for Mac OS $ WebKit.app/Contents/Frameworks/10.11/ 
 JavaScriptCore.framework/Versions/A/Resources/jsc 
 -m ./module.js
  57. 57. Roadmap of Loader https://github.com/whatwg/loader/blob/master/roadmap.md
  58. 58. ES6 Modules in Node.js
  59. 59. 議論はまだ開始せず • npmはNode.js待ち • Node.jsはV8待ち • V8はwhatwg/loader待ち
  60. 60. 論点: CommonJSとの相互運用 • ES6 Modules importでCommonJSを読む • CommonJS require()でES6 Modulesを読む
  61. 61. CommonJSはStaticに解析できない // module.js if (someCondition) { exports.foo = "foo"; } // import.js import foo from "./module.js";
  62. 62. Babel
  63. 63. BabelのCommonJS変換 • 識別子の解釈はNode.jsと同じ • CommonJSとの相互運用を重視
 強気に解釈して今動くことを優先
  64. 64. Babel export // source export default {foo: 1}; // transpiled (with babel v5) Object.defineProperty(exports, "__esModule", { value: true }); exports["default"] = { foo: 1 }; module.exports = exports["default"];
  65. 65. Babel import // source import foo from "./module.js" foo(); // transpiled "use strict"; function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { "default": obj }; } var _moduleJs = require("./module.js"); var _moduleJs2 = _interopRequireDefault(_moduleJs); (0, _moduleJs2["default"])();
  66. 66. CommonJSとの相互変換 // module.js function React() {} React.Component = ... module.exports = React; // import.js import Ract, {Component} from "react";
  67. 67. 問題点 • staticなsyntax errorが失われている • default exportとnamed exportを併用不可
  68. 68. Babel 6 Shock https://flic.kr/p/5oHM46
  69. 69. module.exportsに入れなくなった // source export default {foo: 1}; // transpiled (with babel v6) Object.defineProperty(exports, "__esModule", { value: true }); exports["default"] = { foo: 1 }; // module.exports = exports["default"]; これが消えた // import with CommonJS var foo = require("./foo").default; // .defaultが必要に
  70. 70. Babel Risk https://flic.kr/p/87pcQk
  71. 71. Babel Risk • ES6 Modulesは仕様未決定が多い分、
 Babelの独自解釈成分が強い • Babelの解釈変更やNode.js/ブラウザの
 正式実装で、今書いているBabel版ES6 Modulesのコードが動かなくなる可能性
  72. 72. @sebmck said https://speakerdeck.com/sebmck/javascript-transformation-jsconf-2015?slide=52
  73. 73. TypeScript
  74. 74. TypeScript export // source export default {foo: 1}; // transpired exports.__esModule = true; exports["default"] = { foo: 1 };
  75. 75. TypeScript import // export.ts function foo() {return 1;} export = foo; // import.ts import foo from "./export"; // Error!
  76. 76. ES6 Modules in TypeScript • 旧形式のモジュールは旧形式でロード、
 ES6モジュールはES6形式でロード • 文法が2種類あるのはスマートではないが、
 相互運用の独自解釈が少ないため堅牢 • 旧形式が独自なのでES6への移行に動機
  77. 77. Transpilers for ES6
  78. 78. トランスパイラを使う理由 • 生産性の高い機能を
 実行環境に実装される前から使いたい • 標準化されているから(altJSとは違って)
 相互運用性があり将来も動作するはず
  79. 79. ES6 Modulesを今使う? • 標準化はまだ途中、相互運用性はツール依存、 将来動作しない可能性も • staticな文法の利点が薄い • 結局Browserifyする • リスクリターンをよく考慮しましょう
  80. 80. Rollup
  81. 81. Rollup • Next-generation ES6 Module Bundler • staticな文法を最大限活用 • 最適化で未使用のバインディングを削除
  82. 82. http://rollupjs.org/
  83. 83. jsnext:main in package.json { "name": "my-package", "version": "0.1.0", "main": "dist/index.js", "jsnext:main": "src/index.js" } https://github.com/rollup/rollup/wiki/jsnext:main
  84. 84. jsnext:main • ES6コードとCommonJSコードを両方とも
 npmパッケージに載せる仕組み • staticな強みと、後方互換による資産の活用、
 両方のメリットを活かせる • Node.js/npmの未来へのヒント?
  85. 85. ES6 Modules with HTTP/2
  86. 86. 生ES6 Modulesは速い?遅い? • ブラウザにES6 Modulesがネイティブに実装さ れたら、依存は実行時に解決される • 非同期にリクエストを大量になげる通信コスト
  87. 87. HTTP/1.x では遅い • 多量のTCP接続: 多量の依存ファイル • ラウンドトリップタイム: 深いネストした依存 • これまでのRequireJS等と同じ問題 • r.js: 本番環境用の事前ビルドツールで解決
  88. 88. HTTP/2で解決? • 多量のTCP接続: 多重化で解決! • ラウンドトリップタイム: 解決できず…
  89. 89. ラウンドトリップタイムの解決 • ただのServer Pushではキャッシュ制御に難点 • クライアントで制御: ServiceWorker • サーバーで制御: H2O cache-aware server pusher • 現実世界での探求はまだまだこれから!
  90. 90. http://teppeis.hatenablog.com/entry/2015/05/es6-modules-and-http2
  91. 91. Conclusion
  92. 92. Conclusion • 「ES6はいまから使える」言い過ぎた :) • ES6/ES7を正しく理解しよう • BabelとES6の違いを正しく認識しよう • ES6 Modulesはこれからだ!
  93. 93. MUST BUY! https://gihyo.jp/dp/ebook/2015/978-4-7741-7477-8
  94. 94. Thanks!

×