ECMAScript 2016 Approved(ecma-international.org) |
ECMAScript 2016 Approved(ecma-international.org) |
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.
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.
@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?
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.
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'.
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.
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.
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.
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.
"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."
At least they didn't use 5 digit years. :)
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
Even http://caniuse.com/#feat=arrow-functions says:
> See support for arrow functions (ECMAScript 6)Not much new here for regular JavaScript developers.
Exponentiation operator:
2 ** 32
x **= 2
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".
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.
These are the only 2 features that made it in..
At this point it is best to call them a Babel feature, not an ES feature.
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.
In general this seems to be the approach of ES these days. They take ideas that have been proven or at least prototyped in userland JS or compile-to-JS languages like CoffeeScript and now Babel, and clean them up.
If they didn't push the language forward the community would continue to fragment as other compile-to-JS languages filled that demand.
It's not like you have choices of language on the web, the JS jungle is intimidating enough for newbies as it is. I know many will tout compile-to-js as the solution, but that's an even higher barrier to entry and you get too-much-choice syndrome.
Not that I haven't been glad with the ES6 additions myself ...
You are wrong. It's absolutely fine to downvote on disagreement. See the following comment from pg himself:
When you come to a new site, it's usually considered civil to learn the rules of that site, although of course I cannot force you to do so. For example, assuming that reddit rules apply on HN is kinda silly. Relatedly, you might be interested to note that there are dozens of HN old-timers that will automatically downvote (nearly) any comment that contains a "downvote me if you want" or a "don't just downvote me if you disagree" or "these downvotes are BS" or something.
You're right, though, that not all users agree. And hopefully you learn from this comment that it's okay, on HN, to downvote me if you disagree, even if you think I contributed to the conversation.
PS: welcome to HN.
Besides, votes are used for agreement more than for any other purpose, and given that there's no way to force people to not do this, let's just dispense with the fiction that they can ever mean anything else. "Please no downvote" is just noise.
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.
I certainly don't think so. JavaScript is a language that works in more places now; commonized libraries would be a huge benefit. As an example you wouldn't use Python with different io libraries depending on the operating system it's running on and yet this is what node is evolving into.
> Like window.document.querySelectorAll in browser and require("fs") in node.js?
querySelector / querySelectorAll are specific to a browser platform but a way to conduct io could be pretty universal, in my opinion.
C++'s STL is part of its specification. Python has a library reference outlining the interfaces their standard libraries must include.
You're still thinking in browser world. In a browser world a browser is a platform and has to provide APIs to allow JavaScript to interact with its elements. Today this isn't always true. Today you have node.js and several other execution engines that allow JavaScript to run anywhere much like other languages. It's time the standard reflects that new reality, in my opinion.
What does ownership have to do with it?
That does not make him more right than any other human being.
Ownership means one can impose ones will, it does not mean you are omniscient.
No, just the only relevant person to say what is welcome and allowed in HIS social bookmarking forum and what's not.
>Ownership means one can impose ones will, it does not mean you are omniscient.
"House rules" are not meant to be perfect or agreeable to all -- they are just meant to be whatever those running and owing the house decide.
What does ownership have to do with it, you fucking moron?
That does not make him more right than any other human being. Ownership means one can impose ones will, it does not mean you are omniscient.
This is our website. Maybe pg 'made' it, but we use it. If most of us disagree that is what will (and should in my opinion) happen.
He can always close down the side.
Besides, it's not about "what is he going to do" -- it's about what people coming here should respect.
Therefore, what matters most in practice is the mass opinion of users of the site - what do we think is most useful and respectful in daily usage (following Paul Graham's lead to be respectful because we can all agree that this is a good idea).
I'd say "you fucking moron" besides rude, is grounds for killing your account.
As to the question, rules on any property, including a website, are usually imposed by the owner.
That's what "ownership" has to do with it.
There are moderators, and comment and submission rules in places. Maybe you conflated HN with some kind of self-governing collective?
>That does not make him more right than any other human being. Ownership means one can impose ones will, it does not mean you are omniscient.
You wrote that again and I already answered. Nobody cares about PG being omniscient. He can impose ANY arbitrary will (right or wrong), because it's his site. He can even close it if he gets bored with it. Whether you or I find any particular rule "right" is inconsequential, as we're guests here, not even customers.