Capitol js

Brendan Eich
Brendan EichCEO/President, Brave Software, Inc. at Brave Software, Inc.
••
Capital^H^HolJS brendan@mozilla.org Sunday, September 18, 2011
Capital^H^HolJS brendan@mozilla.org • History, goals Sunday, September 18, 2011
Capital^H^HolJS brendan@mozilla.org • History, goals • ES6, what’s in it? Sunday, September 18, 2011
Capital^H^HolJS brendan@mozilla.org • History, goals • ES6, what’s in it? • Dart: I can’t wait! Sunday, September 18, 2011
Capital^H^HolJS brendan@mozilla.org • History, goals • ES6, what’s in it? • Dart: I can’t wait! • Harmony tune-up Sunday, September 18, 2011
Capital^H^HolJS brendan@mozilla.org • History, goals • ES6, what’s in it? • Dart: I can’t wait! • Harmony tune-up • RiverTrail demo Sunday, September 18, 2011
A very brief history mozilla 2 Sunday, September 18, 2011
A very brief history • Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java mozilla 2 Sunday, September 18, 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 Sunday, September 18, 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 Sunday, September 18, 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 Sunday, September 18, 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 Sunday, September 18, 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 Sunday, September 18, 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 Sunday, September 18, 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 Sunday, September 18, 2011
The Harmony goals mozilla 3 Sunday, September 18, 2011
The Harmony goals • Be a better language for writing: mozilla 3 Sunday, September 18, 2011
The Harmony goals • Be a better language for writing: • complex applications mozilla 3 Sunday, September 18, 2011
The Harmony goals • Be a better language for writing: • complex applications • libraries (including the DOM) shared by those applications mozilla 3 Sunday, September 18, 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 Sunday, September 18, 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 Sunday, September 18, 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 Sunday, September 18, 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 Sunday, September 18, 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 secure subset mozilla 3 Sunday, September 18, 2011
Approved for ES6 mozilla 4 Sunday, September 18, 2011
Approved for ES6 • let, const, function in block scope mozilla 4 Sunday, September 18, 2011
Approved for ES6 • let, const, function in block scope • destructuring: let {x, y} = pt; let [s, v, o] = triple() mozilla 4 Sunday, September 18, 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=0) {...} mozilla 4 Sunday, September 18, 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=0) {...} • 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 Sunday, September 18, 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=0) {...} • 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 Sunday, September 18, 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=0) {...} • 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 Sunday, September 18, 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=0) {...} • 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 Sunday, September 18, 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=0) {...} • 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 [a+b for a of A for b of B] 4 Sunday, September 18, 2011
Yet more approved for ES6 mozilla 5 Sunday, September 18, 2011
Yet more approved for ES6 • Binary data: mozilla 5 Sunday, September 18, 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 Sunday, September 18, 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 Sunday, September 18, 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 Sunday, September 18, 2011
Quasi-Literals mozilla 6 Sunday, September 18, 2011
Quasi-Literals • Injection-safer string interpolation and domain-specific languages mozilla 6 Sunday, September 18, 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 Sunday, September 18, 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 Sunday, September 18, 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"], unescaped: ["literalPart1", "literalPart1"]}, substitution) mozilla 6 Sunday, September 18, 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"], unescaped: ["literalPart1", "literalPart1"]}, substitution) • Multiline string literals w/o prefix: `literalPart1${substitution} (yes, that was a newline!) literalPart2` mozilla 6 Sunday, September 18, 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"], unescaped: ["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 Sunday, September 18, 2011
Classes made it, barely (Yay, I think? Why am I sad?) mozilla 7 Sunday, September 18, 2011
Classes made it, barely (Yay, I think? Why am I sad?) • Sugar for prototypal object pattern, also supports closure patterns: mozilla 7 Sunday, September 18, 2011
Classes made it, barely (Yay, I think? Why am I sad?) • Sugar for prototypal object pattern, also supports closure patterns: • class Point { constructor(x, y) { private x = x, y = y; public closed_r() { return Math.sqrt(x*x + y*y); } } get x() { return @x; } get y() { return @y; } equals(p) { return @x === p@x && @y === p@y; } proto_r() { return Math.sqrt(@x * @x + @y * @y); } } mozilla 7 Sunday, September 18, 2011
Classes made it, barely (Yay, I think? Why am I sad?) • Sugar for prototypal object pattern, also supports closure patterns: • class Point { constructor(x, y) { private x = x, y = y; public closed_r() { return Math.sqrt(x*x + y*y); } } get x() { return @x; } get y() { return @y; } equals(p) { return @x === p@x && @y === p@y; } proto_r() { return Math.sqrt(@x * @x + @y * @y); } } • Private member reference syntax (@x, p@x) still up in the air... mozilla 7 Sunday, September 18, 2011
Classes made it, barely (Yay, I think? Why am I sad?) • Sugar for prototypal object pattern, also supports closure patterns: • class Point { constructor(x, y) { private x = x, y = y; public closed_r() { return Math.sqrt(x*x + y*y); } } get x() { return @x; } get y() { return @y; } equals(p) { return @x === p@x && @y === p@y; } proto_r() { return Math.sqrt(@x * @x + @y * @y); } } • Private member reference syntax (@x, p@x) still up in the air... • extends, prototype, and super work the way you want mozilla 7 Sunday, September 18, 2011
Not yet in Harmony: arrow function syntax mozilla 8 Sunday, September 18, 2011
Not yet in Harmony: arrow function syntax • Arrow function syntax, instead of λ, ƒ, or # (want to save # for later) mozilla 8 Sunday, September 18, 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 8 Sunday, September 18, 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 8 Sunday, September 18, 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 8 Sunday, September 18, 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 8 Sunday, September 18, 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 8 Sunday, September 18, 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] 9 Sunday, September 18, 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 10 Sunday, September 18, 2011
Syntax, yay mozilla 11 Sunday, September 18, 2011
Syntax, yay • Do we need shorter function syntax at all? mozilla 11 Sunday, September 18, 2011
Syntax, yay • Do we need shorter function syntax at all? • Some say no. @mikeal: “I got 99 problems and JavaScript syntax ain’t one.” mozilla 11 Sunday, September 18, 2011
Syntax, yay • 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 11 Sunday, September 18, 2011
Syntax, yay • 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 11 Sunday, September 18, 2011
Syntax, yay • 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 11 Sunday, September 18, 2011
Syntax, yay • 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 11 Sunday, September 18, 2011
Dart to the heart Sunday, September 18, 2011
Dart to the heart • Some things I’ve heard & read Sunday, September 18, 2011
Dart to the heart • Some things I’ve heard & read • “If JavaScript does not have {classes, “guards”}, then it will be REPLACED!” [May 2010 TC39 meeting] Sunday, September 18, 2011
Dart to the heart • Some things I’ve heard & read • “If JavaScript does not have {classes, “guards”}, then it will be REPLACED!” [May 2010 TC39 meeting] • “better performance profile” Sunday, September 18, 2011
Dart to the heart • Some things I’ve heard & read • “If JavaScript does not have {classes, “guards”}, then it will be REPLACED!” [May 2010 TC39 meeting] • “better performance profile” • “amenable to tooling”, “(e.g. with optional types)” Sunday, September 18, 2011
Dart to the heart • Some things I’ve heard & read • “If JavaScript does not have {classes, “guards”}, then it will be REPLACED!” [May 2010 TC39 meeting] • “better performance profile” • “amenable to tooling”, “(e.g. with optional types)” • “Fundamental problems [like the] single Number primitive....” Sunday, September 18, 2011
iOS, lolwut? mozilla 13 Sunday, September 18, 2011
iOS, lolwut? • Leaked memo: “The emergence of compelling alternative platforms like iOS has meant that the web platform must compete on its merits, not just its reach.” mozilla 13 Sunday, September 18, 2011
iOS, lolwut? • Leaked memo: “The emergence of compelling alternative platforms like iOS has meant that the web platform must compete on its merits, not just its reach.” • m-k-s on Hacker News: “If they think per the leaked mail that devs are choosing iOS over browsers because of JS, they have their heads in the sand. Those choices are happening due to iOS as a platform not because devs are somehow so much more happier learning/using Objective-C! The best thing that Google could do is to KEEP working hard on improving the browser platform.” mozilla 13 Sunday, September 18, 2011
Food for thought mozilla 14 Sunday, September 18, 2011
Food for thought • The “REPLACED” threat and “optional types” suggest either mozilla 14 Sunday, September 18, 2011
Food for thought • The “REPLACED” threat and “optional types” suggest either • Optional static types a la Strongtalk [Bracha & Griswold] mozilla 14 Sunday, September 18, 2011
Food for thought • The “REPLACED” threat and “optional types” suggest either • Optional static types a la Strongtalk [Bracha & Griswold] • Optional runtime guards, as proposed for Harmony but not in ES6 mozilla 14 Sunday, September 18, 2011
Food for thought • The “REPLACED” threat and “optional types” suggest either • Optional static types a la Strongtalk [Bracha & Griswold] • Optional runtime guards, as proposed for Harmony but not in ES6 • Syntax: let i :: int = 0; function f(a :: G)... mozilla 14 Sunday, September 18, 2011
Food for thought • The “REPLACED” threat and “optional types” suggest either • Optional static types a la Strongtalk [Bracha & Griswold] • Optional runtime guards, as proposed for Harmony but not in ES6 • Syntax: let i :: int = 0; function f(a :: G)... • Semantics are runtime-pluggable, tie into trademarks proposal (nominal) mozilla 14 Sunday, September 18, 2011
Food for thought • The “REPLACED” threat and “optional types” suggest either • Optional static types a la Strongtalk [Bracha & Griswold] • Optional runtime guards, as proposed for Harmony but not in ES6 • Syntax: let i :: int = 0; function f(a :: G)... • Semantics are runtime-pluggable, tie into trademarks proposal (nominal) • Proposals came at last minute (May TC39 meeting), not ready for ES6 mozilla 14 Sunday, September 18, 2011
Food for thought • The “REPLACED” threat and “optional types” suggest either • Optional static types a la Strongtalk [Bracha & Griswold] • Optional runtime guards, as proposed for Harmony but not in ES6 • Syntax: let i :: int = 0; function f(a :: G)... • Semantics are runtime-pluggable, tie into trademarks proposal (nominal) • Proposals came at last minute (May TC39 meeting), not ready for ES6 • Why not int32, int64, bignum, as well as number (double)? mozilla 14 Sunday, September 18, 2011
The trouble with numbers mozilla 15 Sunday, September 18, 2011
The trouble with numbers • How to introduce a sane numeric tower for JS? mozilla 15 Sunday, September 18, 2011
The trouble with numbers • How to introduce a sane numeric tower for JS? • Suffixes: 4294967295u + 1 === 0u, 2147483647i + 1 === -2147483648i; // WTF! mozilla 15 Sunday, September 18, 2011
The trouble with numbers • How to introduce a sane numeric tower for JS? • Suffixes: 4294967295u + 1 === 0u, 2147483647i + 1 === -2147483648i; // WTF! • Promotion rules as in C, but with dynamic types mozilla 15 Sunday, September 18, 2011
The trouble with numbers • How to introduce a sane numeric tower for JS? • Suffixes: 4294967295u + 1 === 0u, 2147483647i + 1 === -2147483648i; // WTF! • Promotion rules as in C, but with dynamic types • This smells like trouble mozilla 15 Sunday, September 18, 2011
The trouble with numbers • How to introduce a sane numeric tower for JS? • Suffixes: 4294967295u + 1 === 0u, 2147483647i + 1 === -2147483648i; // WTF! • Promotion rules as in C, but with dynamic types • This smells like trouble • Better: use bignum arithmetic; use int arithmetic; etc. mozilla 15 Sunday, September 18, 2011
Better performance predictability mozilla 16 Sunday, September 18, 2011
Better performance predictability • JS engines currently have performance predictability problems, it’s true mozilla 16 Sunday, September 18, 2011
Better performance predictability • JS engines currently have performance predictability problems, it’s true • Speculation can go wrong, fall back on slow paths mozilla 16 Sunday, September 18, 2011
Better performance predictability • JS engines currently have performance predictability problems, it’s true • Speculation can go wrong, fall back on slow paths • Array holes, prototype properties being deleted, unshadowing/fore-shadowing all hurt a bit mozilla 16 Sunday, September 18, 2011
Better performance predictability • JS engines currently have performance predictability problems, it’s true • Speculation can go wrong, fall back on slow paths • Array holes, prototype properties being deleted, unshadowing/fore-shadowing all hurt a bit • But JS engines are still improving rapidly (e.g. the SpiderMonkey Type Inference work by Brian Hackett) mozilla 16 Sunday, September 18, 2011
Better performance predictability • JS engines currently have performance predictability problems, it’s true • Speculation can go wrong, fall back on slow paths • Array holes, prototype properties being deleted, unshadowing/fore-shadowing all hurt a bit • But JS engines are still improving rapidly (e.g. the SpiderMonkey Type Inference work by Brian Hackett) • It’s way too soon to throw in the towel mozilla 16 Sunday, September 18, 2011
Better performance predictability • JS engines currently have performance predictability problems, it’s true • Speculation can go wrong, fall back on slow paths • Array holes, prototype properties being deleted, unshadowing/fore-shadowing all hurt a bit • But JS engines are still improving rapidly (e.g. the SpiderMonkey Type Inference work by Brian Hackett) • It’s way too soon to throw in the towel • We could add more opt-into-high-performance knobs, but: No. mozilla 16 Sunday, September 18, 2011
Harmony tune-up mozilla 17 Sunday, September 18, 2011
Harmony tune-up • It’s good to question the process mozilla 17 Sunday, September 18, 2011
Harmony tune-up • It’s good to question the process • Harmony is both conservative (consensus is hard to achieve) and path- dependent (because macro research takes time, we’re adding syntactic special forms that could be macros -- if only we had macros) mozilla 17 Sunday, September 18, 2011
Harmony tune-up • It’s good to question the process • Harmony is both conservative (consensus is hard to achieve) and path- dependent (because macro research takes time, we’re adding syntactic special forms that could be macros -- if only we had macros) • Should we take the Dart clues to heart, without over-reacting? mozilla 17 Sunday, September 18, 2011
Harmony tune-up • It’s good to question the process • Harmony is both conservative (consensus is hard to achieve) and path- dependent (because macro research takes time, we’re adding syntactic special forms that could be macros -- if only we had macros) • Should we take the Dart clues to heart, without over-reacting? • My suggestion 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 17 Sunday, September 18, 2011
RiverTrail: Parallel JS mozilla 18 Sunday, September 18, 2011
RiverTrail: Parallel JS • A ParallelArray library, like typed arrays but immutable. mozilla 18 Sunday, September 18, 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 18 Sunday, September 18, 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 commutativity to parallelize arithmetic operations (this does inject some f.p. non-determinism). mozilla 18 Sunday, September 18, 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 commutativity 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 18 Sunday, September 18, 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 commutativity 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 18 Sunday, September 18, 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 commutativity 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 18 Sunday, September 18, 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 19 Sunday, September 18, 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 20 Sunday, September 18, 2011
Always bet on JS Sunday, September 18, 2011
Always bet on JS • First they said JS couldn’t be useful for buildling “rich Internet apps” Sunday, September 18, 2011
Always bet on JS • First they said JS couldn’t be useful for buildling “rich Internet apps” • Then they said it couldn’t be fast Sunday, September 18, 2011
Always bet on JS • First they said JS couldn’t be useful for buildling “rich Internet apps” • Then they said it couldn’t be fast • Then they said it couldn’t be fixed Sunday, September 18, 2011
Always bet on JS • First they said JS couldn’t be useful for buildling “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 Sunday, September 18, 2011
Always bet on JS • First they said JS couldn’t be useful for buildling “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! Sunday, September 18, 2011
Always bet on JS • First they said JS couldn’t be useful for buildling “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 Sunday, September 18, 2011
Q&A • @BrendanEich on twitter • brendan@mozilla.org • es-discuss@mozilla.org mozilla 22 Sunday, September 18, 2011
1 of 118

