ES6 workshop

• Long time coming
  • Finished now
  • Browsers are doing serious work on implementing it
• The first big change of the language since 1999, with version 3
  • Version 4 never got agreed on
  • Version 5 was a very conservative improvement
• Backwards-compatible
  • No ES5 programs stop working
• You can compile ES6 to ES5
  • Babel
  • Polyfills
  • Cleaner, more concise code
• This workshop will go over the themes listed on these slides
  • This isn't all there is to ES6
  • I won't have time to go into them deeply
• There will be exercises for most subjects
  • Go to marijnhaverbeke.nl/falsy
    • an ES6 sandbox
    • exercises and place to solve them
  • After each theoretical part, I'll ask you to solve the exercises
    • Work alone or in small groups or not at all
    • Feel free to ask me for help at any time
• At home
  • babel src/foo.js > dist/foo.js
  • Will want to combine with a module packager
• Most changes are syntactic niceties
  • I'll be showing a lot of code

Classes

• There was a time where it was fashionable to complain
  • They are adding classes to JavaScript! They want to make it Java!
  • No one ever had that intention
  • No one is taking your prototypes away from you
  • Things change, that's okay
• A syntactic improvement
  • Which I've found extremely helpful
  • Easier to quickly define a type
  • Information about the type more centralized and readable
• So you say class
  • its name
  • possibly its superclass
  • and then the body
    • which contains methods, getters, setters, and a constructor
• What you get is almost the same as the old approach
  • The constructor is bound to the name
  • Its prototype is an object based on the superclass prototype
  • With all the getters, setters, and methods from the body added
  • You can still mess with the prototype afterwards
• No semicolons or commas between body elements
  • This is what getters and setters look like
  • A class that lies about its age
• Can't define non-method properties in the class body
  • Instance props have to be defined the old way, in constructor
  • Shared properties you can define as getters or by adding to proto

• Prefixing static to a method puts it on the constructor

• A real win is super
  • Calls to superclasses were very awkward in ES5
  • Have to explicitly name superclass, use .call, etc
  • The super keyword makes this easier
    • Call in constructor to call super constructor
    • Call methods on it to call methods from superclass
• class expressions
  • very much like function expressions
  • use class in expression position
  • can be useful for mixins, dependency injection, etc
  • evaluates to the constructor function

Object literals

• Regular object literals also got some new syntax

