A better title would be "Towards old age, waiting for ECMAScript 6".
It's only been like 10 years already (since those features were promised for ES4), no need to move faster, please participating companies, take your time debating BS pedantic distinctions until the spec is finalized. Then it would only take 3-4 years until it has around 90% penetration so it can be used.
It's not like 14-15 years is a lot of time in technology. Perhaps only one generation of web programmers will have retired by then.
The issue being, of course, that a standard which is not implemented is of little use.
Last time around, a few stakeholders (mostly MS, but also Yahoo and Google) managed to railroad the proposal completely resulting in the watered down ECMAScript 5.
But this is the sort of basic functionality that shouldn't be coming in a standard nearly 20 years after the language was first released. This is especially true when other languages have had such functionality since before JavaScript was conceived. It's not like they're new concepts that post-date JavaScript's creation.
ECMAScript 4 had to be dropped when people realized that turning JavaScript into a JS-Java hybrid increased complexity rather than decreasing it. But the process of drafting ES4 and then disputing whether to go forward took a lot of time.
And don't forget that IE6 was Microsoft's latest and greatest for a long time, with little prospect of an upgrade. When IE progress was frozen with huge market share, the prospect of updating JS seemed like a pipe dream.
>ECMAScript 4 had to be dropped when people realized that turning JavaScript into a JS-Java hybrid increased complexity rather than decreasing it.
AS3 (which completely conforms with the ES4 draft specification) is a lot nicer to use than JavaScript (ES5.1 included). It gives you means to organize your code and your tools also have a clue what you're doing.
I'd rather live working around some oddities than with nothing at all.
But it's a false dichotomy, I'd say: nothing prevents them from being more agile and correcting any issues that is found in the spec in a dot update. A few people will have to update their code, or use some conditional code, big fucing deal.
Or they could, you know, provide a reference implementation -- e.g working with Mozilla or anyone interested.
Release it as an opt-in engine (e.g with something like "use strict") fix any issues that arise for 1-2 years, and make it a finalized standard from the on.
I'm expecting top comments will wind up being a bit negative because of how long it takes to modify a living language without breaking the web (spec side). But for ES6, the main thing in need right now is C++ programmers able to hack on VMs to actually implement all the features. If you are one and care about this, by all means see where you can help in V8/SM. If you're a company that cares but only has dollars, and not programmers/time, consider hiring consultants to work on landing the features you are most interested in. Just because a spec is fleshed out by committee over time doesn't mean the patches magically appear with it. (e.g. C++11)
CoffeeScript is a debauchery of JS. With ECMAScript 6 you won't need CoffeeScript for anything except maybe it's inline printf-like string substitution.
Don't use "objects". Embrace the associative array that is a JSON (I know, Object is in the name) construct. Getters and setters are not necessary with this.
How does using associative arrays reduce the need for non-trivial getters and setters? I see how it provides an alternative to trivial getter and setter pairs; just as using bare public data fields in a language that supports them does, but non-trivial or non-paired (getter or setter alone) or different visibility ones seem to be a different issue.
My belief is that in a functional language like JS, you shouldn't couple data with operations on itself. As a result, all you'd ever have is non-trivial getters and setters. You see this with map like constructs in Erlang. You'd have a function that takes a map and does stuff.
Systems built with large teams need to have their developers negotiate API boundaries. Strict typing and intelligent getters/setters help a great deal to achieve this because the code becomes self-negotiating. A second problem with large teams is that most programmers can't write pure functional code, turning the codebase into a hybrid mess. ES6 matters most for large teams because the inefficiencies of ES5 are felt most on those kinds of scale.
I'm also doubtful how well DOM programming can be mixed with a functional approach, but i'll concede that it is at a minimum possible to do it.
I don't think it's true that most programmers can't write pure functional code; I think it is more the case that that most programming languages don't provide good support -- particularly constructs that make the distinction between pure and impure code clear -- for programmers who wish to write pure functional code or at least to cleanly segregate pure and impure code.
When I'm writing code, getters and setters are a huge help for abstraction. I won't give up using a feature only because it's not the "convention". Look at the trouble frameworks like angular and knockout go through (secondary event loop, calling functions for assignments...) because some browsers do not support getters and setters. I can use them on the server side at least.
Andy Wingo is working on generators in SpiderMonkey now that he landed them in V8. Goal is to get FF/Chrome parity. (If anyone on the IE team is reading...)
We are forced to use only JavaScript features that are available on the system browsers of the mobile platforms, when doing web projects for mobile platforms.
So it does not matter what Firefox or Chrome support on the desktop, if those features are not widespread on the mobile platforms.
Are the mobile editions of Chrome and Firefox far behind in their Javascript support? I was under the impression that those two were pretty much up to speed with their desktop versions.
You can play with them just now in 0.11.2 if you run node with --harmony or --harmony-generators. Can't really use them in modules until it's in core though.
Will ES6 have native support for 64-bit integers and arbitrary-precision numbers? Or at least 64-bit integers? To me, this is the biggest, fundamental problem with Javascript.
Yeah there are plenty of JS libraries for large numbers, but all of them are a bit of a hack. They are not as fast as native compiler/interpreter support, and there is no obvious way to integrate the logic into other native functions such as JSON.parse and JSON.stringify. So you have to create your own JSON parser which is not as fast like I did: https://github.com/datalanche/json-bignum
That is fine if the JSON consumer and producer are Javascript. What happens when the producer is a language that handles large numbers correctly? The numbers are rounded in Javascript.
Not really. There aren't regular updates to IE adding new functionality from the living HTML5 standard (and other standards). Further, the latest IE cannot be installed on some older, yet still popular, versions of Windows. These two factors combined means that a lot of people don't have a modern up-to-date IE.
The current update frequency for IE is a dramatic improvement over older versions.
The fact that you can't install IE11 on Windows 2000 is irrelevant. I can't install Safari on my Windows machine anymore either, and it's still a HTML5 browser (albeit a bad one, the last time I tried it on a Mac).
Users not installing updates isn't relevant either.
IE is a perfectly respectable HTML5 browser. It runs my HTML5 games better than Opera or Safari and has fairly comprehensive support for non-bleeding-edge features, especially if you look at 11 (coming out soon, I believe).
> The current update frequency for IE is a dramatic improvement over older versions.
Obviously an update frequency of 1 year is a dramatic improvement over an update frequency of 5 years, but still is not enough. Basically it means "if a feature is not present in IE11, wait a year, or two".
the use of const in node.js at least can be used today and I think should be for all required modules... for example, it's always bothered me in node.js that most examples are written in the following way:
var fs = require('fs');
fs is such an easy name to give to any random variable in a function
function foo() {
var fs = 88; // just overwrote fs module..
}
I do two things in my non-standard way...
const FS=require('fs');
it makes more sense to me... i'm less likely to write in a random function:
function foo() {
var FS = 88;
}
Just my thought... node.js supports const for a long time I wish examples would use it for required modules...
But your first example doesn't overwrite fs, it just overwrites the use within that function scope. Which is what you want (to use the fs that you assigned). Outside that function fs is still fs.
const is really just a readonly. It would prevent you from accidentally overwriting fs if you were to forget to type var at some point.
More needs to be written about when to use const, because there isn't much explanation for it out there. It seems like engines can better optimize some code if it knows certain variables won't be reassigned. But in that case you mind up always using const, which I doubt is correct either. There has to be some overhead to using const, so you probably wouldn't want to use it in a tight loop, for example. Or maybe I'm all wrong about this. Need some writing.
My example, was perhaps too simple seeing how the functions are very short... I'm sure someone will mention making long functions is a bad idea... but it happens... using const for required modules seems like a simple rule to follow for avoiding trouble... Also, stylistically using an uppercase lettering while not normal in node.js community is normal to JS in other contexts... jQuery... getElementById.. perhaps Fs if you prefer however looking through mozilla code as a guideline - variables declared const are uppercase... hence FS makes better sense to me... because why would a module variable name ever not be... and in the rare case that it is.. declare it var at least until let is available...
It's only been like 10 years already (since those features were promised for ES4), no need to move faster, please participating companies, take your time debating BS pedantic distinctions until the spec is finalized. Then it would only take 3-4 years until it has around 90% penetration so it can be used.
It's not like 14-15 years is a lot of time in technology. Perhaps only one generation of web programmers will have retired by then.