6 ms·

ECMAScript 2016 Approved

238 points by gsklee 10y ago

SimeVidas 10y ago
504 pages according to Chrome’s print preview.
BinaryIdiot 10y ago
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.
- rtpg 10y ago
  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.
  - BinaryIdiot 10y ago
    > Yeah, though jQuery has helped a lot to make some sort of "standard library", jQuery is mostly a better library for dealing with the DOM though. It has support for making network calls but those don't work in node without polyfills. > 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. I mean fetch exists and is an HTML 5 standard that's fairly decoupled from the DOM, unlike XMLHttpRequest. But it has to also work in node.js. I wrote a set of HTTP methods in my msngr library that works in both node.js and the web browser but it feels like a hack. I want my language to have first class networking and file io.
    - aviraldg 10y ago
      Did you try isomorphic-fetch?
      - BinaryIdiot 10y ago
        No; node and the browser provide APIs that do this already they're just very different so I simply wrapped them to avoid dependencies (it was pretty easy). But I knew of it and it's a good idea.
  - yoshuaw 10y ago
    > I would love for browsers and other VMs (well, Node) to aim for Python-level standard library (...) Node has a cultural disliking for big standard libraries, preferring to delegate to the package manager instead. If anything the API might shrink further, not get added to.
- ZenPsycho 10y ago
  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 10y ago
    > 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.
- BurningFrog 10y ago
  The diff is very small, unless this document from January is outdated: http://www.2ality.com/2016/01/ecmascript-2016.html http://www.2ality.com/2016/01/ecmascript-2016.html
  - neogenix 10y ago
    No that is still correct. It is this line from the 'overview': "This specification also includes support for a new exponentiation operator and adds a new method to Array.prototype called includes."
  - BinaryIdiot 10y ago
    Yeah I thought I was misreading things with how little changed. I guess the move to yearly really makes a difference there.
- disordinary 10y ago
  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.
- espadrine 10y ago
  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/ 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/ 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/ 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'.
  - BinaryIdiot 10y ago
    > If implementing JS required a file system to be present, it would not be possible to implement a spec-compliant JS in some environments. Maybe? I think it would be really interesting to open that up for the web browser to a degree. It would need some sort of permission model but providing more, standard libraries that can interact with the system would make web applications more viable in certain types of projects (especially corporate). Sure that opens it up to major, major security concerns but nothing that can't be overcome. But even so it could be part of the standard that certain pieces can become restricted when deployed into certain environments. > 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'. That would be awesome though this has been a known issue for quite a long time now and no one seems to really want to do much about it so I'm not sure what kind of effort it's going to take to make this happen.
- kensai 10y ago
  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."
- deleted 10y ago
  [deleted]
- irrational 10y ago
  But, wouldn't including file IO in JS lead to massive security problems in the browser?
0xCMP 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      I do hope they gain some more traction. I've found them to be very useful with reducing boilerplate / repetitive code.
- neogenix 10y ago
  "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..
- RobertKerans 10y ago
  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 https://github.com/tc39/proposals
- tlrobinson 10y ago
  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.
sktrdie 10y ago
Did Observables make it in with the `async function* SomeObservable() {}` type of syntax?
- domenicd 10y ago
  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.
domenicd 10y ago
As always, see https://tc39.github.io/ecma262/ https://tc39.github.io/ecma262/ for the up-to-date spec that implementers use.
z3t4 10y ago
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 10y ago
  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.
edwinjm 10y ago
"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 10y ago
  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 10y ago
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 10y ago
  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 10y ago
    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.
- buchanaf 10y ago
  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.
- 10y ago
salamanca 10y ago
The few number of changes speaks of the already inherent quality of the language.
jsingleton 10y ago
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 10y ago
  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 10y ago
    We should just call it ES15 and ES16.
    - jsingleton 10y ago
      But then what about ECMAScript 2024 and ECMAScript 2025?
      - RobertKerans 10y ago
        ES24 and ES25?
  - jsingleton 10y ago
    Yeah, I was referring to new feature in ES2015/ES6, but really I mean just new ES features in general are good. It's just the naming that's problematic. Even http://caniuse.com/#feat=arrow-functions http://caniuse.com/#feat=arrow-functions says: > See support for arrow functions (ECMAScript 6)
    - dangoor 10y ago
