ECMAScript 2016 Approved

Javascript doesn't need and shouldn't have a "Standard Library". Javascript isn't python or c. It's more like Lua: It's meant to be embedded inside an application, and the application provides all the interfaces you need.

If you start trying to include things like file i/o in the base language, you're never going to satisfy all the very different requirements of code running in a browser vs. running on a server. If file I/O had been standardised years ago, with API designed by server programmers the browser would be saddled with lousy synchronous stuff that hangs the browser UI, opens up a thousand security issues, and bloats the language with stuff that's pointless for purposes that aren't web browsers or servers.

If you think the web platform lacks something what you do is take it up with the W3C or WhatWG who are in charge of deciding what APIs the application exposes. if you want node to match the browser or vice versa, write a library.

Finally the biggest and best reason to not do this is that, once you put something in javascript (or a web browser for that matter), you can never ever take it out no matter how badly designed it is, without breaking something. At least with an external library abstraction you can switch to a better designed library.

Javascript and the web is an open platform. not a closed platform. The web browser itself provides a MASSIVE standard library that includes everything from a UI and text layout engine, to a standard graphics drawing library, a standard file io library, and plenty of other stuff you'd have to build from scratch in python or ruby. Don't undersell that.

I concur; I wish for a delta to be made more explicit as a non-normative section.

I added concise explanatory additions to the spec here: http://espadrine.github.io/New-In-A-Spec/es2016/.

Currently, the changes for ES2017 are the following: http://espadrine.github.io/New-In-A-Spec/es2017/.

File I/O means different things in different contexts. If implementing JS required a file system to be present, it would not be possible to implement a spec-compliant JS in some environments. But specs are already worked on elsewhere, such as the File API: https://w3c.github.io/FileAPI/. They obviously have very specific constraints, as the Web has a restrictive security model compared to downloaded executable binaries.

That said, some level of convergence with Node.js would be welcome, starting with the now fragmented module loading mechanisms: var f = require('file') vs. import * as f from 'file'.

Yeah, though jQuery has helped a lot to make some sort of "standard library", requirements in the browser (small file size) makes it really hard to bootstrap a "standard library for JS".

I would love for browsers and other VMs (well, Node) to aim for Python-level standard library that would be integrated into the VM. We could get a bunch of functionality without having to ship 3 Meg files to everyone.

Here's a proposal: FF starts building a "standard library for Javascript". Developers can start using it, or provide polyfills for the bits they use through a special script tag like:

<script src="std-lib-poyfill.js" standard-lib-polyfill></src>

So FF would know not to pull it in but other browsers would know. Maybe a version number/point release in there too.

There might be a bit of competition between browsers but I think we could quickly reach a consensus on most things.

... Though I guess this is what standards are for. I would like to see a browser try this anyways, though. That would be the fastest way to get the standards bodies to acknowledge the problem.

The diff is very small, unless this document from January is outdated: http://www.2ality.com/2016/01/ecmascript-2016.html

From the outline's description:

"ECMAScript as defined here is not intended to be computationally self-sufficient; indeed, there are no provisions in this specification for input of external data or output of computed results. Instead, it is expected that the computational environment of an ECMAScript program will provide not only the objects and other facilities described in this specification but also certain environment-specific objects, whose description and behaviour are beyond the scope of this specification except to indicate that they may provide certain properties that can be accessed and certain functions that can be called from an ECMAScript program."

Package management and bundling is so good now I don't see it being a benefit to force us into one way of doing things. The great thing about javascript is flexibility.

But, wouldn't including file IO in JS lead to massive security problems in the browser?

They decided on the "ECMAScript YYYY" naming format a while before the 2015 spec was finalized. Many people in the community continued to call things ES6 and ES7, but those aren't the official names.

ECMAScript is going to be updated on an annual basis now, so it is easier to just use the year going forward.

Promises and arrow functions are ES2015 features, by the way. Already directly supported in a slight majority of the browsers in use: http://caniuse.com/#search=arrow