Capitol js

••
Download to read offline
TechnologyNews & Politics

My CapitolJS 2011 talk. Firefox add-on source for the Parallel JS demo: http://github.com/RiverTrail/RiverTrail

Brendan Eich
Brendan EichCEO/President, Brave Software, Inc. at Brave Software, Inc.

Recommended

JSLOL by
JSLOLJSLOL
JSLOLBrendan Eich
15.4K views•111 slides
Txjs talk by
Txjs talkTxjs talk
Txjs talkBrendan Eich
2.8K views•75 slides
ES.next by
ES.nextES.next
ES.nextBrendan Eich
5.1K views•53 slides
MSR Talk by
MSR TalkMSR Talk
MSR TalkBrendan Eich
2.4K views•97 slides
Building Languages for the JVM - StarTechConf 2011 by
Building Languages for the JVM - StarTechConf 2011Building Languages for the JVM - StarTechConf 2011
Building Languages for the JVM - StarTechConf 2011Charles Nutter
1.6K views•64 slides
Splash by
SplashSplash
SplashBrendan Eich
6.9K views•52 slides

More Related Content

Viewers also liked

Paren free by
Paren freeParen free
Paren freeBrendan Eich
2.3K views•25 slides
Web futures by
Web futuresWeb futures
Web futuresBrendan Eich
8.7K views•40 slides
Mozilla's NodeConf talk by
Mozilla's NodeConf talkMozilla's NodeConf talk
Mozilla's NodeConf talkBrendan Eich
3.1K views•40 slides
Fluent14 by
Fluent14Fluent14
Fluent14Brendan Eich
8.9K views•40 slides
Taysom seminar by
Taysom seminarTaysom seminar
Taysom seminarBrendan Eich
7.5K views•7 slides
Fluent15 by
Fluent15Fluent15
Fluent15Brendan Eich
8.1K views•15 slides