• Methods in an object literal can be written using the same shorthand syntax
  • (Though don't forget the commas)
• When the property is initialized to a variable with the same name
  • You can simply only use the name
• You can use the proto property in an object literal to specify its prototype
  • In general, the proto property is now in the standard
  • And in such a way that
    • it isn't an own property
    • it doesn't appear on null-prototype objects
• Putting a property between square brackets allows a computed name
  • This is occasionaly useful
  • And often useful if you're using symbols, which we come to later
  • This also works in class definitions, by the way

Block scope

• Another very visible syntactic change
  • You can immediately spot ES6 code because s/var/let/
• let is like var, but block-scoped instead of function-scoped
  • If you declare a var inside of an if branch or loop
    • it won't leak into the rest of the function
    • its scope is the block in which it was declared
  • This is almost always preferable
    • So people tend to use let everywhere
• const is like let, but immutable
  • assignments ignored
    • Babel raises static error when possible
    • that seems saner
  • mostly useful as a form of documentation
    • this isn't going to change
    • especially for global/module-wide variables
• functions declarations in blocks used to be a mess
  • some engines hoisted them to the top of the function, some didn't
  • ES5 forbids them
  • ES6 simply makes them block-scoped, hoisting them to the top of the block
• Stricter
  • you get an error if you declare the same let/const variable twice in same block
  • that also goes for redeclaring argument variables
  • so now I hope everybody stops declaring all their variables at the top of the function
    • man is that ugly
    • this leaves no excuse
• Sane behavior for loops
  • each iteration conceptually gets a new scope
  • you only really notice this if you close over it
  • we'll see in the exercises why this is good

Arrow functions

• People often say JS is a functional language
  • You have closures and higher-order functions and such
  • But every function you write is at least 18 characters
    • function and return keyword, parens, braces
  • So your conceptually elegant functional code still looks absolutely awful
• Arrow functions are a shorter syntax for defining functions
  • Put a fat arrow after the arguments, and then an expression that is the function body
• You may put parens around the arguments
  • For zero or > one you have to

• This allows all kinds of things to look a lot more succinct

• Wait, can we do that?
  • Doesn't the callback get its own this?
  • No, not with arrow functions
  • Arrow functions inherit (close over) the this from their parent scope
  • So you can finally stop doing 'var self = this' (or 'that', or 'thiz')
    • One less source of bugs and friction
• Arrow functions can not be used as constructors
  • Nor would you want to
• But what if your function needs to have a body
  • A brace after a fat arrow starts a body
  • Here you have to use the return keyword if you want to return something
  • Also useful for non-returning single-expression bodies
• There's a corner case with trying to return an object expression
  • That'll be treated as a body
  • Wrap it in parens to get an object

Destructuring

• ES6 introduces destructuring assignment
  • You can now assign to, or bind, 'patterns'
  • More cleanly express property extraction
• Array patterns are written as arrays
  • but the elements are patterns instead of expressions
  • this means that we are binding x and y to the 1st and 2nd properties in the array
• Object patterns are similar
  • There's a shorthand for when the bound identifier is the same as the property name
  • You can nest these
• By putting an equals sign after a pattern you provide a default
  • If the value found is undefined, the default is used instead
• Any binding construct can use a destructuring pattern
  • also within a for loop
• You can assign directly to patterns
  • But the syntax makes this slightly awkward
  • Need semicolons in semicolon-free style
  • Need parens around assignments to object patterns
• And function parameters can be patterns
  • pick out the fields that you need right away
  • can add defaults to have argument default values
  • In arrow functions, even for a single arg, must add parentheses around pattern
• Destructuring causes something very much like property access to happen
  • And will error out if applied to null or undefined
  • (Unfortunately, there's no conditional matching support)

Spread operator

• In ES6 dot-dot-dot is a piece of syntax called spread
  • It means different things in different context
  • but the general idea is that it represents expanding an array

• Can be used in array literals to smear out other arrays into the new array

• Can be used in array patterns to match the rest of of the array

• And similarly, in argument lists, to match any remaining arguments
  • You get a real array, not a weird arguments object
  • This, combined with default argument values
    • means you never need to touch arguments again
• Can even be used in function calls, to insert an array of arguments
  • Doesn't even have to be at the end of the list in this case

Template strings

• There was one type of quote character that you couldn't yet use for JS strings
  • the backtick
  • well now you can
• It mostly works the same as regular strings
  • You escape characters with backslashes
  • But template strings can include newlines
    • (They stand for ... newlines)
• And if you say ${}, the result is spliced in
  • Converted to string
  • So we have multiline strings and string interpolation now
• But that's not all. Look at this
  • String.raw
  • That's in fact a general-purpose feature
• Template strings, tagged template strings
  • tag`foo` is just a call to tag
    • passing in the string parts and the interpolated parts separately
  • So tag`foo ${bar} and ${baz}` calls tag(["foo ", " and ", ""], bar, baz)
  • But the strings passed are 'cooked' (backslashes interpreted)
  • How do you implement String.raw?
    • The raw property of the string array is another array with uninterpreted strings

Map, Set

• In classical JavaScript, we have one type of map/hash: the object
  • Keys are strings (and integers, sort of)
  • And even for that, they are kind of garbage unless you Object.create(null)
• Creating, for example, a map with objects as keys does not work
  • You can add properties to the objects themselves (eww)
  • Or you can stard adding unique ids to all objects (ugh)
• ES6 comes with a convenient Map object that implements such a map
  • Comparing objects happens much like the === operator
  • Except that NaN matches to NaN, even though it isn't === equal

• Methods on maps

• Sets are similar, but only store a set of objects

• Then there's WeakMap and WeakSet
  • Which don't cause the garbage collector to hold onto their keys
  • This can be useful for storing information about values
    • which you aren't going to need anymore if you stop using the value
  • They can spontaneously lose entries

Promise

• This is one of the parts of ES6 that can be implemented purely as a library
  • Which people have done
  • It's available in modern browsers, but also as an npm package
  • Widely used -- some of you are probably already using it
• A promise is an abstraction over an asynchronous action
  • an object that allows you to register functions
    • to be called when the action finishes or fails
  • along with a few primitives for working with such actions
• This is what promise-using code looks like
  • you define or import async primites that wrap their result in a promise
    • for example jQuery.ajax
  • Your code tends to become a big chain of then calls
    • rather than a big pyramid of nested callbacks
    • that's an improvement
• A promise can succeed or fail
  • Succeeds with result value
  • Fails with an error value (usually an Error object)
• Promises help with error handling
  • In classical callback style, it is notoriously easy to 'drop' an exception
    • Crashing your program
  • Promises call their handler functions from a try block
    • And consider raising an exception to be the same as failing the promise
• You create a promise like this
  • The constructor takes a function with two arguments
  • This function must then initiate the action
    • and call its first argument on success
    • or its second on failure
• The then method returns another promise
  • If the function given to it returned a plain value,
    • that's the result of the returned promise
  • If it returned another promise
    • The returned promise waits for that one and takes its result
• Effective but very noisy abstraction

Symbols

• Everybody knows that object properties are keys
  • But now this is no longer the case
  • They can be either strings or symbols
  • Symbols are different
    • They are compared by identity, rather than by character content
• Why?
  • Extending existing objects is fundementally unsafe
    • Someone else might be doing the same using the same name
  • If both libraries would create a symbol
    • They'd both have their own symbol object to use as index
    • Calling symbol with the same string returns a new symbol
    • And thus they wouldn't clash
• Private variables
  • You can also use this as a way to signal that properties are private
  • Use symbols as property names, don't export them
  • Somewhat awkward, I wouldn't bother, but you could do that
  • Note that these are still not unreachable for external code
    • It can call Object.getOwnPropertySymbols to get access to a symbol
    • And then use it to get at the property values
    • Strict privacy is not JavaScript's way (and that's okay)
• The standard defines a number of 'well known' symbols
  • these are properties of Symbol containing symbols
  • that are part of certain interfaces
  • you can use them to, for example, hook into the behavior of instanceof
    • this doesn't actually work yet on any browser I tried
    • but we'll get to another such symbol in a moment
      • possibly the most important one, used for iteration

Iterators

• There's various ways to model iteration over the content of containers
  • internal iterators like forEach
  • external iterators, like C++ iterators, where you have an object that represents the iteration
  • and of course, crudely running an integer up to the container size and indexing
• ES6 defines an interface for external iterators
  • .next() -> {value, done}
  • keep calling it until .done is true
  • the iterated values are the ones in the objects where done isn't true
  • the last object (done=true) also has a value, but that one is usually ignored
    • this is the 'return value' of an iterator
    • we'll come back to an exception later
• Then there's the concept of an iterable
  • Symbol.iterator holds a function that produces the iterator
  • arrays, maps, sets, strings, are all iterable
• The easiers way to consume an iteratable is for/of
  • Syntax very much like for/in
  • But iterates over an iterable
  • Examples
• The spread operator actually uses this interface
  • So [..."foo"] is ["f", "o", "o"]
• Efficiency concerns are not unfounded
  • Much slower than a var i loop
  • Mostly due to the GC having to clean up all those objects
    • It's good at this, but not so good that it doesn't make a difference
  • So if you are iterating over huge arrays (or lots of tiny ones)
    • and the work you do for each element is cheap enough that the iteration cost matters
    • maybe stick for var i loops
  • Whenever the loops are small, the iteration cost isn't relevant
    • Still, it is unfortunate that we have to think about this
    • I'm hoping things will improve as implementation of this feature matures

Generators

• Generators are a nice way to define iterators
  • Not all iterators have to be generators
  • But often using this approach helps readability
• The definition looks sort of like an internal iterator
  • You use your own control flow and then yield to the consumer
  • But through the magic of compilers, these are turned into external iterators
• Such a function is called a generator
  • When you call it, it returns an iterator
  • Instread of putting its local state on the stack, it puts it on the heap
  • So that the function body can be resumed
    • even though it is not on the call stack anymore
• Standard iterators, as well as generators, are iterable
  • They return themselves as iterator
  • So you can use them everywhere an iterable is expected
  • You can also inherit from the standard iterator proto yourself
    • But it's kind of awkward
    • They actually mention this in the standard
    • Great interface design
• So a generator is like an off-stack stack frame
  • That means, among other things
    • that the yield has to appear in the generator function itself
    • you can't yield from an internal helper functions
  • can you have recursive generators?
    • Not directly, but you can use yield*
    • Which yields all the values in an iterable
    • If that iterable is a generator
      • this is a lot like a recursive call to a generator

• (This is how you indicate that a method is an iterator, by the way.)

• In typical iteration the data flows in one way, out of the iterator
  • But you can write an iterator whose next method accepts an argument
    • And somehow changes its behavior based on that argument
    • Like this countdown, which can be bumped up by passing an integer to next
  • In a generator, the yield expression returns the first argument passed to next
    • So this code does the same thing
    • Except that a generator doesn't have access to the value passed to the first next call
      • which starts execution at the top of the body
      • and thus doesn't correspond to a yield expression
• I mentioned the return value of an iterator before
  • the value of the last (done=true) object it returns
  • if a generator contains a return statement, that sets this value
  • and if you do yield*, the result of that yield expression
    • is the iterator's return value
• This is all pretty weird and takes some getting used to
  • From the outside, you have the iterator interface
  • From the inside, you have arbitrarily suspended and resumed control flow
    • With values moving out (yielded) and coming in (passed to next)
  • On top of that, an iterator created with a generator has a throw method
    • Which raises an exception at the the generator's current pause point
  • Why was this feature designed like this?
• Let's look from the inside again
  • We get the superpower of suspending control flow
    • exchanging values with another part of the program
    • and resuming again
  • Who can think of a problem in JS programming that this might help with?
    • Very good -- async programming
• All we need is
  • This one little wrapper
  • And async primitives that expose a consistent interface
• Generators have been suggested as the answer to the pain of async code
  • An async process is written as a generator
  • Each time the function needs to do something asynchronous
    • it yields to pause itself
      • producing a value that describes the thing it is waiting for
      • and expecting the result of that thing as the value of the yield expression
  • On the 'other side', the side receiving the yielded values
    • There needs to be code that waits for the async actions to finish
    • And calls next with their result
  • One widely used way to describe async actions is Promises
    • They are a great fit for this style
• So here's an example -- loadUser
  • It uses the get function to make requests
    • (This could just be jQuery's get function)
  • Note how we don't need a separate getJSON
    • We can insert an asynchronous call in the middle of an expression
    • Just have to prefix it with 'yield' so that our execution is paused
    • And its result just flows right into our call expression
  • Can make async calls inside of control flow (like if)
    • Without doing weird callback gymnastics
• And we can even compose such pieces of code cleanly
  • This generator calls the getUser generator as a subroutine
  • getUser will produce promises that get resolved
    • and they end up in the right way because yield* passes them on
  • its return value is what the yield* expression returns
    • exactly what we want
  • to actually run such a async code, we pass it to a driver function
• Here I tried to fit my driver function on a slide
  • It takes a generator and starts by calling that
    • to turn it into an iterator
  • The resume function takes a result produced by the generator
    • And if it is done, we're at the end of the function
    • If not, value must be a promise that the function is waiting for
      • So we wire up callbacks using then
      • And depending on how the promise resolves
        • give the generator a value
        • or raise an exception
      • The next thing coming out of the generator is passed back to resume
  • To start things off, we start the generator and pass its result to resume
• So this is pretty cool
  • Not perfect, somewhat noisy and error prone
  • But I think it's better than just promises
  • And also preferable to implicit pseudo-blocking calls
    • If you don't know which function call will suspend your code
    • You don't know when your state should be consistent
    • Having suspendability be obvious in the code is a plus
• There is work on an extension in the next version of JS called async/await
  • which is a lot like this
  • but without the need for wrapping things in a driver

Modules

• I don't have exercises for this part
  • No time to set up the sandbox logic
  • You can use babel and webpack/browserify locally
• You can think of ES6 modules as a different syntax for CommonJS modules
  • the thing with require/exports
  • except it is more well-integrated into the language
    • and more static
• My initial reaction was -- why?
  • Who wants static
  • And why invent syntax if we can cleverly reuse existing concepts
• But they are actually quite nice
  • I've ported on library (Acorn) and written a new project (ProseMirror) using such modules
  • And I'm sold
  • The syntax is much more pleasant
    • Importing groups of bindings from a module is much cleaner
    • exporting also definitely looks better
      • no more need to both define a local variable and assign to exports
  • The staticness is usually what you want
    • If my code won't browserify/webpack that's a bug anyway
    • So there's very little clever run-time tricks I can use
    • Lint errors for import/export mistakes are a plus
• So here's what it looks like
  • you can prefix the various declarations--var, let, const, function, class--with export
  • these add an export with the same name to the module
  • modules are collections of exports

• Imports and exports appear the top level

• No more 'i'm going to export a function'
  • except that the export named 'default' has a special role
  • You can export an expression as default like this
    • But it is not necessarily the only thing exported
• To import, you normally specify a list of imported stuff in braces
  • But if you do this, you get the default export
  • You can also list the word default in a list of imports
• Imported modules are referenced as string literals
  • Static string literals, not any string expression
  • The spec does not specify a resolution mechanism
  • But people are mostly using Node's mechanism
    • conveniently import from node_modules
• You can rename imports
  • To, for example, avoid name clases
• Or import all exports under an object
  • You can not import * into the local scope directly
  • I think that's a good thing
  • It means every identifier you pull in is explicitly declared
    • No magic or unexpected conflicts

• Finally, there's syntax for re-exporting

• And similar syntax for exporting after the fact from the local module

• Dynamic loading
  • System.import takes any string, dynamically resolves/loads
  • Returns a promise -- async loading
  • I am not aware of any implementations or projects using this
    • but it's in the spec, will probably be adopted

New objects & methods

• ES6 also defines a number of new objects and methods
  • We saw a few, like Promise, Map, Set
• Typed arrays are now part of the language
  • They've been in browsers for a while
    • Needed by, for example, WebGL
  • A compactly represented array of binary numbers
    • You can sort of approach it like an array
      • It has a bunch of properties and methods similar to arrays (length, [i], map)
    • But also exposes a bunch of memory-munging methods
      • fill
      • copyWithin
      • set
    • Iterable
• In fact, arrays also have fill and copyWithin methods now
  • As well as the Array.from method we saw before
  • And Array.of, a less braindead new Array
  • you can now find elements or indices with a predicate with find and findIndex
• New, less brainless versions of isNaN, parseInt under Number
  • isNaN no longer converts to number before checking
  • parseInt doesn't magically switch to octal when first char is 0
• RegExp.unicode
  • Treats astral code points as single characters
    • Classic JS regexps used to treat them as their utf-16 halves
    • Which just doesn't make any sense
    • Add /u for them to do the right thing
• Codepoint-aware string methods
  • You'd prefer not to do utf-16 en/decoding in your own code
  • String.fromCodePoint
  • "".codePointAt
• String.repeat
  • I've probably written this ten times in different projects
  • It's now in the language!