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

31–40 of 83 posts

Re: ECMAScript 2016 Approved

#31

Post by kensai »

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…

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

Re: ECMAScript 2016 Approved

#32

Post by patates »

BinaryIdiot wrote: post #12
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…

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

Re: ECMAScript 2016 Approved

#33

Post by [deleted] »

BinaryIdiot wrote: post #12
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…

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

[deleted]

Re: ECMAScript 2016 Approved

#34

Post by norswap »

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

The irony of your post getting downvoted is delightful. (I myself agree with you.)

Re: ECMAScript 2016 Approved

#35

Post by yoshuaw »

rtpg wrote: post #4
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…

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…

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

Re: ECMAScript 2016 Approved

#36

Post by oceanswave »

BinaryIdiot wrote: post #12
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…

> 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 confusing a language with a platform. The language specs of the languages you mentioned do not have file system semantics included

Re: ECMAScript 2016 Approved

#37

Post by tragic »

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

It's also fine not to, which means (in my view) it's fine to ask others not to, if you disagree with pg and think it's unhelpful.

Re: ECMAScript 2016 Approved

#38

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

Re: ECMAScript 2016 Approved

#39

Post by Noseshine »

dpweb wrote: post #38

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.

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.

Re: ECMAScript 2016 Approved

#40

Post by buchanaf »

dpweb wrote: post #38

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.

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