Viewers also liked(16)

Paren free by Brendan Eich
Paren freeParen free
Paren free
Brendan Eich•2.3K views
Web futures by Brendan Eich
Web futuresWeb futures
Web futures
Brendan Eich•8.7K views
Mozilla's NodeConf talk by Brendan Eich
Mozilla's NodeConf talkMozilla's NodeConf talk
Mozilla's NodeConf talk
Brendan Eich•3.1K views
Fluent14 by Brendan Eich
Fluent14Fluent14
Fluent14
Brendan Eich•8.9K views
Taysom seminar by Brendan Eich
Taysom seminarTaysom seminar
Taysom seminar
Brendan Eich•7.5K views
Fluent15 by Brendan Eich
Fluent15Fluent15
Fluent15
Brendan Eich•8.1K views
My dotJS Talk by Brendan Eich
My dotJS TalkMy dotJS Talk
My dotJS Talk
Brendan Eich•10.6K views
JS Responsibilities by Brendan Eich
JS ResponsibilitiesJS Responsibilities
JS Responsibilities
Brendan Eich•34.9K views
Mozilla Research Party Talk by Brendan Eich
Mozilla Research Party TalkMozilla Research Party Talk
Mozilla Research Party Talk
Brendan Eich•3.1K views
dotJS 2015 by Brendan Eich
dotJS 2015dotJS 2015
dotJS 2015
Brendan Eich•5.3K views
Always bet on JS - Finjs.io NYC 2016 by Brendan Eich
Always bet on JS - Finjs.io NYC 2016Always bet on JS - Finjs.io NYC 2016
Always bet on JS - Finjs.io NYC 2016
Brendan Eich•1.9K views
Extensible Operators and Literals for JavaScript by Brendan Eich
Extensible Operators and Literals for JavaScriptExtensible Operators and Literals for JavaScript
Extensible Operators and Literals for JavaScript
Brendan Eich•6.8K views
Value Objects, Full Throttle (to be updated for spring TC39 meetings) by Brendan Eich
Value Objects, Full Throttle (to be updated for spring TC39 meetings)Value Objects, Full Throttle (to be updated for spring TC39 meetings)
Value Objects, Full Throttle (to be updated for spring TC39 meetings)
Brendan Eich•16K views
Value objects in JS - an ES7 work in progress by Brendan Eich
Value objects in JS - an ES7 work in progressValue objects in JS - an ES7 work in progress
Value objects in JS - an ES7 work in progress
Brendan Eich•22.7K views
The Same-Origin Saga by Brendan Eich
The Same-Origin SagaThe Same-Origin Saga
The Same-Origin Saga
Brendan Eich•2.9K views
Int64 by Brendan Eich
Int64Int64
Int64
Brendan Eich•12.8K views

