
Toward Modern Web Apps with ECMAScript 6 - jacobr
http://www.sencha.com/blog/toward-modern-web-apps-with-ecmascript-6/
======
coldtea
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.

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

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

~~~
masklinn
Sure, but it's not like that's a rare occurrence (behold HN's darling Go)

------
jacobr
Here is a list of current browser support for ES6 features:
[http://kangax.github.io/es5-compat-
table/es6/](http://kangax.github.io/es5-compat-table/es6/)

~~~
apaprocki
I think the chart needs updating -- generators landed in Chrome, which is why
they're in Node Harmony.

~~~
egeozcan
I actually am using them in a production node.js server so it better has
support =)

------
apaprocki
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)

~~~
davedx
Relevant:
[https://code.google.com/p/v8/wiki/Contributing](https://code.google.com/p/v8/wiki/Contributing)

------
kaoD
So... CoffeeScript with curly braces?

On a more serious take: as a Node.js developer I can't wait for generators to
be ubiquitous!

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

~~~
camus
Coffeescript saved JS dev. It proved we did not have to wait for TC39 lto get
new language features.

~~~
egeozcan
Meh. It doesn't even support getters and setters.

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

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

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

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

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

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

~~~
kevingadd
Signed/unsigned 64-bit integers are on the agenda, but I think they are
planned for ES7. They're being prototyped in SpiderMonkey right now.

~~~
rpedela
That is great to hear! Of course if ES7 takes another 10 years...

~~~
kevingadd
I'm as impatient as you are :) Emulating 64-bit integers is pretty slow in
modern runtimes...

------
marshray
More ways in which Javascript is sucking dramatically less from the language
perspective.

~~~
camus
front dev will always suck since Microsoft decided an entire generation of OS
will never have a modern browser by default. And yes this is MS fault.

~~~
kevingadd
IE's been a solid HTML5 browser for a couple years now. As good as Opera or
Safari, certainly.

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

~~~
kevingadd
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).

~~~
Aldo_MX
> _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".

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

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

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

