Toward Modern Web Apps with ECMAScript 6(sencha.com)
sencha.com
Toward Modern Web Apps with ECMAScript 6
http://www.sencha.com/blog/toward-modern-web-apps-with-ecmascript-6/
53 comments
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.
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.
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.
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.
Sure, but it's not like that's a rare occurrence (behold HN's darling Go)
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.
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.
TypeScript is very similar.
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.
> 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
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
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.
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.
Here is a list of current browser support for ES6 features: http://kangax.github.io/es5-compat-table/es6/
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)
So... CoffeeScript with curly braces?
On a more serious take: as a Node.js developer I can't wait for generators to be ubiquitous!
On a more serious take: as a Node.js developer I can't wait for generators to be ubiquitous!
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.
Coffeescript saved JS dev. It proved we did not have to wait for TC39 lto get new language features.
Meh. It doesn't even support getters and setters.
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'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.
Emscripten is far more worthy of the phrase 'saved JS dev.'
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...)
Mobile is what matters nowadays.
This seems like a non-sequitur. Could you clarify?
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.
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.
This does not work like that. It is the same thing as with IE 6.
You cannot assume everyone has a mobile device with the latest Firefox or Chrome version installed.
Most people only use the system browser, which can be whatever Webkit version depending on the iOS or Android version, Bink or mobile IE.
Some people might install the mobile versions of Firefox.
So as always, one is quite constrained if the goal is to target any mobile device with the same codebase.
You cannot assume everyone has a mobile device with the latest Firefox or Chrome version installed.
Most people only use the system browser, which can be whatever Webkit version depending on the iOS or Android version, Bink or mobile IE.
Some people might install the mobile versions of Firefox.
So as always, one is quite constrained if the goal is to target any mobile device with the same codebase.
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.
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.
It's very interesting and tempting but would end up as a loss of time if they are not.
[deleted]
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.
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.
solutions like http://code.google.com/p/closure-library/source/browse/closu... have been in use for many years.
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
If you want to use native JSON, store it as an object with a string.
{ "small": 2, "large": { "bignum": "-9223372036854775807.4237482374983253298159" } }
Then make sure to replace or treat the object as a big number. Granted, it is more busywork.
{ "small": 2, "large": { "bignum": "-9223372036854775807.4237482374983253298159" } }
Then make sure to replace or treat the object as a big number. Granted, it is more busywork.
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.
More ways in which Javascript is sucking dramatically less from the language perspective.
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.
IE's been a solid HTML5 browser for a couple years now. As good as Opera or Safari, certainly.
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 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".
Microsoft clearly did not make IE a business priority to the extent that Google has with Chrome, and obviously Mozilla with their flagship.
Whether or not they could do better is separate from the question of whether it's a browser that can handle modern sites and applications. It can.
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...
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.
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.