Similar to Capitol js

Re-Introduction to Third-party Scripting by
Re-Introduction to Third-party ScriptingRe-Introduction to Third-party Scripting
Re-Introduction to Third-party Scriptingbenvinegar
1.7K views•58 slides
A Re-Introduction to Third-Party Scripting by
A Re-Introduction to Third-Party ScriptingA Re-Introduction to Third-Party Scripting
A Re-Introduction to Third-Party Scriptingbenvinegar
6.4K views•58 slides
Nodes Cck And Panels by
Nodes Cck And PanelsNodes Cck And Panels
Nodes Cck And Panelsjskulski
936 views•20 slides
Future Tense by
Future TenseFuture Tense
Future TenseBrendan Eich
10.2K views•32 slides
Go - The Power Of Simplicity by
Go - The Power Of SimplicityGo - The Power Of Simplicity
Go - The Power Of SimplicityEduardo Nunes Pereira
347 views•27 slides
Porting E-poetry: The Case of First Screening by
Porting E-poetry: The Case of First ScreeningPorting E-poetry: The Case of First Screening
Porting E-poetry: The Case of First ScreeningLeonardo Flores
793 views•20 slides

Similar to Capitol js(20)

Re-Introduction to Third-party Scripting by benvinegar
Re-Introduction to Third-party ScriptingRe-Introduction to Third-party Scripting
Re-Introduction to Third-party Scripting
benvinegar•1.7K views
A Re-Introduction to Third-Party Scripting by benvinegar
A Re-Introduction to Third-Party ScriptingA Re-Introduction to Third-Party Scripting
A Re-Introduction to Third-Party Scripting
benvinegar•6.4K views
Nodes Cck And Panels by jskulski
Nodes Cck And PanelsNodes Cck And Panels
Nodes Cck And Panels
jskulski•936 views
Future Tense by Brendan Eich
Future TenseFuture Tense
Future Tense
Brendan Eich•10.2K views
Go - The Power Of Simplicity by Eduardo Nunes Pereira
Go - The Power Of SimplicityGo - The Power Of Simplicity
Go - The Power Of Simplicity
Eduardo Nunes Pereira•347 views
Porting E-poetry: The Case of First Screening by Leonardo Flores
Porting E-poetry: The Case of First ScreeningPorting E-poetry: The Case of First Screening
Porting E-poetry: The Case of First Screening
Leonardo Flores•793 views
Rust 101 (2017 edition) by Robert 'Bob' Reyes
Rust 101 (2017 edition)Rust 101 (2017 edition)
Rust 101 (2017 edition)
Robert 'Bob' Reyes•389 views
Introduction to Cross Platform Development with Xamarin/ Visual Studio by IndyMobileNetDev
Introduction to Cross Platform Development with Xamarin/ Visual StudioIntroduction to Cross Platform Development with Xamarin/ Visual Studio
Introduction to Cross Platform Development with Xamarin/ Visual Studio
IndyMobileNetDev•2.8K views
Introduction to Go by zhubert
Introduction to GoIntroduction to Go
Introduction to Go
zhubert•623 views
NoTube User Model slides by Dan Brickley
NoTube User Model slidesNoTube User Model slides
NoTube User Model slides
Dan Brickley•7.1K views
"The Past Present and Future of the Mozilla Foundation" by Zak Greant @ eLibe... by eLiberatica
"The Past Present and Future of the Mozilla Foundation" by Zak Greant @ eLibe..."The Past Present and Future of the Mozilla Foundation" by Zak Greant @ eLibe...
"The Past Present and Future of the Mozilla Foundation" by Zak Greant @ eLibe...
eLiberatica•685 views
Forking Successfully - or is a branch better? by Colin Charles
Forking Successfully - or is a branch better?Forking Successfully - or is a branch better?
Forking Successfully - or is a branch better?
Colin Charles•1.4K views
Web application development - The past, the present, the future by Juho Vepsäläinen
Web application development - The past, the present, the futureWeb application development - The past, the present, the future
Web application development - The past, the present, the future
Juho Vepsäläinen•395 views
2016 bioinformatics i_python_part_1_wim_vancriekinge by Prof. Wim Van Criekinge
2016 bioinformatics i_python_part_1_wim_vancriekinge2016 bioinformatics i_python_part_1_wim_vancriekinge
2016 bioinformatics i_python_part_1_wim_vancriekinge
Prof. Wim Van Criekinge•1.8K views
Monorepo at Pinterest by Suman Karumuri
Monorepo at PinterestMonorepo at Pinterest
Monorepo at Pinterest
Suman Karumuri•819 views
Webinar Mobile ECM Apps with Nuxeo EP by Nuxeo
Webinar Mobile ECM Apps with Nuxeo EPWebinar Mobile ECM Apps with Nuxeo EP
Webinar Mobile ECM Apps with Nuxeo EP
Nuxeo•606 views
I phone udvikling best brains by Ove larsen
I phone udvikling best brainsI phone udvikling best brains
I phone udvikling best brains
Ove larsen•467 views
5 Realms for Learning iOS Development by irving-ios-jumpstart
5 Realms for Learning iOS Development5 Realms for Learning iOS Development
5 Realms for Learning iOS Development
irving-ios-jumpstart•865 views
MiningTheSocialWeb.Ch2.Microformat by HyeonSeok Choi
MiningTheSocialWeb.Ch2.MicroformatMiningTheSocialWeb.Ch2.Microformat
MiningTheSocialWeb.Ch2.Microformat
HyeonSeok Choi•327 views
Symfony Day 2009 - Symfony vs Integrating products by Xavier Lacot
Symfony Day 2009 - Symfony vs Integrating productsSymfony Day 2009 - Symfony vs Integrating products
Symfony Day 2009 - Symfony vs Integrating products
Xavier Lacot•1.4K views

