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

21–30 of 83 posts

Re: ECMAScript 2016 Approved

#21

Post by aviraldg »

BinaryIdiot wrote: post #6
rtpg wrote: post #4

Earlier quoted context omitted.

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

Did you try isomorphic-fetch?

Re: ECMAScript 2016 Approved

#22

Post by 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!?

Re: ECMAScript 2016 Approved

#23

Post by disordinary »

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…

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.

Re: ECMAScript 2016 Approved

#24

Post by Kiro »

rkwz wrote: post #17
ZenPsycho wrote: post #7

Earlier quoted context omitted.

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

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

You are wrong. It's absolutely fine to downvote on disagreement. See the following comment from pg himself:

http://news.ycombinator.com/item?id=117171

Re: ECMAScript 2016 Approved

#25

Post by [deleted] »

Kiro wrote: post #24
rkwz wrote: post #17

Earlier quoted context omitted.

(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 co…

> Please don't downvote parent if you disagree with parent's opinion, downvote only if it doesn't contribute to the discussion You are wrong. It's absolutely fine to downvote on disagreement. See the following comment from pg himself: http://news.ycombinator.com/item?id=117171

[deleted]

Re: ECMAScript 2016 Approved

#26

Post by LionessLover »

z3t4 wrote: post #22

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!?

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.

Re: ECMAScript 2016 Approved

#27

Post by rictic »

rkwz wrote: post #17
ZenPsycho wrote: post #7

Earlier quoted context omitted.

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

Manipulation and utility functions like Object.keys, Object.values, Object.entries, Array.isArray, Array.prototype.includes, Sets, Maps, and many more? Because those and more are actual accepted additions to Javascript over the past several years.

Re: ECMAScript 2016 Approved

#28

Post by LionessLover »

Kiro wrote: post #24
rkwz wrote: post #17

Earlier quoted context omitted.

(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 co…

> Please don't downvote parent if you disagree with parent's opinion, downvote only if it doesn't contribute to the discussion You are wrong. It's absolutely fine to downvote on disagreement. See the following comment from pg himself: http://news.ycombinator.com/item?id=117171

Which is wrong. As is the use of "absolutely" - to show that you have the universe-opinion. What hubris. And it does not matter that some guy "himself" posted some opinion either. Right were you link to there are different opinions from other people that show more thought was put into them. The "pg" comment actually is the only one for your argument, all others are against!

Re: ECMAScript 2016 Approved

#29

Post by espadrine »

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…

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

Re: ECMAScript 2016 Approved

#30

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

Post reply on HN