8 ms·
Toward Modern Web Apps with ECMAScript 6
- kaoD 13y agoSo... CoffeeScript with curly braces? On a more serious take: as a Node.js developer I can't wait for generators to be ubiquitous!
- aa0 13y agoCoffeeScript 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 13y agoCoffeescript saved JS dev. It proved we did not have to wait for TC39 lto get new language features.
- egeozcan 13y agoMeh. It doesn't even support getters and setters.
- virmundi 13y agoDon'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 13y agoHow 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 13y agoMy 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 13y agoSystems 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 13y agoI 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.
- egeozcan 13y agoWhen 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.
- aa0 13y agoEmscripten is far more worthy of the phrase 'saved JS dev.'
- jameswyse 13y agoYou 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 13y agoI 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.
- deleted 13y ago[deleted]
- apaprocki 13y agoAndy 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...)
- pjmlp 13y agoMobile is what matters nowadays.
- portmanteaufu 13y agoThis seems like a non-sequitur. Could you clarify?
- pjmlp 13y agoWe 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.
- portmanteaufu 13y agoAre 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.
- pjmlp 13y agoThis 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.
- jacobr 13y agoHere 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/
- marshray 13y agoMore ways in which Javascript is sucking dramatically less from the language perspective.
- camus 13y agofront 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 13y agoIE's been a solid HTML5 browser for a couple years now. As good as Opera or Safari, certainly.
- ht_th 13y agoNot 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 13y agoThe 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 13y ago> 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".
- coldtea 13y agoA 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 13y agoThe 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 13y agoBut 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 13y agoSure, but it's not like that's a rare occurrence (behold HN's darling Go)
- pjmlp 13y agoSadly 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 13y 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 http://wtfjs.com/page/13
- apaprocki 13y agoI'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 13y agoRelevant: https://code.google.com/p/v8/wiki/Contributing https://code.google.com/p/v8/wiki/Contributing
- taf2 13y agothe 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 13y agoBut 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 13y agoMy 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...
- rpedela 13y agoWill 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 13y agoSigned/unsigned 64-bit integers are on the agenda, but I think they are planned for ES7. They're being prototyped in SpiderMonkey right now.
- nonchalance 13y agosolutions like http://code.google.com/p/closure-library/source/browse/closure/goog/math/long.js http://code.google.com/p/closure-library/source/browse/closu... have been in use for many years.
- rpedela 13y agoYeah 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 https://github.com/datalanche/json-bignum
- Raphael 13y ago