Brendan Eich, profile picture
Uploaded byBrendan Eich
PDF, PPTX15,389 views

JSLOL

The document outlines the history and goals of JavaScript, specifically focusing on the development and features introduced in ECMAScript 6 (ES6). Key features highlighted include block-scoped variables, destructuring, parameter defaults, rest/spread parameters, proxies, modules, and class syntactical sugar. It also touches on the evolution of JavaScript from its origins as 'Mocha' to its adoption as ECMAScript, including significant milestones such as the introduction of AJAX and Harmony's goals for the language.

Embed presentation

Download as PDF, PPTX
1 / 111
2 / 111
3 / 111
4 / 111
5 / 111
6 / 111
7 / 111
8 / 111
9 / 111
10 / 111
11 / 111
12 / 111
13 / 111
14 / 111
15 / 111
16 / 111
17 / 111
18 / 111
19 / 111
20 / 111
21 / 111
22 / 111
23 / 111
24 / 111
25 / 111
26 / 111
27 / 111
28 / 111
29 / 111
30 / 111
31 / 111
32 / 111
33 / 111
34 / 111
35 / 111
36 / 111
37 / 111
38 / 111
39 / 111
40 / 111
41 / 111
42 / 111
43 / 111
44 / 111
45 / 111
46 / 111
47 / 111
48 / 111
49 / 111
50 / 111
51 / 111
52 / 111
53 / 111
54 / 111
55 / 111
56 / 111
57 / 111
58 / 111
59 / 111
60 / 111
61 / 111
62 / 111
63 / 111
64 / 111
65 / 111
66 / 111
67 / 111
68 / 111
69 / 111
70 / 111
71 / 111
72 / 111
73 / 111
74 / 111
75 / 111
76 / 111
77 / 111
78 / 111
79 / 111
80 / 111
81 / 111
82 / 111
83 / 111
84 / 111
85 / 111
86 / 111
87 / 111
88 / 111
89 / 111
90 / 111
91 / 111
92 / 111
93 / 111
94 / 111
95 / 111
96 / 111
97 / 111
98 / 111
99 / 111
100 / 111
101 / 111
102 / 111
103 / 111
104 / 111
105 / 111
106 / 111
107 / 111
108 / 111
109 / 111
110 / 111
111 / 111
JSLOL brendan@mozilla.org Tuesday, October 4, 2011
JSLOL brendan@mozilla.org • History, goals Tuesday, October 4, 2011
JSLOL brendan@mozilla.org • History, goals • ES6, what’s in it? Tuesday, October 4, 2011
JSLOL brendan@mozilla.org • History, goals • ES6, what’s in it? • Controversies Tuesday, October 4, 2011
JSLOL brendan@mozilla.org • History, goals • ES6, what’s in it? • Controversies • Harmony tune-up Tuesday, October 4, 2011
JSLOL brendan@mozilla.org • History, goals • ES6, what’s in it? • Controversies • Harmony tune-up • RiverTrail demo Tuesday, October 4, 2011
A very brief history mozilla 2 Tuesday, October 4, 2011
A very brief history • Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java mozilla 2 Tuesday, October 4, 2011
A very brief history • Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java • September 1995: “LiveScript” (did Netscape marketing go to Microsoft after?) mozilla 2 Tuesday, October 4, 2011
A very brief history • Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java • September 1995: “LiveScript” (did Netscape marketing go to Microsoft after?) • December 1995: “JavaScript”, thanks to Bill Joy (a Sun Founder) mozilla 2 Tuesday, October 4, 2011
A very brief history • Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java • September 1995: “LiveScript” (did Netscape marketing go to Microsoft after?) • December 1995: “JavaScript”, thanks to Bill Joy (a Sun Founder) • 1996-1997: ES1 thanks to ECMA (now Ecma) TC39 -- see my TXJS talk mozilla 2 Tuesday, October 4, 2011
A very brief history • Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java • September 1995: “LiveScript” (did Netscape marketing go to Microsoft after?) • December 1995: “JavaScript”, thanks to Bill Joy (a Sun Founder) • 1996-1997: ES1 thanks to ECMA (now Ecma) TC39 -- see my TXJS talk • 1999: ES3: function expressions, RegExps, try/catch/finally, switch, do-while mozilla 2 Tuesday, October 4, 2011
A very brief history • Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java • September 1995: “LiveScript” (did Netscape marketing go to Microsoft after?) • December 1995: “JavaScript”, thanks to Bill Joy (a Sun Founder) • 1996-1997: ES1 thanks to ECMA (now Ecma) TC39 -- see my TXJS talk • 1999: ES3: function expressions, RegExps, try/catch/finally, switch, do-while • 2005: the Ajax revolution, followed by “The Ajax Experience” mozilla 2 Tuesday, October 4, 2011
A very brief history • Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java • September 1995: “LiveScript” (did Netscape marketing go to Microsoft after?) • December 1995: “JavaScript”, thanks to Bill Joy (a Sun Founder) • 1996-1997: ES1 thanks to ECMA (now Ecma) TC39 -- see my TXJS talk • 1999: ES3: function expressions, RegExps, try/catch/finally, switch, do-while • 2005: the Ajax revolution, followed by “The Ajax Experience” • 2008: ES4 RIP, Harmony founded in July at the Oslo TC39 meeting mozilla 2 Tuesday, October 4, 2011
A very brief history • Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java • September 1995: “LiveScript” (did Netscape marketing go to Microsoft after?) • December 1995: “JavaScript”, thanks to Bill Joy (a Sun Founder) • 1996-1997: ES1 thanks to ECMA (now Ecma) TC39 -- see my TXJS talk • 1999: ES3: function expressions, RegExps, try/catch/finally, switch, do-while • 2005: the Ajax revolution, followed by “The Ajax Experience” • 2008: ES4 RIP, Harmony founded in July at the Oslo TC39 meeting mozilla • 2009: ES5: “use strict”, JSON, Object.create, etc. 2 Tuesday, October 4, 2011
The Harmony goals mozilla 3 Tuesday, October 4, 2011
The Harmony goals • Be a better language for writing: mozilla 3 Tuesday, October 4, 2011
The Harmony goals • Be a better language for writing: • complex applications mozilla 3 Tuesday, October 4, 2011
The Harmony goals • Be a better language for writing: • complex applications • libraries (including the DOM) shared by those applications mozilla 3 Tuesday, October 4, 2011
The Harmony goals • Be a better language for writing: • complex applications • libraries (including the DOM) shared by those applications • code generators targeting the new edition mozilla 3 Tuesday, October 4, 2011
The Harmony goals • Be a better language for writing: • complex applications • libraries (including the DOM) shared by those applications • code generators targeting the new edition • Better tests, if not a testable (executable) specification mozilla 3 Tuesday, October 4, 2011
The Harmony goals • Be a better language for writing: • complex applications • libraries (including the DOM) shared by those applications • code generators targeting the new edition • Better tests, if not a testable (executable) specification • Adopt de facto standards where possible mozilla 3 Tuesday, October 4, 2011
The Harmony goals • Be a better language for writing: • complex applications • libraries (including the DOM) shared by those applications • code generators targeting the new edition • Better tests, if not a testable (executable) specification • Adopt de facto standards where possible • Keep versioning as simple and linear as possible mozilla 3 Tuesday, October 4, 2011
The Harmony goals • Be a better language for writing: • complex applications • libraries (including the DOM) shared by those applications • code generators targeting the new edition • Better tests, if not a testable (executable) specification • Adopt de facto standards where possible • Keep versioning as simple and linear as possible • Support a statically verifiable, object-capability subset mozilla 3 Tuesday, October 4, 2011
Approved for ES6 mozilla 4 Tuesday, October 4, 2011
Approved for ES6 • let, const, function in block scope mozilla 4 Tuesday, October 4, 2011
Approved for ES6 • let, const, function in block scope • destructuring: let {x, y} = pt; let [s, v, o] = triple() mozilla 4 Tuesday, October 4, 2011
Approved for ES6 • let, const, function in block scope • destructuring: let {x, y} = pt; let [s, v, o] = triple() • parameter default values: function f(x, y=1, {z=2, w=3}) {...} mozilla 4 Tuesday, October 4, 2011
Approved for ES6 • let, const, function in block scope • destructuring: let {x, y} = pt; let [s, v, o] = triple() • parameter default values: function f(x, y=1, {z=2, w=3}) {...} • rest, spread: function g(i, j, ...r) { return r.slice(i, j); } let a = [0, 1, 2, 3], o = new any_constructor(...a) mozilla 4 Tuesday, October 4, 2011
Approved for ES6 • let, const, function in block scope • destructuring: let {x, y} = pt; let [s, v, o] = triple() • parameter default values: function f(x, y=1, {z=2, w=3}) {...} • rest, spread: function g(i, j, ...r) { return r.slice(i, j); } let a = [0, 1, 2, 3], o = new any_constructor(...a) • proxies, weak maps: Proxy.create(handler, proto), new WeakMap mozilla 4 Tuesday, October 4, 2011
Approved for ES6 • let, const, function in block scope • destructuring: let {x, y} = pt; let [s, v, o] = triple() • parameter default values: function f(x, y=1, {z=2, w=3}) {...} • rest, spread: function g(i, j, ...r) { return r.slice(i, j); } let a = [0, 1, 2, 3], o = new any_constructor(...a) • proxies, weak maps: Proxy.create(handler, proto), new WeakMap • modules: module M { export function fast_sin(x) {...} } mozilla 4 Tuesday, October 4, 2011
Approved for ES6 • let, const, function in block scope • destructuring: let {x, y} = pt; let [s, v, o] = triple() • parameter default values: function f(x, y=1, {z=2, w=3}) {...} • rest, spread: function g(i, j, ...r) { return r.slice(i, j); } let a = [0, 1, 2, 3], o = new any_constructor(...a) • proxies, weak maps: Proxy.create(handler, proto), new WeakMap • modules: module M { export function fast_sin(x) {...} } • iterators, generators: function* gen() { yield 1; yield 2; } mozilla 4 Tuesday, October 4, 2011
Approved for ES6 • let, const, function in block scope • destructuring: let {x, y} = pt; let [s, v, o] = triple() • parameter default values: function f(x, y=1, {z=2, w=3}) {...} • rest, spread: function g(i, j, ...r) { return r.slice(i, j); } let a = [0, 1, 2, 3], o = new any_constructor(...a) • proxies, weak maps: Proxy.create(handler, proto), new WeakMap • modules: module M { export function fast_sin(x) {...} } • iterators, generators: function* gen() { yield 1; yield 2; } mozilla • comprehensions: return [x+y for x of a for y of b] 4 Tuesday, October 4, 2011
Yet more approved for ES6 mozilla 5 Tuesday, October 4, 2011
Yet more approved for ES6 • Binary data: mozilla 5 Tuesday, October 4, 2011
Yet more approved for ES6 • Binary data: • const Point2D = new StructType({ x: uint32, y: uint32 }), Color = new StructType({ r: uint8, g: uint8, b: uint8 }), Pixel = new StructType({ point: Point2D, color: Color }); mozilla 5 Tuesday, October 4, 2011
Yet more approved for ES6 • Binary data: • const Point2D = new StructType({ x: uint32, y: uint32 }), Color = new StructType({ r: uint8, g: uint8, b: uint8 }), Pixel = new StructType({ point: Point2D, color: Color }); • const Triangle = new ArrayType(Pixel, 3); mozilla 5 Tuesday, October 4, 2011
Yet more approved for ES6 • Binary data: • const Point2D = new StructType({ x: uint32, y: uint32 }), Color = new StructType({ r: uint8, g: uint8, b: uint8 }), Pixel = new StructType({ point: Point2D, color: Color }); • const Triangle = new ArrayType(Pixel, 3); • new Triangle([{ point: { x: 0, y: 0 }, color: { r: 255, g: 255, b: 255 } }, { point: { x: 5, y: 5 }, color: { r: 128, g: 0, b: 0 } }, { point: { x: 10, y: 0 }, color: { r: 0, g: 0, b: 128 } }]); mozilla 5 Tuesday, October 4, 2011
Quasi-Literals mozilla 6 Tuesday, October 4, 2011
Quasi-Literals • Injection-safer string interpolation and domain-specific languages mozilla 6 Tuesday, October 4, 2011
Quasi-Literals • Injection-safer string interpolation and domain-specific languages • Backtick-quoted string desugars to a function call that operates on the literal portions and substitution results: mozilla 6 Tuesday, October 4, 2011
Quasi-Literals • Injection-safer string interpolation and domain-specific languages • Backtick-quoted string desugars to a function call that operates on the literal portions and substitution results: • quasi`literalPart1${substitution}literalPart2` desugars to mozilla 6 Tuesday, October 4, 2011
Quasi-Literals • Injection-safer string interpolation and domain-specific languages • Backtick-quoted string desugars to a function call that operates on the literal portions and substitution results: • quasi`literalPart1${substitution}literalPart2` desugars to • quasi({raw: ["literalPart1", "literalPart1"], cooked: ["literalPart1", "literalPart1"]}, substitution) mozilla 6 Tuesday, October 4, 2011
Quasi-Literals • Injection-safer string interpolation and domain-specific languages • Backtick-quoted string desugars to a function call that operates on the literal portions and substitution results: • quasi`literalPart1${substitution}literalPart2` desugars to • quasi({raw: ["literalPart1", "literalPart1"], cooked: ["literalPart1", "literalPart1"]}, substitution) • Multiline string literals w/o prefix: `literalPart1${substitution} (yes, that was a newline!) literalPart2` mozilla 6 Tuesday, October 4, 2011
Quasi-Literals • Injection-safer string interpolation and domain-specific languages • Backtick-quoted string desugars to a function call that operates on the literal portions and substitution results: • quasi`literalPart1${substitution}literalPart2` desugars to • quasi({raw: ["literalPart1", "literalPart1"], cooked: ["literalPart1", "literalPart1"]}, substitution) • Multiline string literals w/o prefix: `literalPart1${substitution} (yes, that was a newline!) literalPart2` mozilla • Multiline regexp literals: re`literalPart1${substitution} (yes, that was a newline!) w+ literalPart2` 6 Tuesday, October 4, 2011
Classes sort of made it, but face existential doubt mozilla 7 Tuesday, October 4, 2011
Classes sort of made it, but face existential doubt • Sugar for prototypal object pattern, also supports closure patterns: mozilla 7 Tuesday, October 4, 2011
Classes sort of made it, but face existential doubt • Sugar for prototypal object pattern, also supports closure patterns: • const px = Name.create(‘x’), py = Name.create(‘y’); class Point extends Base { constructor(x, y) { super(); this[px] = x, this[py] = y; this.r = function() { return Math.sqrt(x*x + y*y); } } get x() { return this[px]; } get y() { return this[py]; } proto_r() { return Math.sqrt(this[px] * this[px] + this[py] * this[py]); } equals(p) { return this[px] === p[px] && this[py] === p[py]; } mozilla } 7 Tuesday, October 4, 2011
Triangle (the proto operator) mozilla 8 Tuesday, October 4, 2011
Triangle (the proto operator) • Instead of var obj = {__proto__: base, a: 1, b: 2}, use let obj = base <| {a: 1, b: 2} mozilla 8 Tuesday, October 4, 2011
Triangle (the proto operator) • Instead of var obj = {__proto__: base, a: 1, b: 2}, use let obj = base <| {a: 1, b: 2} • Works for other literal object forms: let arr = base <| [p, q, r] let fun = base <| function (...args) { ... } let re = base <| /(w+)s+(w)+/g mozilla 8 Tuesday, October 4, 2011
The monocle-mustache operator mozilla 9 Tuesday, October 4, 2011
The monocle-mustache operator • Inspired by PrototypeJS’s Object.extend mozilla 9 Tuesday, October 4, 2011
The monocle-mustache operator • Inspired by PrototypeJS’s Object.extend • base.{a:1, b:2} // warning: updates base mozilla 9 Tuesday, October 4, 2011
The monocle-mustache operator • Inspired by PrototypeJS’s Object.extend • base.{a:1, b:2} // warning: updates base • Copies all “own” right-hand-side properties (including private names) to base mozilla 9 Tuesday, October 4, 2011
The monocle-mustache operator • Inspired by PrototypeJS’s Object.extend • base.{a:1, b:2} // warning: updates base • Copies all “own” right-hand-side properties (including private names) to base • Should it generate a fresh value instead of mutating? let obj = base.{a:1, b:2} mozilla 9 Tuesday, October 4, 2011
The monocle-mustache operator • Inspired by PrototypeJS’s Object.extend • base.{a:1, b:2} // warning: updates base • Copies all “own” right-hand-side properties (including private names) to base • Should it generate a fresh value instead of mutating? let obj = base.{a:1, b:2} • Or if we want Prototype-style update, should it look like an assignment op? base .= {a:1, b:2} mozilla 9 Tuesday, October 4, 2011
Class pattern using triangle-monocle-mustache mozilla 10 Tuesday, October 4, 2011
Class pattern using triangle-monocle-mustache • const px = Name.create(‘x’), py = Name.create(‘y’); let Point = Base <| function (x, y) { super(); this[px] = x, this[py] = y; this.r = function() { return Math.sqrt(x*x + y*y); } }.prototype.{ get x() { return this[px]; }, get y() { return this[py]; }, proto_r() { return Math.sqrt(this[px] * this[px] + this[py] * this[py]); }, equals(p) { return this[px] === p[px] && this[py] === p[py]; } }.constructor.{ allPoints: [] // class “static” property! } mozilla 10 Tuesday, October 4, 2011
Syntax, yay mozilla 11 Tuesday, October 4, 2011
Syntax, yay • Do we want class syntax, or triangle-monocle-mustache -- or triangle-monocle- equals-mustache? (triangle-monocle-long-nose-mustache?!) mozilla 11 Tuesday, October 4, 2011
Syntax, yay • Do we want class syntax, or triangle-monocle-mustache -- or triangle-monocle- equals-mustache? (triangle-monocle-long-nose-mustache?!) • CoffeeScript has class as sugar for the prototypal pattern -- why can’t JS? mozilla 11 Tuesday, October 4, 2011
Syntax, yay • Do we want class syntax, or triangle-monocle-mustache -- or triangle-monocle- equals-mustache? (triangle-monocle-long-nose-mustache?!) • CoffeeScript has class as sugar for the prototypal pattern -- why can’t JS? • Using funny operators is error prone and (to some, in some fonts) ugly mozilla 11 Tuesday, October 4, 2011
Syntax, yay • Do we want class syntax, or triangle-monocle-mustache -- or triangle-monocle- equals-mustache? (triangle-monocle-long-nose-mustache?!) • CoffeeScript has class as sugar for the prototypal pattern -- why can’t JS? • Using funny operators is error prone and (to some, in some fonts) ugly • TC39, even with the “champions” model, falls into bikeshedding if the syntax is not super-awesome from the start mozilla 11 Tuesday, October 4, 2011
Syntax, yay • Do we want class syntax, or triangle-monocle-mustache -- or triangle-monocle- equals-mustache? (triangle-monocle-long-nose-mustache?!) • CoffeeScript has class as sugar for the prototypal pattern -- why can’t JS? • Using funny operators is error prone and (to some, in some fonts) ugly • TC39, even with the “champions” model, falls into bikeshedding if the syntax is not super-awesome from the start • Should we have a world-wide syntax beauty contest? mozilla 11 Tuesday, October 4, 2011
Not yet in Harmony: arrow function syntax mozilla 12 Tuesday, October 4, 2011
Not yet in Harmony: arrow function syntax • Arrow function syntax, instead of λ, ƒ, or # (want to save # for later) mozilla 12 Tuesday, October 4, 2011
Not yet in Harmony: arrow function syntax • Arrow function syntax, instead of λ, ƒ, or # (want to save # for later) • Just like CoffeeScript: let identity = (x) -> x mozilla 12 Tuesday, October 4, 2011
Not yet in Harmony: arrow function syntax • Arrow function syntax, instead of λ, ƒ, or # (want to save # for later) • Just like CoffeeScript: let identity = (x) -> x • Expression body: const square = (x) -> (x * x) mozilla 12 Tuesday, October 4, 2011
Not yet in Harmony: arrow function syntax • Arrow function syntax, instead of λ, ƒ, or # (want to save # for later) • Just like CoffeeScript: let identity = (x) -> x • Expression body: const square = (x) -> (x * x) • Statement body: let countUsed = (str) -> { if (str in usedWords) usedWords[str]++; else usedWords[str] = 1; } mozilla 12 Tuesday, October 4, 2011
Not yet in Harmony: arrow function syntax • Arrow function syntax, instead of λ, ƒ, or # (want to save # for later) • Just like CoffeeScript: let identity = (x) -> x • Expression body: const square = (x) -> (x * x) • Statement body: let countUsed = (str) -> { if (str in usedWords) usedWords[str]++; else usedWords[str] = 1; } • Fat arrow too: callback = (msg) => ( this.vmail.push(msg) ) mozilla 12 Tuesday, October 4, 2011
Not yet in Harmony: arrow function syntax • Arrow function syntax, instead of λ, ƒ, or # (want to save # for later) • Just like CoffeeScript: let identity = (x) -> x • Expression body: const square = (x) -> (x * x) • Statement body: let countUsed = (str) -> { if (str in usedWords) usedWords[str]++; else usedWords[str] = 1; } • Fat arrow too: callback = (msg) => ( this.vmail.push(msg) ) • Binding forms: let f() -> “writable” const K() -> “readonly” mozilla 12 Tuesday, October 4, 2011
Not yet in Harmony: block lambda revival • Inspired by Smalltalk via Ruby let empty = {||}; // no need for space between bars assert(empty() === undefined); assert(typeof empty === "function"); // native and implements [[Call]] assert(empty.length === 0);   let identity = {|x| x}; // completion is return value   assert(identity(42) === 42); assert(identity.length === 1);   let a = [1, 2, 3, 4]; let b = a.map {|e| e * e} // paren-free call with block is // idiomatic control structure so // no semicolon at end mozilla print(b); // [1, 4, 9, 16] 13 Tuesday, October 4, 2011
More block lambda revival • Paren-free calls, control effects: you know you want it... b = a.map {|e| // newline in block ok e * e * e} // newline after ends call   function find_first_odd(a) { a.forEach { |e, i| if (e & 1) return i; } // returns from function return -1; }   function escape_return() { return {|e| return e}; } b = escape_return(); try { b(42); } catch (e) {} // error, return from // inactive function mozilla 14 Tuesday, October 4, 2011
Syntax, yay again mozilla 15 Tuesday, October 4, 2011
Syntax, yay again • Do we need shorter function syntax at all? mozilla 15 Tuesday, October 4, 2011
Syntax, yay again • Do we need shorter function syntax at all? • Some say no. @mikeal: “I got 99 problems and JavaScript syntax ain’t one.” mozilla 15 Tuesday, October 4, 2011
Syntax, yay again • Do we need shorter function syntax at all? • Some say no. @mikeal: “I got 99 problems and JavaScript syntax ain’t one.” • Others say yes, but divide into roughly three camps: mozilla 15 Tuesday, October 4, 2011
Syntax, yay again • Do we need shorter function syntax at all? • Some say no. @mikeal: “I got 99 problems and JavaScript syntax ain’t one.” • Others say yes, but divide into roughly three camps: • Arrow function syntax, as in CoffeeScript. mozilla 15 Tuesday, October 4, 2011
Syntax, yay again • Do we need shorter function syntax at all? • Some say no. @mikeal: “I got 99 problems and JavaScript syntax ain’t one.” • Others say yes, but divide into roughly three camps: • Arrow function syntax, as in CoffeeScript. • Block lambdas. @jashkenas: “For the record, I too favor [block lambdas] if arrows in JS will need curlies to delimit blocks. Curlies or arrows, not both.” mozilla 15 Tuesday, October 4, 2011
Syntax, yay again • Do we need shorter function syntax at all? • Some say no. @mikeal: “I got 99 problems and JavaScript syntax ain’t one.” • Others say yes, but divide into roughly three camps: • Arrow function syntax, as in CoffeeScript. • Block lambdas. @jashkenas: “For the record, I too favor [block lambdas] if arrows in JS will need curlies to delimit blocks. Curlies or arrows, not both.” • Some leading ugly character, maybe -- unsure about this, return. mozilla 15 Tuesday, October 4, 2011
Harmony tune-up mozilla 16 Tuesday, October 4, 2011
Harmony tune-up • It’s good to question the process as well as the product mozilla 16 Tuesday, October 4, 2011
Harmony tune-up • It’s good to question the process as well as the product • Harmony is both conservative (consensus is hard to achieve) and path- dependent (e.g., because macro research takes time, we’re adding syntactic special forms that could be macros -- if only we had macros) mozilla 16 Tuesday, October 4, 2011
Harmony tune-up • It’s good to question the process as well as the product • Harmony is both conservative (consensus is hard to achieve) and path- dependent (e.g., because macro research takes time, we’re adding syntactic special forms that could be macros -- if only we had macros) • Should we take Dart to heart, without over-reacting? I can’t wait! mozilla 16 Tuesday, October 4, 2011
Harmony tune-up • It’s good to question the process as well as the product • Harmony is both conservative (consensus is hard to achieve) and path- dependent (e.g., because macro research takes time, we’re adding syntactic special forms that could be macros -- if only we had macros) • Should we take Dart to heart, without over-reacting? I can’t wait! • One idea is to prototype in SpiderMonkey and V8 some of the strawman proposals that did not make ES6 now, and see if any deserve promotion to ES6 mozilla 16 Tuesday, October 4, 2011
Harmony tune-up • It’s good to question the process as well as the product • Harmony is both conservative (consensus is hard to achieve) and path- dependent (e.g., because macro research takes time, we’re adding syntactic special forms that could be macros -- if only we had macros) • Should we take Dart to heart, without over-reacting? I can’t wait! • One idea is to prototype in SpiderMonkey and V8 some of the strawman proposals that did not make ES6 now, and see if any deserve promotion to ES6 • Prototyping is hard. We could use help from the community... mozilla 16 Tuesday, October 4, 2011
Good news tonight mozilla 17 Tuesday, October 4, 2011
Good news tonight • ES6 is being drafted mozilla 17 Tuesday, October 4, 2011
Good news tonight • ES6 is being drafted • It contains lots of awesome already mozilla 17 Tuesday, October 4, 2011
Good news tonight • ES6 is being drafted • It contains lots of awesome already • Prototyping in SpiderMonkey and V8 is ongoing, so we’ll actually implementor- and user-test before finalizing the spec mozilla 17 Tuesday, October 4, 2011
Good news tonight • ES6 is being drafted • It contains lots of awesome already • Prototyping in SpiderMonkey and V8 is ongoing, so we’ll actually implementor- and user-test before finalizing the spec • Even if we cut a few things -- still awesome mozilla 17 Tuesday, October 4, 2011
Good news tonight • ES6 is being drafted • It contains lots of awesome already • Prototyping in SpiderMonkey and V8 is ongoing, so we’ll actually implementor- and user-test before finalizing the spec • Even if we cut a few things -- still awesome • Help us find the prettiest and most usable syntax mozilla 17 Tuesday, October 4, 2011
Help us, pretty/usable syntax pony-corn! mozilla 18 Tuesday, October 4, 2011
RiverTrail: Parallel JS mozilla 19 Tuesday, October 4, 2011
RiverTrail: Parallel JS • A ParallelArray library, like typed arrays but immutable. mozilla 19 Tuesday, October 4, 2011
RiverTrail: Parallel JS • A ParallelArray library, like typed arrays but immutable. • map, reduce, combine, filter, partition, scan, scatter -- all produce fresh ParallelArray results mozilla 19 Tuesday, October 4, 2011
RiverTrail: Parallel JS • A ParallelArray library, like typed arrays but immutable. • map, reduce, combine, filter, partition, scan, scatter -- all produce fresh ParallelArray results • Relies on associativity to parallelize arithmetic operations (this does inject some f.p. non-determinism). mozilla 19 Tuesday, October 4, 2011
RiverTrail: Parallel JS • A ParallelArray library, like typed arrays but immutable. • map, reduce, combine, filter, partition, scan, scatter -- all produce fresh ParallelArray results • Relies on associativity to parallelize arithmetic operations (this does inject some f.p. non-determinism). • A Firefox add-on that runs a Narcissus-based JS-to-OpenCL compiler over ParallelArray code mozilla 19 Tuesday, October 4, 2011
RiverTrail: Parallel JS • A ParallelArray library, like typed arrays but immutable. • map, reduce, combine, filter, partition, scan, scatter -- all produce fresh ParallelArray results • Relies on associativity to parallelize arithmetic operations (this does inject some f.p. non-determinism). • A Firefox add-on that runs a Narcissus-based JS-to-OpenCL compiler over ParallelArray code • Source: github.com/RiverTrail/RiverTrail (user id should’ve been IntelLabs) mozilla 19 Tuesday, October 4, 2011
RiverTrail: Parallel JS • A ParallelArray library, like typed arrays but immutable. • map, reduce, combine, filter, partition, scan, scatter -- all produce fresh ParallelArray results • Relies on associativity to parallelize arithmetic operations (this does inject some f.p. non-determinism). • A Firefox add-on that runs a Narcissus-based JS-to-OpenCL compiler over ParallelArray code • Source: github.com/RiverTrail/RiverTrail (user id should’ve been IntelLabs) • Demo code is funny: it contains a "DO NOT use strict”; directive! mozilla 19 Tuesday, October 4, 2011
RiverTrail demo sample code • the ParallelArray constructor builds on typed arrays: NBody.private.initVel = new Array(numBodies); NBody.private.initVelTA = new Float32Array(numBodies * 4); var initAsteroidPos = new Array(50); for (i = 0; i < 50; i++) {     initAsteroidPos[i] = new ParallelArray([                                             NBody.private.posTA[i * 3 + 0],     // x                                             NBody.private.posTA[i * 3 + 1],                                             NBody.private.posTA[i * 3 + 2],                                             ]); }   . . . NBody.private.asteroidPos = new ParallelArray(Float32Array, initAsteroidPos);   . . . NBody.private.vel = new ParallelArray(Float32Array, NBody.private.initVel); mozilla 20 Tuesday, October 4, 2011
ParallelArray methods in action • combine method is a workhorse (takes variable number of args) "animateTickParallel": function animateTickParallel() {     // increment (+=) velocity by acceleration     var newVel = NBody.private.vel.combine(                  1,                      low_precision(NBody.bodyVelocityLoopified),                      NBody.private.pos,                      numBodies,                      NBody.Constant.deltaTime,                      NBody.Constant.epsSqr,                      NBody.time,                      NBody.private.asteroidPos                  );   . . . mozilla 21 Tuesday, October 4, 2011
Always bet on JS Tuesday, October 4, 2011
Always bet on JS • First they said JS couldn’t be useful for building “rich Internet apps” Tuesday, October 4, 2011
Always bet on JS • First they said JS couldn’t be useful for building “rich Internet apps” • Then they said it couldn’t be fast Tuesday, October 4, 2011
Always bet on JS • First they said JS couldn’t be useful for building “rich Internet apps” • Then they said it couldn’t be fast • Then they said it couldn’t be fixed Tuesday, October 4, 2011
Always bet on JS • First they said JS couldn’t be useful for building “rich Internet apps” • Then they said it couldn’t be fast • Then they said it couldn’t be fixed • Then it couldn’t do multicore/GPU Tuesday, October 4, 2011
Always bet on JS • First they said JS couldn’t be useful for building “rich Internet apps” • Then they said it couldn’t be fast • Then they said it couldn’t be fixed • Then it couldn’t do multicore/GPU • Wrong every time! Tuesday, October 4, 2011
Always bet on JS • First they said JS couldn’t be useful for building “rich Internet apps” • Then they said it couldn’t be fast • Then they said it couldn’t be fixed • Then it couldn’t do multicore/GPU • Wrong every time! • My advice: always bet on JS Tuesday, October 4, 2011
Q&A • @BrendanEich on twitter • brendan@mozilla.org • es-discuss@mozilla.org mozilla 23 Tuesday, October 4, 2011

More Related Content

PDF
Capitol js
byBrendan Eich
 
PDF
Txjs talk
byBrendan Eich
 
PDF
ES.next
byBrendan Eich
 
PDF
MSR Talk
byBrendan Eich
 
PDF
Building Languages for the JVM - StarTechConf 2011
byCharles Nutter
 
PDF
Splash
byBrendan Eich
 
PDF
Javaland keynote final
byMarcus Lagergren
 
PDF
Apcug 2011 07-17-intro_to_drupal_jeff_schuler
byhewie
 
Capitol js
byBrendan Eich
 
Txjs talk
byBrendan Eich
 
ES.next
byBrendan Eich
 
MSR Talk
byBrendan Eich
 
Building Languages for the JVM - StarTechConf 2011
byCharles Nutter
 
Splash
byBrendan Eich
 
Javaland keynote final
byMarcus Lagergren
 
Apcug 2011 07-17-intro_to_drupal_jeff_schuler
byhewie
 

Viewers also liked

PDF
Always bet on JS - Finjs.io NYC 2016
byBrendan Eich
 
PDF
dotJS 2015
byBrendan Eich
 
PDF
Fluent14
byBrendan Eich
 
PDF
My dotJS Talk
byBrendan Eich
 
PDF
Mozilla's NodeConf talk
byBrendan Eich
 
PDF
Paren free
byBrendan Eich
 
PDF
Fluent15
byBrendan Eich
 
PDF
Taysom seminar
byBrendan Eich
 
PDF
JS Responsibilities
byBrendan Eich
 
PDF
Web futures
byBrendan Eich
 
PDF
Mozilla Research Party Talk
byBrendan Eich
 
PDF
Extensible Operators and Literals for JavaScript
byBrendan Eich
 
PDF
Value Objects, Full Throttle (to be updated for spring TC39 meetings)
byBrendan Eich
 
PDF
Value objects in JS - an ES7 work in progress
byBrendan Eich
 
PDF
The Same-Origin Saga
byBrendan Eich
 
PDF
Int64
byBrendan Eich
 
Always bet on JS - Finjs.io NYC 2016
byBrendan Eich
 
dotJS 2015
byBrendan Eich
 
Fluent14
byBrendan Eich
 
My dotJS Talk
byBrendan Eich
 
Mozilla's NodeConf talk
byBrendan Eich
 
Paren free
byBrendan Eich
 
Fluent15
byBrendan Eich
 
Taysom seminar
byBrendan Eich
 
JS Responsibilities
byBrendan Eich
 
Web futures
byBrendan Eich
 
Mozilla Research Party Talk
byBrendan Eich
 
Extensible Operators and Literals for JavaScript
byBrendan Eich
 
Value Objects, Full Throttle (to be updated for spring TC39 meetings)
byBrendan Eich
 
Value objects in JS - an ES7 work in progress
byBrendan Eich
 
The Same-Origin Saga
byBrendan Eich
 
Int64
byBrendan Eich
 

Similar to JSLOL

PDF
Javascript FTW
byPascal Rettig
 
PDF
Red Dirt JS
byNathan Smith
 
PDF
Web application development - The past, the present, the future
byJuho Vepsäläinen
 
PPTX
Javascript Today
bySistek Yazılım
 
PDF
JavaScript History
byRhio Kim
 
PDF
Do Try This At Home Ajax Bookmarking, Cross Site Scripting, And Other Web 2 ...
byjward5519
 
PDF
JavaScript Intro
byEric Brown
 
PPTX
JavaScript as Development Platform
byAlexei Skachykhin
 
PPTX
Java script introduction
byJesus Obenita Jr.
 
PDF
High Performance JavaScript
bygreenwop
 
PDF
JavaScript Landscape
byJanne Kuuskeri
 
PDF
Mozilla
byshivangi srivastava
 
PPTX
Brief History of JavaScript
byRifad Ainun Nazieb
 
PDF
A Look at the Future of HTML5
byTim Wright
 
PDF
Building Distributed JavaScript Widgets with jQuery
bybenvinegar
 
KEY
The History of HTML5
byMike Wilcox
 
PPT
Introduction To Rich Internet Applications
byAbdelmonaim Remani
 
PDF
HTML XHTML HTML5
bytimstone
 
PDF
Tim stone.html5.rjug.20110316
byRichmond Java User's Group
 
PPT
TypeScript - Javascript done right
byWekoslav Stefanovski
 
Javascript FTW
byPascal Rettig
 
Red Dirt JS
byNathan Smith
 
Web application development - The past, the present, the future
byJuho Vepsäläinen
 
Javascript Today
bySistek Yazılım
 
JavaScript History
byRhio Kim
 
Do Try This At Home Ajax Bookmarking, Cross Site Scripting, And Other Web 2 ...
byjward5519
 
JavaScript Intro
byEric Brown
 
JavaScript as Development Platform
byAlexei Skachykhin
 
Java script introduction
byJesus Obenita Jr.
 
High Performance JavaScript
bygreenwop
 
JavaScript Landscape
byJanne Kuuskeri
 
Mozilla
byshivangi srivastava
 
Brief History of JavaScript
byRifad Ainun Nazieb
 
A Look at the Future of HTML5
byTim Wright
 
Building Distributed JavaScript Widgets with jQuery
bybenvinegar
 
The History of HTML5
byMike Wilcox
 
Introduction To Rich Internet Applications
byAbdelmonaim Remani
 
HTML XHTML HTML5
bytimstone
 
Tim stone.html5.rjug.20110316
byRichmond Java User's Group
 
TypeScript - Javascript done right
byWekoslav Stefanovski
 

Recently uploaded

PDF
Traditional-Security-Models-No-Longer-Work.pptx (1).pdf
byOhhproJunction
 
PDF
UiPath Automation Developer Associate Training Series 2026 - Session 2
byDianaGray10
 
PDF
TravelTech Paris 2025 | The EU Digital Identity Wallet and it’s impact on Tra...
byapidays
 
PDF
Explaining the flow of purpose-specific BOM
byakipii ogaoga
 
PDF
Explaining specific examples of purpose-specific BOM
byakipii ogaoga
 
PDF
How to Install XRDP on CentOS 10 .pdf
byGreen Webpage
 
PPTX
Introducing VisualSim 2610 The Next Leap in System Level Modeling
byDeepak Shankar
 
PPTX
How Does an ICO Launchpad Work Step-by-Step Breakdown.pptx
byTom Hardy S
 
PDF
Oracle Cloud Infrastructure 2025 Architect Professional (1Z0-1127-25) Master ...
byExamCert App
 
PDF
shayk.online - Anonymous chat with Sinatra and WebSockets
byEleanor McHugh
 
PDF
Why Many Smart Device Platforms Fail to Scale?
byPromeraki Developments
 
PPTX
Do You Control the AI, or Does the AI Control You?
bymedhateltoukhy
 
PPTX
Automation Without Apprentices: How AI Challenges the Open Source Way
byIcinga
 
PDF
final.pdf
byomarbishtawi04
 
PDF
Session 1/5: Enhancing Automation with Screenplay & Business Rules
bysuhanisingh58689
 
PDF
The new book “Marketing in the Metaverse” spotlights Scott M. Graffius’ research
byScott M. Graffius
 
PDF
February 2026 Patch Tuesday hosted by Chris Goettl and Todd Schell
byIvanti
 
PPTX
TravelTech Paris 2025 | Beyond the pipes: Why Channel Management isn’t really...
byapidays
 
PDF
GenerationAI Paris 2025 | How Agentic AI is Reinventing Organizations
byapidays
 
PDF
Writing GPU-Ready AI Models in Pure Java with Babylon
byAna-Maria Mihalceanu
 
Traditional-Security-Models-No-Longer-Work.pptx (1).pdf
byOhhproJunction
 
UiPath Automation Developer Associate Training Series 2026 - Session 2
byDianaGray10
 
TravelTech Paris 2025 | The EU Digital Identity Wallet and it’s impact on Tra...
byapidays
 
Explaining the flow of purpose-specific BOM
byakipii ogaoga
 
Explaining specific examples of purpose-specific BOM
byakipii ogaoga
 
How to Install XRDP on CentOS 10 .pdf
byGreen Webpage
 
Introducing VisualSim 2610 The Next Leap in System Level Modeling
byDeepak Shankar
 
How Does an ICO Launchpad Work Step-by-Step Breakdown.pptx
byTom Hardy S
 
Oracle Cloud Infrastructure 2025 Architect Professional (1Z0-1127-25) Master ...
byExamCert App
 
shayk.online - Anonymous chat with Sinatra and WebSockets
byEleanor McHugh
 
Why Many Smart Device Platforms Fail to Scale?
byPromeraki Developments
 
Do You Control the AI, or Does the AI Control You?
bymedhateltoukhy
 
Automation Without Apprentices: How AI Challenges the Open Source Way
byIcinga
 
final.pdf
byomarbishtawi04
 
Session 1/5: Enhancing Automation with Screenplay & Business Rules
bysuhanisingh58689
 
The new book “Marketing in the Metaverse” spotlights Scott M. Graffius’ research
byScott M. Graffius
 
February 2026 Patch Tuesday hosted by Chris Goettl and Todd Schell
byIvanti
 
TravelTech Paris 2025 | Beyond the pipes: Why Channel Management isn’t really...
byapidays
 
GenerationAI Paris 2025 | How Agentic AI is Reinventing Organizations
byapidays
 
Writing GPU-Ready AI Models in Pure Java with Babylon
byAna-Maria Mihalceanu
 

JSLOL

  • 1.
    JSLOL brendan@mozilla.org Tuesday, October 4, 2011
  • 2.
    JSLOL brendan@mozilla.org • History, goals Tuesday, October 4, 2011
  • 3.
    JSLOL brendan@mozilla.org • History, goals • ES6, what’s in it? Tuesday, October 4, 2011
  • 4.
    JSLOL brendan@mozilla.org • History, goals • ES6, what’s in it? • Controversies Tuesday, October 4, 2011
  • 5.
    JSLOL brendan@mozilla.org • History, goals • ES6, what’s in it? • Controversies • Harmony tune-up Tuesday, October 4, 2011
  • 6.
    JSLOL brendan@mozilla.org • History, goals • ES6, what’s in it? • Controversies • Harmony tune-up • RiverTrail demo Tuesday, October 4, 2011
  • 7.
    A very briefhistory mozilla 2 Tuesday, October 4, 2011
  • 8.
    A very briefhistory • Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java mozilla 2 Tuesday, October 4, 2011
  • 9.
    A very briefhistory • Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java • September 1995: “LiveScript” (did Netscape marketing go to Microsoft after?) mozilla 2 Tuesday, October 4, 2011
  • 10.
    A very briefhistory • Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java • September 1995: “LiveScript” (did Netscape marketing go to Microsoft after?) • December 1995: “JavaScript”, thanks to Bill Joy (a Sun Founder) mozilla 2 Tuesday, October 4, 2011
  • 11.
    A very briefhistory • Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java • September 1995: “LiveScript” (did Netscape marketing go to Microsoft after?) • December 1995: “JavaScript”, thanks to Bill Joy (a Sun Founder) • 1996-1997: ES1 thanks to ECMA (now Ecma) TC39 -- see my TXJS talk mozilla 2 Tuesday, October 4, 2011
  • 12.
    A very briefhistory • Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java • September 1995: “LiveScript” (did Netscape marketing go to Microsoft after?) • December 1995: “JavaScript”, thanks to Bill Joy (a Sun Founder) • 1996-1997: ES1 thanks to ECMA (now Ecma) TC39 -- see my TXJS talk • 1999: ES3: function expressions, RegExps, try/catch/finally, switch, do-while mozilla 2 Tuesday, October 4, 2011
  • 13.
    A very briefhistory • Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java • September 1995: “LiveScript” (did Netscape marketing go to Microsoft after?) • December 1995: “JavaScript”, thanks to Bill Joy (a Sun Founder) • 1996-1997: ES1 thanks to ECMA (now Ecma) TC39 -- see my TXJS talk • 1999: ES3: function expressions, RegExps, try/catch/finally, switch, do-while • 2005: the Ajax revolution, followed by “The Ajax Experience” mozilla 2 Tuesday, October 4, 2011
  • 14.
    A very briefhistory • Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java • September 1995: “LiveScript” (did Netscape marketing go to Microsoft after?) • December 1995: “JavaScript”, thanks to Bill Joy (a Sun Founder) • 1996-1997: ES1 thanks to ECMA (now Ecma) TC39 -- see my TXJS talk • 1999: ES3: function expressions, RegExps, try/catch/finally, switch, do-while • 2005: the Ajax revolution, followed by “The Ajax Experience” • 2008: ES4 RIP, Harmony founded in July at the Oslo TC39 meeting mozilla 2 Tuesday, October 4, 2011
  • 15.
    A very briefhistory • Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java • September 1995: “LiveScript” (did Netscape marketing go to Microsoft after?) • December 1995: “JavaScript”, thanks to Bill Joy (a Sun Founder) • 1996-1997: ES1 thanks to ECMA (now Ecma) TC39 -- see my TXJS talk • 1999: ES3: function expressions, RegExps, try/catch/finally, switch, do-while • 2005: the Ajax revolution, followed by “The Ajax Experience” • 2008: ES4 RIP, Harmony founded in July at the Oslo TC39 meeting mozilla • 2009: ES5: “use strict”, JSON, Object.create, etc. 2 Tuesday, October 4, 2011
  • 16.
    The Harmony goals mozilla 3 Tuesday, October 4, 2011
  • 17.
    The Harmony goals • Be a better language for writing: mozilla 3 Tuesday, October 4, 2011
  • 18.
    The Harmony goals • Be a better language for writing: • complex applications mozilla 3 Tuesday, October 4, 2011
  • 19.
    The Harmony goals • Be a better language for writing: • complex applications • libraries (including the DOM) shared by those applications mozilla 3 Tuesday, October 4, 2011
  • 20.
    The Harmony goals • Be a better language for writing: • complex applications • libraries (including the DOM) shared by those applications • code generators targeting the new edition mozilla 3 Tuesday, October 4, 2011
  • 21.
    The Harmony goals • Be a better language for writing: • complex applications • libraries (including the DOM) shared by those applications • code generators targeting the new edition • Better tests, if not a testable (executable) specification mozilla 3 Tuesday, October 4, 2011
  • 22.
    The Harmony goals • Be a better language for writing: • complex applications • libraries (including the DOM) shared by those applications • code generators targeting the new edition • Better tests, if not a testable (executable) specification • Adopt de facto standards where possible mozilla 3 Tuesday, October 4, 2011
  • 23.
    The Harmony goals • Be a better language for writing: • complex applications • libraries (including the DOM) shared by those applications • code generators targeting the new edition • Better tests, if not a testable (executable) specification • Adopt de facto standards where possible • Keep versioning as simple and linear as possible mozilla 3 Tuesday, October 4, 2011
  • 24.
    The Harmony goals • Be a better language for writing: • complex applications • libraries (including the DOM) shared by those applications • code generators targeting the new edition • Better tests, if not a testable (executable) specification • Adopt de facto standards where possible • Keep versioning as simple and linear as possible • Support a statically verifiable, object-capability subset mozilla 3 Tuesday, October 4, 2011
  • 25.
    Approved for ES6 mozilla 4 Tuesday, October 4, 2011
  • 26.
    Approved for ES6 • let, const, function in block scope mozilla 4 Tuesday, October 4, 2011
  • 27.
    Approved for ES6 • let, const, function in block scope • destructuring: let {x, y} = pt; let [s, v, o] = triple() mozilla 4 Tuesday, October 4, 2011
  • 28.
    Approved for ES6 • let, const, function in block scope • destructuring: let {x, y} = pt; let [s, v, o] = triple() • parameter default values: function f(x, y=1, {z=2, w=3}) {...} mozilla 4 Tuesday, October 4, 2011
  • 29.
    Approved for ES6 • let, const, function in block scope • destructuring: let {x, y} = pt; let [s, v, o] = triple() • parameter default values: function f(x, y=1, {z=2, w=3}) {...} • rest, spread: function g(i, j, ...r) { return r.slice(i, j); } let a = [0, 1, 2, 3], o = new any_constructor(...a) mozilla 4 Tuesday, October 4, 2011
  • 30.
    Approved for ES6 • let, const, function in block scope • destructuring: let {x, y} = pt; let [s, v, o] = triple() • parameter default values: function f(x, y=1, {z=2, w=3}) {...} • rest, spread: function g(i, j, ...r) { return r.slice(i, j); } let a = [0, 1, 2, 3], o = new any_constructor(...a) • proxies, weak maps: Proxy.create(handler, proto), new WeakMap mozilla 4 Tuesday, October 4, 2011
  • 31.
    Approved for ES6 • let, const, function in block scope • destructuring: let {x, y} = pt; let [s, v, o] = triple() • parameter default values: function f(x, y=1, {z=2, w=3}) {...} • rest, spread: function g(i, j, ...r) { return r.slice(i, j); } let a = [0, 1, 2, 3], o = new any_constructor(...a) • proxies, weak maps: Proxy.create(handler, proto), new WeakMap • modules: module M { export function fast_sin(x) {...} } mozilla 4 Tuesday, October 4, 2011
  • 32.
    Approved for ES6 • let, const, function in block scope • destructuring: let {x, y} = pt; let [s, v, o] = triple() • parameter default values: function f(x, y=1, {z=2, w=3}) {...} • rest, spread: function g(i, j, ...r) { return r.slice(i, j); } let a = [0, 1, 2, 3], o = new any_constructor(...a) • proxies, weak maps: Proxy.create(handler, proto), new WeakMap • modules: module M { export function fast_sin(x) {...} } • iterators, generators: function* gen() { yield 1; yield 2; } mozilla 4 Tuesday, October 4, 2011
  • 33.
    Approved for ES6 • let, const, function in block scope • destructuring: let {x, y} = pt; let [s, v, o] = triple() • parameter default values: function f(x, y=1, {z=2, w=3}) {...} • rest, spread: function g(i, j, ...r) { return r.slice(i, j); } let a = [0, 1, 2, 3], o = new any_constructor(...a) • proxies, weak maps: Proxy.create(handler, proto), new WeakMap • modules: module M { export function fast_sin(x) {...} } • iterators, generators: function* gen() { yield 1; yield 2; } mozilla • comprehensions: return [x+y for x of a for y of b] 4 Tuesday, October 4, 2011
  • 34.
    Yet more approvedfor ES6 mozilla 5 Tuesday, October 4, 2011
  • 35.
    Yet more approvedfor ES6 • Binary data: mozilla 5 Tuesday, October 4, 2011
  • 36.
    Yet more approvedfor ES6 • Binary data: • const Point2D = new StructType({ x: uint32, y: uint32 }), Color = new StructType({ r: uint8, g: uint8, b: uint8 }), Pixel = new StructType({ point: Point2D, color: Color }); mozilla 5 Tuesday, October 4, 2011
  • 37.
    Yet more approvedfor ES6 • Binary data: • const Point2D = new StructType({ x: uint32, y: uint32 }), Color = new StructType({ r: uint8, g: uint8, b: uint8 }), Pixel = new StructType({ point: Point2D, color: Color }); • const Triangle = new ArrayType(Pixel, 3); mozilla 5 Tuesday, October 4, 2011
  • 38.
    Yet more approvedfor ES6 • Binary data: • const Point2D = new StructType({ x: uint32, y: uint32 }), Color = new StructType({ r: uint8, g: uint8, b: uint8 }), Pixel = new StructType({ point: Point2D, color: Color }); • const Triangle = new ArrayType(Pixel, 3); • new Triangle([{ point: { x: 0, y: 0 }, color: { r: 255, g: 255, b: 255 } }, { point: { x: 5, y: 5 }, color: { r: 128, g: 0, b: 0 } }, { point: { x: 10, y: 0 }, color: { r: 0, g: 0, b: 128 } }]); mozilla 5 Tuesday, October 4, 2011
  • 39.
    Quasi-Literals mozilla 6 Tuesday, October 4, 2011
  • 40.
    Quasi-Literals • Injection-safer string interpolation and domain-specific languages mozilla 6 Tuesday, October 4, 2011
  • 41.
    Quasi-Literals • Injection-safer string interpolation and domain-specific languages • Backtick-quoted string desugars to a function call that operates on the literal portions and substitution results: mozilla 6 Tuesday, October 4, 2011
  • 42.
    Quasi-Literals • Injection-safer string interpolation and domain-specific languages • Backtick-quoted string desugars to a function call that operates on the literal portions and substitution results: • quasi`literalPart1${substitution}literalPart2` desugars to mozilla 6 Tuesday, October 4, 2011
  • 43.
    Quasi-Literals • Injection-safer string interpolation and domain-specific languages • Backtick-quoted string desugars to a function call that operates on the literal portions and substitution results: • quasi`literalPart1${substitution}literalPart2` desugars to • quasi({raw: ["literalPart1", "literalPart1"], cooked: ["literalPart1", "literalPart1"]}, substitution) mozilla 6 Tuesday, October 4, 2011
  • 44.
    Quasi-Literals • Injection-safer string interpolation and domain-specific languages • Backtick-quoted string desugars to a function call that operates on the literal portions and substitution results: • quasi`literalPart1${substitution}literalPart2` desugars to • quasi({raw: ["literalPart1", "literalPart1"], cooked: ["literalPart1", "literalPart1"]}, substitution) • Multiline string literals w/o prefix: `literalPart1${substitution} (yes, that was a newline!) literalPart2` mozilla 6 Tuesday, October 4, 2011
  • 45.
    Quasi-Literals • Injection-safer string interpolation and domain-specific languages • Backtick-quoted string desugars to a function call that operates on the literal portions and substitution results: • quasi`literalPart1${substitution}literalPart2` desugars to • quasi({raw: ["literalPart1", "literalPart1"], cooked: ["literalPart1", "literalPart1"]}, substitution) • Multiline string literals w/o prefix: `literalPart1${substitution} (yes, that was a newline!) literalPart2` mozilla • Multiline regexp literals: re`literalPart1${substitution} (yes, that was a newline!) w+ literalPart2` 6 Tuesday, October 4, 2011
  • 46.
    Classes sort ofmade it, but face existential doubt mozilla 7 Tuesday, October 4, 2011
  • 47.
    Classes sort ofmade it, but face existential doubt • Sugar for prototypal object pattern, also supports closure patterns: mozilla 7 Tuesday, October 4, 2011
  • 48.
    Classes sort ofmade it, but face existential doubt • Sugar for prototypal object pattern, also supports closure patterns: • const px = Name.create(‘x’), py = Name.create(‘y’); class Point extends Base { constructor(x, y) { super(); this[px] = x, this[py] = y; this.r = function() { return Math.sqrt(x*x + y*y); } } get x() { return this[px]; } get y() { return this[py]; } proto_r() { return Math.sqrt(this[px] * this[px] + this[py] * this[py]); } equals(p) { return this[px] === p[px] && this[py] === p[py]; } mozilla } 7 Tuesday, October 4, 2011
  • 49.
    Triangle (the protooperator) mozilla 8 Tuesday, October 4, 2011
  • 50.
    Triangle (the protooperator) • Instead of var obj = {__proto__: base, a: 1, b: 2}, use let obj = base <| {a: 1, b: 2} mozilla 8 Tuesday, October 4, 2011
  • 51.
    Triangle (the protooperator) • Instead of var obj = {__proto__: base, a: 1, b: 2}, use let obj = base <| {a: 1, b: 2} • Works for other literal object forms: let arr = base <| [p, q, r] let fun = base <| function (...args) { ... } let re = base <| /(w+)s+(w)+/g mozilla 8 Tuesday, October 4, 2011
  • 52.
    The monocle-mustache operator mozilla 9 Tuesday, October 4, 2011
  • 53.
    The monocle-mustache operator • Inspired by PrototypeJS’s Object.extend mozilla 9 Tuesday, October 4, 2011
  • 54.
    The monocle-mustache operator • Inspired by PrototypeJS’s Object.extend • base.{a:1, b:2} // warning: updates base mozilla 9 Tuesday, October 4, 2011
  • 55.
    The monocle-mustache operator • Inspired by PrototypeJS’s Object.extend • base.{a:1, b:2} // warning: updates base • Copies all “own” right-hand-side properties (including private names) to base mozilla 9 Tuesday, October 4, 2011
  • 56.
    The monocle-mustache operator • Inspired by PrototypeJS’s Object.extend • base.{a:1, b:2} // warning: updates base • Copies all “own” right-hand-side properties (including private names) to base • Should it generate a fresh value instead of mutating? let obj = base.{a:1, b:2} mozilla 9 Tuesday, October 4, 2011
  • 57.
    The monocle-mustache operator • Inspired by PrototypeJS’s Object.extend • base.{a:1, b:2} // warning: updates base • Copies all “own” right-hand-side properties (including private names) to base • Should it generate a fresh value instead of mutating? let obj = base.{a:1, b:2} • Or if we want Prototype-style update, should it look like an assignment op? base .= {a:1, b:2} mozilla 9 Tuesday, October 4, 2011
  • 58.
    Class pattern usingtriangle-monocle-mustache mozilla 10 Tuesday, October 4, 2011
  • 59.
    Class pattern usingtriangle-monocle-mustache • const px = Name.create(‘x’), py = Name.create(‘y’); let Point = Base <| function (x, y) { super(); this[px] = x, this[py] = y; this.r = function() { return Math.sqrt(x*x + y*y); } }.prototype.{ get x() { return this[px]; }, get y() { return this[py]; }, proto_r() { return Math.sqrt(this[px] * this[px] + this[py] * this[py]); }, equals(p) { return this[px] === p[px] && this[py] === p[py]; } }.constructor.{ allPoints: [] // class “static” property! } mozilla 10 Tuesday, October 4, 2011
  • 60.
    Syntax, yay mozilla 11 Tuesday, October 4, 2011
  • 61.
    Syntax, yay • Do we want class syntax, or triangle-monocle-mustache -- or triangle-monocle- equals-mustache? (triangle-monocle-long-nose-mustache?!) mozilla 11 Tuesday, October 4, 2011
  • 62.
    Syntax, yay • Do we want class syntax, or triangle-monocle-mustache -- or triangle-monocle- equals-mustache? (triangle-monocle-long-nose-mustache?!) • CoffeeScript has class as sugar for the prototypal pattern -- why can’t JS? mozilla 11 Tuesday, October 4, 2011
  • 63.
    Syntax, yay • Do we want class syntax, or triangle-monocle-mustache -- or triangle-monocle- equals-mustache? (triangle-monocle-long-nose-mustache?!) • CoffeeScript has class as sugar for the prototypal pattern -- why can’t JS? • Using funny operators is error prone and (to some, in some fonts) ugly mozilla 11 Tuesday, October 4, 2011
  • 64.
    Syntax, yay • Do we want class syntax, or triangle-monocle-mustache -- or triangle-monocle- equals-mustache? (triangle-monocle-long-nose-mustache?!) • CoffeeScript has class as sugar for the prototypal pattern -- why can’t JS? • Using funny operators is error prone and (to some, in some fonts) ugly • TC39, even with the “champions” model, falls into bikeshedding if the syntax is not super-awesome from the start mozilla 11 Tuesday, October 4, 2011
  • 65.
    Syntax, yay • Do we want class syntax, or triangle-monocle-mustache -- or triangle-monocle- equals-mustache? (triangle-monocle-long-nose-mustache?!) • CoffeeScript has class as sugar for the prototypal pattern -- why can’t JS? • Using funny operators is error prone and (to some, in some fonts) ugly • TC39, even with the “champions” model, falls into bikeshedding if the syntax is not super-awesome from the start • Should we have a world-wide syntax beauty contest? mozilla 11 Tuesday, October 4, 2011
  • 66.
    Not yet inHarmony: arrow function syntax mozilla 12 Tuesday, October 4, 2011
  • 67.
    Not yet inHarmony: arrow function syntax • Arrow function syntax, instead of λ, ƒ, or # (want to save # for later) mozilla 12 Tuesday, October 4, 2011
  • 68.
    Not yet inHarmony: arrow function syntax • Arrow function syntax, instead of λ, ƒ, or # (want to save # for later) • Just like CoffeeScript: let identity = (x) -> x mozilla 12 Tuesday, October 4, 2011
  • 69.
    Not yet inHarmony: arrow function syntax • Arrow function syntax, instead of λ, ƒ, or # (want to save # for later) • Just like CoffeeScript: let identity = (x) -> x • Expression body: const square = (x) -> (x * x) mozilla 12 Tuesday, October 4, 2011
  • 70.
    Not yet inHarmony: arrow function syntax • Arrow function syntax, instead of λ, ƒ, or # (want to save # for later) • Just like CoffeeScript: let identity = (x) -> x • Expression body: const square = (x) -> (x * x) • Statement body: let countUsed = (str) -> { if (str in usedWords) usedWords[str]++; else usedWords[str] = 1; } mozilla 12 Tuesday, October 4, 2011
  • 71.
    Not yet inHarmony: arrow function syntax • Arrow function syntax, instead of λ, ƒ, or # (want to save # for later) • Just like CoffeeScript: let identity = (x) -> x • Expression body: const square = (x) -> (x * x) • Statement body: let countUsed = (str) -> { if (str in usedWords) usedWords[str]++; else usedWords[str] = 1; } • Fat arrow too: callback = (msg) => ( this.vmail.push(msg) ) mozilla 12 Tuesday, October 4, 2011
  • 72.
    Not yet inHarmony: arrow function syntax • Arrow function syntax, instead of λ, ƒ, or # (want to save # for later) • Just like CoffeeScript: let identity = (x) -> x • Expression body: const square = (x) -> (x * x) • Statement body: let countUsed = (str) -> { if (str in usedWords) usedWords[str]++; else usedWords[str] = 1; } • Fat arrow too: callback = (msg) => ( this.vmail.push(msg) ) • Binding forms: let f() -> “writable” const K() -> “readonly” mozilla 12 Tuesday, October 4, 2011
  • 73.
    Not yet inHarmony: block lambda revival • Inspired by Smalltalk via Ruby let empty = {||}; // no need for space between bars assert(empty() === undefined); assert(typeof empty === "function"); // native and implements [[Call]] assert(empty.length === 0);   let identity = {|x| x}; // completion is return value   assert(identity(42) === 42); assert(identity.length === 1);   let a = [1, 2, 3, 4]; let b = a.map {|e| e * e} // paren-free call with block is // idiomatic control structure so // no semicolon at end mozilla print(b); // [1, 4, 9, 16] 13 Tuesday, October 4, 2011
  • 74.
    More block lambdarevival • Paren-free calls, control effects: you know you want it... b = a.map {|e| // newline in block ok e * e * e} // newline after ends call   function find_first_odd(a) { a.forEach { |e, i| if (e & 1) return i; } // returns from function return -1; }   function escape_return() { return {|e| return e}; } b = escape_return(); try { b(42); } catch (e) {} // error, return from // inactive function mozilla 14 Tuesday, October 4, 2011
  • 75.
    Syntax, yay again mozilla 15 Tuesday, October 4, 2011
  • 76.
    Syntax, yay again • Do we need shorter function syntax at all? mozilla 15 Tuesday, October 4, 2011
  • 77.
    Syntax, yay again • Do we need shorter function syntax at all? • Some say no. @mikeal: “I got 99 problems and JavaScript syntax ain’t one.” mozilla 15 Tuesday, October 4, 2011
  • 78.
    Syntax, yay again • Do we need shorter function syntax at all? • Some say no. @mikeal: “I got 99 problems and JavaScript syntax ain’t one.” • Others say yes, but divide into roughly three camps: mozilla 15 Tuesday, October 4, 2011
  • 79.
    Syntax, yay again • Do we need shorter function syntax at all? • Some say no. @mikeal: “I got 99 problems and JavaScript syntax ain’t one.” • Others say yes, but divide into roughly three camps: • Arrow function syntax, as in CoffeeScript. mozilla 15 Tuesday, October 4, 2011
  • 80.
    Syntax, yay again • Do we need shorter function syntax at all? • Some say no. @mikeal: “I got 99 problems and JavaScript syntax ain’t one.” • Others say yes, but divide into roughly three camps: • Arrow function syntax, as in CoffeeScript. • Block lambdas. @jashkenas: “For the record, I too favor [block lambdas] if arrows in JS will need curlies to delimit blocks. Curlies or arrows, not both.” mozilla 15 Tuesday, October 4, 2011
  • 81.
    Syntax, yay again • Do we need shorter function syntax at all? • Some say no. @mikeal: “I got 99 problems and JavaScript syntax ain’t one.” • Others say yes, but divide into roughly three camps: • Arrow function syntax, as in CoffeeScript. • Block lambdas. @jashkenas: “For the record, I too favor [block lambdas] if arrows in JS will need curlies to delimit blocks. Curlies or arrows, not both.” • Some leading ugly character, maybe -- unsure about this, return. mozilla 15 Tuesday, October 4, 2011
  • 82.
    Harmony tune-up mozilla 16 Tuesday, October 4, 2011
  • 83.
    Harmony tune-up • It’s good to question the process as well as the product mozilla 16 Tuesday, October 4, 2011
  • 84.
    Harmony tune-up • It’s good to question the process as well as the product • Harmony is both conservative (consensus is hard to achieve) and path- dependent (e.g., because macro research takes time, we’re adding syntactic special forms that could be macros -- if only we had macros) mozilla 16 Tuesday, October 4, 2011
  • 85.
    Harmony tune-up • It’s good to question the process as well as the product • Harmony is both conservative (consensus is hard to achieve) and path- dependent (e.g., because macro research takes time, we’re adding syntactic special forms that could be macros -- if only we had macros) • Should we take Dart to heart, without over-reacting? I can’t wait! mozilla 16 Tuesday, October 4, 2011
  • 86.
    Harmony tune-up • It’s good to question the process as well as the product • Harmony is both conservative (consensus is hard to achieve) and path- dependent (e.g., because macro research takes time, we’re adding syntactic special forms that could be macros -- if only we had macros) • Should we take Dart to heart, without over-reacting? I can’t wait! • One idea is to prototype in SpiderMonkey and V8 some of the strawman proposals that did not make ES6 now, and see if any deserve promotion to ES6 mozilla 16 Tuesday, October 4, 2011
  • 87.
    Harmony tune-up • It’s good to question the process as well as the product • Harmony is both conservative (consensus is hard to achieve) and path- dependent (e.g., because macro research takes time, we’re adding syntactic special forms that could be macros -- if only we had macros) • Should we take Dart to heart, without over-reacting? I can’t wait! • One idea is to prototype in SpiderMonkey and V8 some of the strawman proposals that did not make ES6 now, and see if any deserve promotion to ES6 • Prototyping is hard. We could use help from the community... mozilla 16 Tuesday, October 4, 2011
  • 88.
    Good news tonight mozilla 17 Tuesday, October 4, 2011
  • 89.
    Good news tonight • ES6 is being drafted mozilla 17 Tuesday, October 4, 2011
  • 90.
    Good news tonight • ES6 is being drafted • It contains lots of awesome already mozilla 17 Tuesday, October 4, 2011
  • 91.
    Good news tonight • ES6 is being drafted • It contains lots of awesome already • Prototyping in SpiderMonkey and V8 is ongoing, so we’ll actually implementor- and user-test before finalizing the spec mozilla 17 Tuesday, October 4, 2011
  • 92.
    Good news tonight • ES6 is being drafted • It contains lots of awesome already • Prototyping in SpiderMonkey and V8 is ongoing, so we’ll actually implementor- and user-test before finalizing the spec • Even if we cut a few things -- still awesome mozilla 17 Tuesday, October 4, 2011
  • 93.
    Good news tonight • ES6 is being drafted • It contains lots of awesome already • Prototyping in SpiderMonkey and V8 is ongoing, so we’ll actually implementor- and user-test before finalizing the spec • Even if we cut a few things -- still awesome • Help us find the prettiest and most usable syntax mozilla 17 Tuesday, October 4, 2011
  • 94.
    Help us, pretty/usablesyntax pony-corn! mozilla 18 Tuesday, October 4, 2011
  • 95.
    RiverTrail: Parallel JS mozilla 19 Tuesday, October 4, 2011
  • 96.
    RiverTrail: Parallel JS • A ParallelArray library, like typed arrays but immutable. mozilla 19 Tuesday, October 4, 2011
  • 97.
    RiverTrail: Parallel JS • A ParallelArray library, like typed arrays but immutable. • map, reduce, combine, filter, partition, scan, scatter -- all produce fresh ParallelArray results mozilla 19 Tuesday, October 4, 2011
  • 98.
    RiverTrail: Parallel JS • A ParallelArray library, like typed arrays but immutable. • map, reduce, combine, filter, partition, scan, scatter -- all produce fresh ParallelArray results • Relies on associativity to parallelize arithmetic operations (this does inject some f.p. non-determinism). mozilla 19 Tuesday, October 4, 2011
  • 99.
    RiverTrail: Parallel JS • A ParallelArray library, like typed arrays but immutable. • map, reduce, combine, filter, partition, scan, scatter -- all produce fresh ParallelArray results • Relies on associativity to parallelize arithmetic operations (this does inject some f.p. non-determinism). • A Firefox add-on that runs a Narcissus-based JS-to-OpenCL compiler over ParallelArray code mozilla 19 Tuesday, October 4, 2011
  • 100.
    RiverTrail: Parallel JS • A ParallelArray library, like typed arrays but immutable. • map, reduce, combine, filter, partition, scan, scatter -- all produce fresh ParallelArray results • Relies on associativity to parallelize arithmetic operations (this does inject some f.p. non-determinism). • A Firefox add-on that runs a Narcissus-based JS-to-OpenCL compiler over ParallelArray code • Source: github.com/RiverTrail/RiverTrail (user id should’ve been IntelLabs) mozilla 19 Tuesday, October 4, 2011
  • 101.
    RiverTrail: Parallel JS • A ParallelArray library, like typed arrays but immutable. • map, reduce, combine, filter, partition, scan, scatter -- all produce fresh ParallelArray results • Relies on associativity to parallelize arithmetic operations (this does inject some f.p. non-determinism). • A Firefox add-on that runs a Narcissus-based JS-to-OpenCL compiler over ParallelArray code • Source: github.com/RiverTrail/RiverTrail (user id should’ve been IntelLabs) • Demo code is funny: it contains a "DO NOT use strict”; directive! mozilla 19 Tuesday, October 4, 2011
  • 102.
    RiverTrail demo samplecode • the ParallelArray constructor builds on typed arrays: NBody.private.initVel = new Array(numBodies); NBody.private.initVelTA = new Float32Array(numBodies * 4); var initAsteroidPos = new Array(50); for (i = 0; i < 50; i++) {     initAsteroidPos[i] = new ParallelArray([                                             NBody.private.posTA[i * 3 + 0],     // x                                             NBody.private.posTA[i * 3 + 1],                                             NBody.private.posTA[i * 3 + 2],                                             ]); }   . . . NBody.private.asteroidPos = new ParallelArray(Float32Array, initAsteroidPos);   . . . NBody.private.vel = new ParallelArray(Float32Array, NBody.private.initVel); mozilla 20 Tuesday, October 4, 2011
  • 103.
    ParallelArray methods inaction • combine method is a workhorse (takes variable number of args) "animateTickParallel": function animateTickParallel() {     // increment (+=) velocity by acceleration     var newVel = NBody.private.vel.combine(                  1,                      low_precision(NBody.bodyVelocityLoopified),                      NBody.private.pos,                      numBodies,                      NBody.Constant.deltaTime,                      NBody.Constant.epsSqr,                      NBody.time,                      NBody.private.asteroidPos                  );   . . . mozilla 21 Tuesday, October 4, 2011
  • 104.
    Always bet onJS Tuesday, October 4, 2011
  • 105.
    Always bet onJS • First they said JS couldn’t be useful for building “rich Internet apps” Tuesday, October 4, 2011
  • 106.
    Always bet onJS • First they said JS couldn’t be useful for building “rich Internet apps” • Then they said it couldn’t be fast Tuesday, October 4, 2011
  • 107.
    Always bet onJS • First they said JS couldn’t be useful for building “rich Internet apps” • Then they said it couldn’t be fast • Then they said it couldn’t be fixed Tuesday, October 4, 2011
  • 108.
    Always bet onJS • First they said JS couldn’t be useful for building “rich Internet apps” • Then they said it couldn’t be fast • Then they said it couldn’t be fixed • Then it couldn’t do multicore/GPU Tuesday, October 4, 2011
  • 109.
    Always bet onJS • First they said JS couldn’t be useful for building “rich Internet apps” • Then they said it couldn’t be fast • Then they said it couldn’t be fixed • Then it couldn’t do multicore/GPU • Wrong every time! Tuesday, October 4, 2011
  • 110.
    Always bet onJS • First they said JS couldn’t be useful for building “rich Internet apps” • Then they said it couldn’t be fast • Then they said it couldn’t be fixed • Then it couldn’t do multicore/GPU • Wrong every time! • My advice: always bet on JS Tuesday, October 4, 2011
  • 111.
    Q&A • @BrendanEich on twitter • brendan@mozilla.org • es-discuss@mozilla.org mozilla 23 Tuesday, October 4, 2011