
ECMAScript 2016 Approved - gsklee
http://www.ecma-international.org/ecma-262/7.0/index.html
======
BinaryIdiot
I wish this contained a delta between the previous release and this release.
It's difficult to find the differences just by skimming.

Edit: apparently I hadn't realized that the changes were so few that what was
in the outline really did cover everything. I thought it was a summation. My
fault.

That being said I continue to be disappointed in the built-in standard library
of JavaScript. As far as I can tell ECMAScript 2017 also has zero plans for
incorporating useful libraries for file IO or sockets (currently both are
provided through different APIs by node or the browser). This really needs to
happen.

~~~
ZenPsycho
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.

~~~
BinaryIdiot
> 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.

I couldn't disagree more. JavaScript started out that way but today (really
the past 6+ years) it's used in identical use cases as Python in addition to
being embedded into web browsers.

> 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.

You don't need to. Provide the basic capabilities that all languages provide,
restrict what isn't possible when it's embedded into an environment. Keep it
simple.

> 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.

This is very unfair. What's "years ago"? The asynchronous patterns used in
JavaScript date back to well over a decade ago and JavaScript wasn't really
used elsewhere until node.js. I'm not sure I would consider any standard APIs
as "bloat" either. This just looks like a baseless attack.

> 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.

Same goes for all programming languages and their standard libraries. This is
why you target specific versions. This is a solved problem.

> Javascript and the web is an open platform. not a closed platform.

So is Python. C++. C#. etc.

~~~
patates
> You don't need to. Provide the basic capabilities that all languages
> provide, restrict what isn't possible when it's embedded into an
> environment. Keep it simple.

Well, that makes sense but wouldn't it make more sense that the environments
supply what's meaningful on top of a very light base? Like
window.document.querySelectorAll in browser and require("fs") in node.js?

I, although, also think that stuff like what underscore/lodash provides could
very well be in that light base, before we start discussing a standard for
observables.

~~~
BinaryIdiot
> wouldn't it make more sense that the environments supply what's meaningful
> on top of a very light base

I certainly don't think so. JavaScript is a language that works in more places
now; commonized libraries would be a huge benefit. As an example you wouldn't
use Python with different io libraries depending on the operating system it's
running on and yet this is what node is evolving into.

> Like window.document.querySelectorAll in browser and require("fs") in
> node.js?

querySelector / querySelectorAll are specific to a browser platform but a way
to conduct io could be pretty universal, in my opinion.

------
jsingleton
So, ECMAScript 2015 is ES6 and ECMAScript 2016 (this) is ES7 [0]. I like the
new features (promises, arrow functions etc.) but the naming is as confusing
as Visual Studio. VS 2015 is the current version but VS 15 is the next one.

[0]
[https://en.wikipedia.org/wiki/ECMAScript](https://en.wikipedia.org/wiki/ECMAScript)

~~~
dangoor
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](http://caniuse.com/#search=arrow)

~~~
nojvek
We should just call it ES15 and ES16.

~~~
jsingleton
But then what about ECMAScript 2024 and ECMAScript 2025?

~~~
RobertKerans
ES24 and ES25?

------
domenicd
As always, see
[https://tc39.github.io/ecma262/](https://tc39.github.io/ecma262/) for the up-
to-date spec that implementers use.

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

Not much new here for regular JavaScript developers.

~~~
WorldMaker
Everything about this is for regular JS developers:

Exponentiation operator:

    
    
        2 ** 32
    

is much friendlier to write than Math.pow(2, 32) or

    
    
        x **= 2
    

versus x = Math.pow(x, 32).

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".

------
dpweb
They should be working to make JS smaller and simpler and better. Focus on the
philosophy of what JS should be. People instead tend to focus on 'new
features'.

The power in JS is functional programming. For instance, grafting on Classes,
was a mistake. They may focus on concepts like, how do we make sure we never
create two ways to do the same thing - instead of how do we incorporate this
new thing.

~~~
Noseshine
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.

~~~
irrational
What is your programming background? I just wondering because I also do not
use classes or even prototypical inheritance but just functions. But I did not
come from a class-heavy background like Java. I'd like to see a poll of those
who use classes vs not in JavaScript and whether they come from a class-heavy
language background (like Java) or not. My assumption is that those who come
from Java prefer to use classes in JS and others not so much.

------
SimeVidas
504 pages according to Chrome’s print preview.

------
0xCMP
Does anyone know if decorators made it in? I can't find them via the search at
first glance. I'm guessing they're listed under a different name/section than
I thought?

~~~
Raticide
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?

~~~
domenicd
Decorators are not an ES7 feature. They 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.

At this point it is best to call them a Babel feature, not an ES feature.

~~~
dvlsg
I do hope they gain some more traction. I've found them to be very useful with
reducing boilerplate / repetitive code.

------
z3t4
Why don't they "fix" the numeric system to be more exact? I'm talking about
the float implementation. I don't think anyone depends on the floating point
rounding errors. But we do spend a lot of time avoiding them. They totally
"screwed up" the syntax in 2015, with many breaking changes, so why not fix
the damn rounding errors!?

~~~
LionessLover
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](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.

------
sktrdie
Did Observables make it in with the `async function* SomeObservable() {}` type
of syntax?

~~~
domenicd
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/](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.

------
_pmf_
These 10 ECMA Features Taken From Actually Useful Languages And Presented As
Cool Innovations Will Blow Your Mind!

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

