Toward Modern Web Apps with ECMAScript 6

http://www.sencha.com/blog/toward-modern-web-apps-with-ecmascript-6/

by jacobr • 13 years ago

92 52 13 years ago

sencha.com

kaoD• 13 years ago

So... CoffeeScript with curly braces?

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

aa02• 13 years ago

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.

camus2• 13 years ago

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

jameswyse• 13 years ago

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.

a-l-c-o• 13 years ago

I wonder why even play with them until ES6 features are confirmed (though it feels like they will).

It's very interesting and tempting but would end up as a loss of time if they are not.

apaprocki3• 13 years ago

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

pjmlp4• 13 years ago

Mobile is what matters nowadays.

jacobr• 13 years ago

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

apaprocki3• 13 years ago

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

egeozcan3• 13 years ago

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

marshray• 13 years ago

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

camus2• 13 years ago

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.

kevingadd5• 13 years ago

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

coldtea2• 13 years ago

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.

masklinn2• 13 years ago

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• 13 years ago

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.

pjmlp4• 13 years ago

Sadly this is like any standard in the IT world.

Just look how long C++11 took to finish or the features that are being discussed for C++17.

Or the first C standard 1989, when the language existed since 1972. Or how many C compilers, commercial and open-source, implement C11.

Many many other examples are possible.

pornel• 13 years ago

no need to move faster, please participating companies, take your time debating BS pedantic distinctions until the spec is finalized.

OTOH if things are rushed then you end up with underdefined oddities and weird effects of things that seemed sensible: http://wtfjs.com/page/13

coldtea2• 13 years ago

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.

gdwatson• 13 years ago

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.

ahoge• 13 years ago

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.

TypeScript is very similar.

apaprocki3• 13 years ago

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• 13 years ago

Relevant: https://code.google.com/p/v8/wiki/Contributing

taf22• 13 years ago

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• 13 years ago

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.

taf22• 13 years ago

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

rpedela4• 13 years ago

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.

kevingadd5• 13 years ago

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.

rpedela4• 13 years ago

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

nonchalance• 13 years ago

solutions like http://code.google.com/p/closure-library/source/browse/closu... have been in use for many years.

rpedela4• 13 years ago

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

Toward Modern Web Apps with ECMAScript 6

Related Stories