_pmf_ 10y ago
These 10 ECMA Features Taken From Actually Useful Languages And Presented As Cool Innovations Will Blow Your Mind!
- ScaryRacoon 10y ago
  Just so we're clear: you're saying JavaScript isn't a useful language? Ooookay then.

238 points by gsklee 10y ago

504 pages according to Chrome’s print preview.

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.

rtpg 10y ago
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.
- BinaryIdiot 10y ago
  > Yeah, though jQuery has helped a lot to make some sort of "standard library", jQuery is mostly a better library for dealing with the DOM though. It has support for making network calls but those don't work in node without polyfills. > 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. I mean fetch exists and is an HTML 5 standard that's fairly decoupled from the DOM, unlike XMLHttpRequest. But it has to also work in node.js. I wrote a set of HTTP methods in my msngr library that works in both node.js and the web browser but it feels like a hack. I want my language to have first class networking and file io.
  - aviraldg 10y ago
    Did you try isomorphic-fetch?
    - BinaryIdiot 10y ago
      No; node and the browser provide APIs that do this already they're just very different so I simply wrapped them to avoid dependencies (it was pretty easy). But I knew of it and it's a good idea.
- yoshuaw 10y ago
  > I would love for browsers and other VMs (well, Node) to aim for Python-level standard library (...) Node has a cultural disliking for big standard libraries, preferring to delegate to the package manager instead. If anything the API might shrink further, not get added to.
ZenPsycho 10y ago
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 10y ago
  > 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.
BurningFrog 10y ago
The diff is very small, unless this document from January is outdated: http://www.2ality.com/2016/01/ecmascript-2016.html http://www.2ality.com/2016/01/ecmascript-2016.html
- neogenix 10y ago
  No that is still correct. It is this line from the 'overview': "This specification also includes support for a new exponentiation operator and adds a new method to Array.prototype called includes."
- BinaryIdiot 10y ago
  Yeah I thought I was misreading things with how little changed. I guess the move to yearly really makes a difference there.
disordinary 10y ago
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.
espadrine 10y ago
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/ 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/ 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/ 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'.
- BinaryIdiot 10y ago
  > If implementing JS required a file system to be present, it would not be possible to implement a spec-compliant JS in some environments. Maybe? I think it would be really interesting to open that up for the web browser to a degree. It would need some sort of permission model but providing more, standard libraries that can interact with the system would make web applications more viable in certain types of projects (especially corporate). Sure that opens it up to major, major security concerns but nothing that can't be overcome. But even so it could be part of the standard that certain pieces can become restricted when deployed into certain environments. > 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'. That would be awesome though this has been a known issue for quite a long time now and no one seems to really want to do much about it so I'm not sure what kind of effort it's going to take to make this happen.
kensai 10y ago
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."
deleted 10y ago
[deleted]
irrational 10y ago
But, wouldn't including file IO in JS lead to massive security problems in the browser?

0xCMP 10y ago

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 10y ago
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 10y ago
  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 10y ago
    I do hope they gain some more traction. I've found them to be very useful with reducing boilerplate / repetitive code.
neogenix 10y ago
"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..
RobertKerans 10y ago
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 https://github.com/tc39/proposals
tlrobinson 10y ago
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.

sktrdie 10y ago

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

domenicd 10y ago
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.

domenicd 10y ago

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

z3t4 10y ago

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 10y ago
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.

edwinjm 10y ago

"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 10y ago
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 10y ago

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 10y ago
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 10y ago
  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.
buchanaf 10y ago
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.
10y ago

salamanca 10y ago

The few number of changes speaks of the already inherent quality of the language.

jsingleton 10y ago

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 10y ago
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 10y ago
  We should just call it ES15 and ES16.
  - jsingleton 10y ago
    But then what about ECMAScript 2024 and ECMAScript 2025?
    - RobertKerans 10y ago
      ES24 and ES25?
- jsingleton 10y ago
  Yeah, I was referring to new feature in ES2015/ES6, but really I mean just new ES features in general are good. It's just the naming that's problematic. Even http://caniuse.com/#feat=arrow-functions http://caniuse.com/#feat=arrow-functions says: > See support for arrow functions (ECMAScript 6)
  - dangoor 10y ago

_pmf_ 10y ago

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

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