ECMAScript 2016 Approved
ecma-international.org
ECMAScript 2016 Approved
1–10 of 83 posts
Re: ECMAScript 2016 Approved
#2504 pages according to Chrome’s print preview.
Re: ECMAScript 2016 Approved
#3I 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.
Re: ECMAScript 2016 Approved
#4I 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 ECMAScrip…
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:
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.
Re: ECMAScript 2016 Approved
#5Does 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?
Re: ECMAScript 2016 Approved
#6I 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 ECMAScrip…
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 propos…
> 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.
Re: ECMAScript 2016 Approved
#7I 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 ECMAScrip…
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.
Re: ECMAScript 2016 Approved
#8I 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 ECMAScrip…
The diff is very small, unless this document from January is outdated: http://www.2ality.com/2016/01/ecmascript-2016.html
Re: ECMAScript 2016 Approved
#9Does 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?
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?
Re: ECMAScript 2016 Approved
#10Does 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?
"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..