Recently uploaded

NTGapps NTG LowCode Platform by
NTGapps NTG LowCode Platform NTGapps NTG LowCode Platform
NTGapps NTG LowCode Platform Mustafa Kuğu
437 views•30 slides
Netmera Presentation.pdf by
Netmera Presentation.pdfNetmera Presentation.pdf
Netmera Presentation.pdfMustafa Kuğu
22 views•50 slides
Inawisdom IDP by
Inawisdom IDPInawisdom IDP
Inawisdom IDPPhilipBasford
15 views•48 slides
"Package management in monorepos", Zoltan Kochan by
"Package management in monorepos", Zoltan Kochan"Package management in monorepos", Zoltan Kochan
"Package management in monorepos", Zoltan KochanFwdays
34 views•18 slides
Discover Aura Workshop (12.5.23).pdf by
Discover Aura Workshop (12.5.23).pdfDiscover Aura Workshop (12.5.23).pdf
Discover Aura Workshop (12.5.23).pdfNeo4j
15 views•55 slides
Innovation & Entrepreneurship strategies in Dairy Industry by
Innovation & Entrepreneurship strategies in Dairy IndustryInnovation & Entrepreneurship strategies in Dairy Industry
Innovation & Entrepreneurship strategies in Dairy IndustryPervaizDar1
35 views•26 slides

Recently uploaded(20)

NTGapps NTG LowCode Platform by Mustafa Kuğu
NTGapps NTG LowCode Platform NTGapps NTG LowCode Platform
NTGapps NTG LowCode Platform
Mustafa Kuğu•437 views
Netmera Presentation.pdf by Mustafa Kuğu
Netmera Presentation.pdfNetmera Presentation.pdf
Netmera Presentation.pdf
Mustafa Kuğu•22 views
Inawisdom IDP by PhilipBasford
Inawisdom IDPInawisdom IDP
Inawisdom IDP
PhilipBasford•15 views
"Package management in monorepos", Zoltan Kochan by Fwdays
"Package management in monorepos", Zoltan Kochan"Package management in monorepos", Zoltan Kochan
"Package management in monorepos", Zoltan Kochan
Fwdays•34 views
Discover Aura Workshop (12.5.23).pdf by Neo4j
Discover Aura Workshop (12.5.23).pdfDiscover Aura Workshop (12.5.23).pdf
Discover Aura Workshop (12.5.23).pdf
Neo4j•15 views
Innovation & Entrepreneurship strategies in Dairy Industry by PervaizDar1
Innovation & Entrepreneurship strategies in Dairy IndustryInnovation & Entrepreneurship strategies in Dairy Industry
Innovation & Entrepreneurship strategies in Dairy Industry
PervaizDar1•35 views
Optimizing Communication to Optimize Human Behavior - LCBM by Yaman Kumar
Optimizing Communication to Optimize Human Behavior - LCBMOptimizing Communication to Optimize Human Behavior - LCBM
Optimizing Communication to Optimize Human Behavior - LCBM
Yaman Kumar•38 views
Measurecamp Brussels - Synthetic data.pdf by Human37
Measurecamp Brussels - Synthetic data.pdfMeasurecamp Brussels - Synthetic data.pdf
Measurecamp Brussels - Synthetic data.pdf
Human37 •26 views
"Surviving highload with Node.js", Andrii Shumada by Fwdays
"Surviving highload with Node.js", Andrii Shumada "Surviving highload with Node.js", Andrii Shumada
"Surviving highload with Node.js", Andrii Shumada
Fwdays•58 views
This talk was not generated with ChatGPT: how AI is changing science by Elena Simperl
This talk was not generated with ChatGPT: how AI is changing scienceThis talk was not generated with ChatGPT: how AI is changing science
This talk was not generated with ChatGPT: how AI is changing science
Elena Simperl•32 views
Evaluation of Quality of Experience of ABR Schemes in Gaming Stream by Alpen-Adria-Universität
Evaluation of Quality of Experience of ABR Schemes in Gaming StreamEvaluation of Quality of Experience of ABR Schemes in Gaming Stream
Evaluation of Quality of Experience of ABR Schemes in Gaming Stream
Alpen-Adria-Universität•38 views
Webinar : Desperately Seeking Transformation - Part 2: Insights from leading... by The Digital Insurer
Webinar : Desperately Seeking Transformation - Part 2: Insights from leading...Webinar : Desperately Seeking Transformation - Part 2: Insights from leading...
Webinar : Desperately Seeking Transformation - Part 2: Insights from leading...
The Digital Insurer•91 views
AI + Memoori = AIM by Memoori
AI + Memoori = AIMAI + Memoori = AIM
AI + Memoori = AIM
Memoori•14 views
GDSC GLAU Info Session.pptx by gauriverrma4
GDSC GLAU Info Session.pptxGDSC GLAU Info Session.pptx
GDSC GLAU Info Session.pptx
gauriverrma4•15 views
What is Authentication Active Directory_.pptx by HeenaMehta35
What is Authentication Active Directory_.pptxWhat is Authentication Active Directory_.pptx
What is Authentication Active Directory_.pptx
HeenaMehta35•15 views
"Running students' code in isolation. The hard way", Yurii Holiuk by Fwdays
"Running students' code in isolation. The hard way", Yurii Holiuk "Running students' code in isolation. The hard way", Yurii Holiuk
"Running students' code in isolation. The hard way", Yurii Holiuk
Fwdays•36 views
Redefining the book supply chain: A glimpse into the future - Tech Forum 2023 by BookNet Canada
Redefining the book supply chain: A glimpse into the future - Tech Forum 2023Redefining the book supply chain: A glimpse into the future - Tech Forum 2023
Redefining the book supply chain: A glimpse into the future - Tech Forum 2023
BookNet Canada•44 views
Business Analyst Series 2023 - Week 4 Session 7 by DianaGray10
Business Analyst Series 2023 - Week 4 Session 7Business Analyst Series 2023 - Week 4 Session 7
Business Analyst Series 2023 - Week 4 Session 7
DianaGray10•146 views
Cocktail of Environments. How to Mix Test and Development Environments and St... by Aleksandr Tarasov
Cocktail of Environments. How to Mix Test and Development Environments and St...Cocktail of Environments. How to Mix Test and Development Environments and St...
Cocktail of Environments. How to Mix Test and Development Environments and St...
Aleksandr Tarasov•23 views
The Power of Generative AI in Accelerating No Code Adoption.pdf by Saeed Al Dhaheri
The Power of Generative AI in Accelerating No Code Adoption.pdfThe Power of Generative AI in Accelerating No Code Adoption.pdf
The Power of Generative AI in Accelerating No Code Adoption.pdf
Saeed Al Dhaheri•39 views