Everything about this is for regular JS developers:

Exponentiation operator:

    2 ** 32

    x **= 2

Array.prototype.includes: if (['jim', 'bob', 'dave'].includes('bob')) { console.log('We have a party, now.') } versus using for/in, for/of, map/reduce or much more commonly importing JQuery/Underscore/Lodash/some other random npm package for this functionality.

Both are small improvements, but both are squarely for "regular JavaScript developers".

I think the way they added classes was actually ingenious. I actually don't use classes or even prototypical inheritance, I only use functions, functions and functions. But they didn't really change Javascript at all under the hood as far as "class" support is concerned apart from some minor things at the edges - it's the exact same prototypical inheritance pattern as before, only that you write it differently. And if you do choose to use classes it's more readable now than before (yet yields the same result). So they satisfy the very big developer market of the "class people", those who like the old Javascript ways, and also those who like a functional approach. I'm content sharing the language with people who program very differently from myself and ignoring those parts.

But all libraries had their own implementation of createClass, the idea was to pave a cow path that was already there, not to invent some completely new pattern.

While I don't necessarily disagree, I might argue that the power of JS comes in its flexibility. JS is as near to a 'universal' language as there is, and people are coming from a variety of different backgrounds to use it. It's convenient that it supports so many flavors of programming.

Your classes example is actually hilarious, because previously every JavaScript library that wanted classes invented their own incompatible syntax for it. Now there is one "blessed" way of doing classes.

In general this seems to be the approach of ES these days. They take ideas that have been proven or at least prototyped in userland JS or compile-to-JS languages like CoffeeScript and now Babel, and clean them up.

If they didn't push the language forward the community would continue to fragment as other compile-to-JS languages filled that demand.

I often worry that with every new standard the platform becomes more opaque for newcomers. You know, average people who want a shot at making their own webpage and learn to program for something with an immediate use case.

It's not like you have choices of language on the web, the JS jungle is intimidating enough for newbies as it is. I know many will tout compile-to-js as the solution, but that's an even higher barrier to entry and you get too-much-choice syndrome.

Not that I haven't been glad with the ES6 additions myself ...

"This specification also includes support for a new exponentiation operator and adds a new method to Array.prototype called includes."

These are the only 2 features that made it in..

There are only 2 features this year, and decorators are only a stage 1 proposal, so not likely next year either.

https://github.com/tc39/proposals

I can't find anything related to it. It's literally the only feature I use in ES7, so I hope it is in there. Perhaps it has some other obscure name?

No, and sadly the decorator proposal doesn't even include support for decorators on functions (only classes and methods). This is due to conflicting opinions on how to handle the interaction with function hoisting.

Because the system JS uses is an ISO standard, it is a problem not just for JS, it works for the majority of use cases, and implementing a second number system (the old one will have to be kept forever) increases cost and complexity significantly without showing enough benefits, since those who need something different can do so.

For example, if you do "money-math" you could just use only integers (use cents instead of dollars) - your number will be an integer as long as it's a whole number and you re,main below Number.MAX_SAFE_INTEGER (http://www.2ality.com/2013/10/safe-integers.html). That's not enough for big-finance math where fractions of cents matter, but for most such applications it is.

No. Observables are a stage 1 proposal, which means roughly that the committee agrees this problem space is interesting, but that it might see drastic changes in implementation, syntax, and more, or might not make it into the eventual standard at all. The idea of observables for async function* {} has been withdrawn in favor of async iterators (https://github.com/zenparsing/async-iteration/). Additionally, the last TC39 meeting surfaced some strong concerns about whether the design of observables is something that can fit with the rest of the JavaScript ecosystem, and at this point it seems that they will either undergo radical changes (becoming promise-based, for example) or will stay as a user-space library instead of becoming part of the standard.

Just so we're clear: you're saying JavaScript isn't a useful language? Ooookay then.