Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ECMAScript 2016 Approved

ecma-international.org

Post reply on HN
Print view View original

11–20 of 83 posts

Re: ECMAScript 2016 Approved

#11

Post by neogenix »

BurningFrog wrote: post #8
BinaryIdiot wrote: post #3

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 ECMAScrip…

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

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

Re: ECMAScript 2016 Approved

#12

Post by BinaryIdiot »

ZenPsycho wrote: post #7
BinaryIdiot wrote: post #3

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 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 f…

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

Re: ECMAScript 2016 Approved

#14

Post by BinaryIdiot »

BurningFrog wrote: post #8
BinaryIdiot wrote: post #3

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 ECMAScrip…

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

Yeah I thought I was misreading things with how little changed. I guess the move to yearly really makes a difference there.

Re: ECMAScript 2016 Approved

#15

Post by elliotec »

ZenPsycho wrote: post #7
BinaryIdiot wrote: post #3

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 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 f…

JavaScript doesn't just run in the web browser anymore. A standard library seems like an odd and annoying oversight at this point. Relevant blog post from Thomas Fuchs: https://medium.com/@thomasfuchs/what-if-we-had-a-great-stand...

Re: ECMAScript 2016 Approved

#16

Post by RobertKerans »

0xCMP wrote: post #5

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?

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

Re: ECMAScript 2016 Approved

#17

Post by rkwz »

ZenPsycho wrote: post #7
BinaryIdiot wrote: post #3

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 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 f…

(Please don't downvote parent if you disagree with parent's opinion, downvote only if it doesn't contribute to the discussion)

@ZenPsycho: A standard library doesn't always have to mean file io or sockets etc. It could be better String/Array/Object manipulation apis, better utility functions (kinda like what underscore/loadsh provide) etc

These are universal helpers that are very much needed whether you're writing code that runs in browser/server/mobile/iot etc.

> 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

Maybe a bad example, but wouldn't sync file io be a problem in server as well?

Re: ECMAScript 2016 Approved

#19

Post by domenicd »

Raticide wrote: post #9
0xCMP wrote: post #5

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?

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?

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.

Re: ECMAScript 2016 Approved

#20

Post by domenicd »

sktrdie wrote: post #13

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

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.
Post reply on HN