Capitol js

  • 1. Capital^H^HolJS brendan@mozilla.org Sunday, September 18, 2011
  • 2. Capital^H^HolJS brendan@mozilla.org • History, goals Sunday, September 18, 2011
  • 3. Capital^H^HolJS brendan@mozilla.org • History, goals • ES6, what’s in it? Sunday, September 18, 2011
  • 4. Capital^H^HolJS brendan@mozilla.org • History, goals • ES6, what’s in it? • Dart: I can’t wait! Sunday, September 18, 2011
  • 5. Capital^H^HolJS brendan@mozilla.org • History, goals • ES6, what’s in it? • Dart: I can’t wait! • Harmony tune-up Sunday, September 18, 2011
  • 6. Capital^H^HolJS brendan@mozilla.org • History, goals • ES6, what’s in it? • Dart: I can’t wait! • Harmony tune-up • RiverTrail demo Sunday, September 18, 2011
  • 7. A very brief history mozilla 2 Sunday, September 18, 2011
  • 8. A very brief history • Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java mozilla 2 Sunday, September 18, 2011
  • 9. 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 Sunday, September 18, 2011
  • 10. 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 Sunday, September 18, 2011
  • 11. 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 Sunday, September 18, 2011
  • 12. 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 Sunday, September 18, 2011
  • 13. 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 Sunday, September 18, 2011
  • 14. 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 Sunday, September 18, 2011
  • 15. 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 Sunday, September 18, 2011
  • 16. The Harmony goals mozilla 3 Sunday, September 18, 2011
  • 17. The Harmony goals • Be a better language for writing: mozilla 3 Sunday, September 18, 2011
  • 18. The Harmony goals • Be a better language for writing: • complex applications mozilla 3 Sunday, September 18, 2011
  • 19. The Harmony goals • Be a better language for writing: • complex applications • libraries (including the DOM) shared by those applications mozilla 3 Sunday, September 18, 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 Sunday, September 18, 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 Sunday, September 18, 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 Sunday, September 18, 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 Sunday, September 18, 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 secure subset mozilla 3 Sunday, September 18, 2011
  • 25. Approved for ES6 mozilla 4 Sunday, September 18, 2011
  • 26. Approved for ES6 • let, const, function in block scope mozilla 4 Sunday, September 18, 2011
  • 27. Approved for ES6 • let, const, function in block scope • destructuring: let {x, y} = pt; let [s, v, o] = triple() mozilla 4 Sunday, September 18, 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=0) {...} mozilla 4 Sunday, September 18, 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=0) {...} • 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 Sunday, September 18, 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=0) {...} • 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 Sunday, September 18, 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=0) {...} • 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 Sunday, September 18, 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=0) {...} • 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 Sunday, September 18, 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=0) {...} • 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 [a+b for a of A for b of B] 4 Sunday, September 18, 2011
  • 34. Yet more approved for ES6 mozilla 5 Sunday, September 18, 2011
  • 35. Yet more approved for ES6 • Binary data: mozilla 5 Sunday, September 18, 2011
  • 36. 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 Sunday, September 18, 2011
  • 37. 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 Sunday, September 18, 2011
  • 38. 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 Sunday, September 18, 2011
  • 39. Quasi-Literals mozilla 6 Sunday, September 18, 2011
  • 40. Quasi-Literals • Injection-safer string interpolation and domain-specific languages mozilla 6 Sunday, September 18, 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 Sunday, September 18, 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 Sunday, September 18, 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"], unescaped: ["literalPart1", "literalPart1"]}, substitution) mozilla 6 Sunday, September 18, 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"], unescaped: ["literalPart1", "literalPart1"]}, substitution) • Multiline string literals w/o prefix: `literalPart1${substitution} (yes, that was a newline!) literalPart2` mozilla 6 Sunday, September 18, 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"], unescaped: ["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 Sunday, September 18, 2011
  • 46. Classes made it, barely (Yay, I think? Why am I sad?) mozilla 7 Sunday, September 18, 2011
  • 47. Classes made it, barely (Yay, I think? Why am I sad?) • Sugar for prototypal object pattern, also supports closure patterns: mozilla 7 Sunday, September 18, 2011
  • 48. Classes made it, barely (Yay, I think? Why am I sad?) • Sugar for prototypal object pattern, also supports closure patterns: • class Point { constructor(x, y) { private x = x, y = y; public closed_r() { return Math.sqrt(x*x + y*y); } } get x() { return @x; } get y() { return @y; } equals(p) { return @x === p@x && @y === p@y; } proto_r() { return Math.sqrt(@x * @x + @y * @y); } } mozilla 7 Sunday, September 18, 2011
  • 49. Classes made it, barely (Yay, I think? Why am I sad?) • Sugar for prototypal object pattern, also supports closure patterns: • class Point { constructor(x, y) { private x = x, y = y; public closed_r() { return Math.sqrt(x*x + y*y); } } get x() { return @x; } get y() { return @y; } equals(p) { return @x === p@x && @y === p@y; } proto_r() { return Math.sqrt(@x * @x + @y * @y); } } • Private member reference syntax (@x, p@x) still up in the air... mozilla 7 Sunday, September 18, 2011
  • 50. Classes made it, barely (Yay, I think? Why am I sad?) • Sugar for prototypal object pattern, also supports closure patterns: • class Point { constructor(x, y) { private x = x, y = y; public closed_r() { return Math.sqrt(x*x + y*y); } } get x() { return @x; } get y() { return @y; } equals(p) { return @x === p@x && @y === p@y; } proto_r() { return Math.sqrt(@x * @x + @y * @y); } } • Private member reference syntax (@x, p@x) still up in the air... • extends, prototype, and super work the way you want mozilla 7 Sunday, September 18, 2011
  • 51. Not yet in Harmony: arrow function syntax mozilla 8 Sunday, September 18, 2011
  • 52. Not yet in Harmony: arrow function syntax • Arrow function syntax, instead of λ, ƒ, or # (want to save # for later) mozilla 8 Sunday, September 18, 2011
  • 53. 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 8 Sunday, September 18, 2011
  • 54. 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 8 Sunday, September 18, 2011
  • 55. 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 8 Sunday, September 18, 2011
  • 56. 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 8 Sunday, September 18, 2011
  • 57. 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 8 Sunday, September 18, 2011
  • 58. 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] 9 Sunday, September 18, 2011
  • 59. 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 10 Sunday, September 18, 2011
  • 60. Syntax, yay mozilla 11 Sunday, September 18, 2011
  • 61. Syntax, yay • Do we need shorter function syntax at all? mozilla 11 Sunday, September 18, 2011
  • 62. Syntax, yay • Do we need shorter function syntax at all? • Some say no. @mikeal: “I got 99 problems and JavaScript syntax ain’t one.” mozilla 11 Sunday, September 18, 2011
  • 63. Syntax, yay • 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 11 Sunday, September 18, 2011
  • 64. Syntax, yay • 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 11 Sunday, September 18, 2011
  • 65. Syntax, yay • 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 11 Sunday, September 18, 2011
  • 66. Syntax, yay • 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 11 Sunday, September 18, 2011
  • 67. Dart to the heart Sunday, September 18, 2011
  • 68. Dart to the heart • Some things I’ve heard & read Sunday, September 18, 2011
  • 69. Dart to the heart • Some things I’ve heard & read • “If JavaScript does not have {classes, “guards”}, then it will be REPLACED!” [May 2010 TC39 meeting] Sunday, September 18, 2011
  • 70. Dart to the heart • Some things I’ve heard & read • “If JavaScript does not have {classes, “guards”}, then it will be REPLACED!” [May 2010 TC39 meeting] • “better performance profile” Sunday, September 18, 2011
  • 71. Dart to the heart • Some things I’ve heard & read • “If JavaScript does not have {classes, “guards”}, then it will be REPLACED!” [May 2010 TC39 meeting] • “better performance profile” • “amenable to tooling”, “(e.g. with optional types)” Sunday, September 18, 2011
  • 72. Dart to the heart • Some things I’ve heard & read • “If JavaScript does not have {classes, “guards”}, then it will be REPLACED!” [May 2010 TC39 meeting] • “better performance profile” • “amenable to tooling”, “(e.g. with optional types)” • “Fundamental problems [like the] single Number primitive....” Sunday, September 18, 2011
  • 73. iOS, lolwut? mozilla 13 Sunday, September 18, 2011
  • 74. iOS, lolwut? • Leaked memo: “The emergence of compelling alternative platforms like iOS has meant that the web platform must compete on its merits, not just its reach.” mozilla 13 Sunday, September 18, 2011
  • 75. iOS, lolwut? • Leaked memo: “The emergence of compelling alternative platforms like iOS has meant that the web platform must compete on its merits, not just its reach.” • m-k-s on Hacker News: “If they think per the leaked mail that devs are choosing iOS over browsers because of JS, they have their heads in the sand. Those choices are happening due to iOS as a platform not because devs are somehow so much more happier learning/using Objective-C! The best thing that Google could do is to KEEP working hard on improving the browser platform.” mozilla 13 Sunday, September 18, 2011
  • 76. Food for thought mozilla 14 Sunday, September 18, 2011
  • 77. Food for thought • The “REPLACED” threat and “optional types” suggest either mozilla 14 Sunday, September 18, 2011
  • 78. Food for thought • The “REPLACED” threat and “optional types” suggest either • Optional static types a la Strongtalk [Bracha & Griswold] mozilla 14 Sunday, September 18, 2011
  • 79. Food for thought • The “REPLACED” threat and “optional types” suggest either • Optional static types a la Strongtalk [Bracha & Griswold] • Optional runtime guards, as proposed for Harmony but not in ES6 mozilla 14 Sunday, September 18, 2011
  • 80. Food for thought • The “REPLACED” threat and “optional types” suggest either • Optional static types a la Strongtalk [Bracha & Griswold] • Optional runtime guards, as proposed for Harmony but not in ES6 • Syntax: let i :: int = 0; function f(a :: G)... mozilla 14 Sunday, September 18, 2011
  • 81. Food for thought • The “REPLACED” threat and “optional types” suggest either • Optional static types a la Strongtalk [Bracha & Griswold] • Optional runtime guards, as proposed for Harmony but not in ES6 • Syntax: let i :: int = 0; function f(a :: G)... • Semantics are runtime-pluggable, tie into trademarks proposal (nominal) mozilla 14 Sunday, September 18, 2011
  • 82. Food for thought • The “REPLACED” threat and “optional types” suggest either • Optional static types a la Strongtalk [Bracha & Griswold] • Optional runtime guards, as proposed for Harmony but not in ES6 • Syntax: let i :: int = 0; function f(a :: G)... • Semantics are runtime-pluggable, tie into trademarks proposal (nominal) • Proposals came at last minute (May TC39 meeting), not ready for ES6 mozilla 14 Sunday, September 18, 2011
  • 83. Food for thought • The “REPLACED” threat and “optional types” suggest either • Optional static types a la Strongtalk [Bracha & Griswold] • Optional runtime guards, as proposed for Harmony but not in ES6 • Syntax: let i :: int = 0; function f(a :: G)... • Semantics are runtime-pluggable, tie into trademarks proposal (nominal) • Proposals came at last minute (May TC39 meeting), not ready for ES6 • Why not int32, int64, bignum, as well as number (double)? mozilla 14 Sunday, September 18, 2011
  • 84. The trouble with numbers mozilla 15 Sunday, September 18, 2011
  • 85. The trouble with numbers • How to introduce a sane numeric tower for JS? mozilla 15 Sunday, September 18, 2011
  • 86. The trouble with numbers • How to introduce a sane numeric tower for JS? • Suffixes: 4294967295u + 1 === 0u, 2147483647i + 1 === -2147483648i; // WTF! mozilla 15 Sunday, September 18, 2011
  • 87. The trouble with numbers • How to introduce a sane numeric tower for JS? • Suffixes: 4294967295u + 1 === 0u, 2147483647i + 1 === -2147483648i; // WTF! • Promotion rules as in C, but with dynamic types mozilla 15 Sunday, September 18, 2011
  • 88. The trouble with numbers • How to introduce a sane numeric tower for JS? • Suffixes: 4294967295u + 1 === 0u, 2147483647i + 1 === -2147483648i; // WTF! • Promotion rules as in C, but with dynamic types • This smells like trouble mozilla 15 Sunday, September 18, 2011
  • 89. The trouble with numbers • How to introduce a sane numeric tower for JS? • Suffixes: 4294967295u + 1 === 0u, 2147483647i + 1 === -2147483648i; // WTF! • Promotion rules as in C, but with dynamic types • This smells like trouble • Better: use bignum arithmetic; use int arithmetic; etc. mozilla 15 Sunday, September 18, 2011
  • 90. Better performance predictability mozilla 16 Sunday, September 18, 2011
  • 91. Better performance predictability • JS engines currently have performance predictability problems, it’s true mozilla 16 Sunday, September 18, 2011
  • 92. Better performance predictability • JS engines currently have performance predictability problems, it’s true • Speculation can go wrong, fall back on slow paths mozilla 16 Sunday, September 18, 2011
  • 93. Better performance predictability • JS engines currently have performance predictability problems, it’s true • Speculation can go wrong, fall back on slow paths • Array holes, prototype properties being deleted, unshadowing/fore-shadowing all hurt a bit mozilla 16 Sunday, September 18, 2011
  • 94. Better performance predictability • JS engines currently have performance predictability problems, it’s true • Speculation can go wrong, fall back on slow paths • Array holes, prototype properties being deleted, unshadowing/fore-shadowing all hurt a bit • But JS engines are still improving rapidly (e.g. the SpiderMonkey Type Inference work by Brian Hackett) mozilla 16 Sunday, September 18, 2011
  • 95. Better performance predictability • JS engines currently have performance predictability problems, it’s true • Speculation can go wrong, fall back on slow paths • Array holes, prototype properties being deleted, unshadowing/fore-shadowing all hurt a bit • But JS engines are still improving rapidly (e.g. the SpiderMonkey Type Inference work by Brian Hackett) • It’s way too soon to throw in the towel mozilla 16 Sunday, September 18, 2011
  • 96. Better performance predictability • JS engines currently have performance predictability problems, it’s true • Speculation can go wrong, fall back on slow paths • Array holes, prototype properties being deleted, unshadowing/fore-shadowing all hurt a bit • But JS engines are still improving rapidly (e.g. the SpiderMonkey Type Inference work by Brian Hackett) • It’s way too soon to throw in the towel • We could add more opt-into-high-performance knobs, but: No. mozilla 16 Sunday, September 18, 2011
  • 97. Harmony tune-up mozilla 17 Sunday, September 18, 2011
  • 98. Harmony tune-up • It’s good to question the process mozilla 17 Sunday, September 18, 2011
  • 99. Harmony tune-up • It’s good to question the process • Harmony is both conservative (consensus is hard to achieve) and path- dependent (because macro research takes time, we’re adding syntactic special forms that could be macros -- if only we had macros) mozilla 17 Sunday, September 18, 2011
  • 100. Harmony tune-up • It’s good to question the process • Harmony is both conservative (consensus is hard to achieve) and path- dependent (because macro research takes time, we’re adding syntactic special forms that could be macros -- if only we had macros) • Should we take the Dart clues to heart, without over-reacting? mozilla 17 Sunday, September 18, 2011
  • 101. Harmony tune-up • It’s good to question the process • Harmony is both conservative (consensus is hard to achieve) and path- dependent (because macro research takes time, we’re adding syntactic special forms that could be macros -- if only we had macros) • Should we take the Dart clues to heart, without over-reacting? • My suggestion 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 17 Sunday, September 18, 2011
  • 102. RiverTrail: Parallel JS mozilla 18 Sunday, September 18, 2011
  • 103. RiverTrail: Parallel JS • A ParallelArray library, like typed arrays but immutable. mozilla 18 Sunday, September 18, 2011
  • 104. RiverTrail: Parallel JS • A ParallelArray library, like typed arrays but immutable. • map, reduce, combine, filter, partition, scan, scatter -- all produce fresh ParallelArray results mozilla 18 Sunday, September 18, 2011
  • 105. 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 commutativity to parallelize arithmetic operations (this does inject some f.p. non-determinism). mozilla 18 Sunday, September 18, 2011
  • 106. 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 commutativity 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 18 Sunday, September 18, 2011
  • 107. 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 commutativity 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 18 Sunday, September 18, 2011
  • 108. 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 commutativity 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 18 Sunday, September 18, 2011
  • 109. 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 19 Sunday, September 18, 2011
  • 110. 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 20 Sunday, September 18, 2011
  • 111. Always bet on JS Sunday, September 18, 2011
  • 112. Always bet on JS • First they said JS couldn’t be useful for buildling “rich Internet apps” Sunday, September 18, 2011
  • 113. Always bet on JS • First they said JS couldn’t be useful for buildling “rich Internet apps” • Then they said it couldn’t be fast Sunday, September 18, 2011
  • 114. Always bet on JS • First they said JS couldn’t be useful for buildling “rich Internet apps” • Then they said it couldn’t be fast • Then they said it couldn’t be fixed Sunday, September 18, 2011
  • 115. Always bet on JS • First they said JS couldn’t be useful for buildling “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 Sunday, September 18, 2011
  • 116. Always bet on JS • First they said JS couldn’t be useful for buildling “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! Sunday, September 18, 2011
  • 117. Always bet on JS • First they said JS couldn’t be useful for buildling “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 Sunday, September 18, 2011
  • 118. Q&A • @BrendanEich on twitter • brendan@mozilla.org • es-discuss@mozilla.org mozilla 22 Sunday, September 18, 2011