The Final ES2015 (ES6) Draft(wiki.ecmascript.org)
wiki.ecmascript.org
The Final ES2015 (ES6) Draft
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#final_draft
75 comments
The right answer to the typography question is probably to just use the HTML version at http://people.mozilla.org/~jorendorff/es6-draft.html for all practical purposes.
IIRC, the particular formatting in the document is required by ECMA and the ES6 committee can't do much about it.
If someone in the know could give me a rough estimate of "When can I expect to be using ES6 to develop applications (at least for modern browsers)?", that'd be nice.
And I'm not talking Babel or any other tools like that, I'm talking straight up ES6.
And I'm not talking Babel or any other tools like that, I'm talking straight up ES6.
A good while yet, I'd expect; a lot depends on Windows 10 uptake. The browser-formerly-known-as-IE is currently running ahead of Chrome and FF on ES6 implementation, but if everyone sticks with Win7 for the next half decade it won't amount to much.
But seriously: use Babel.
But seriously: use Babel.
>The browser-formerly-known-as-IE is currently running ahead of Chrome and FF on ES6 implementation
Not according to Kangax's table.[0] Both Fx 39 and 40 beat out Edge, with 65%, 66% and 63% respectively.
[0] https://kangax.github.io/compat-table/es6/
Not according to Kangax's table.[0] Both Fx 39 and 40 beat out Edge, with 65%, 66% and 63% respectively.
[0] https://kangax.github.io/compat-table/es6/
Or better yet, use jspm with Babel and use ES6 modules for everything.
https://github.com/jspm/jspm-cli
https://github.com/systemjs/systemjs
https://github.com/jspm/jspm-cli
https://github.com/systemjs/systemjs
What's the benefit of jspm vs webpack (which is incredibly powerful, but sloppy IMHO right now).
I honestly haven't used webpack much myself, but I found these two threads on the topic:
https://github.com/jspm/jspm-cli/issues/335
https://github.com/jspm/jspm-cli/issues/844
According to those, SystemJS (jspm's module loader) has the following advantages:
- Able to load any type of module as any other type of module (global, CommonJS, AMD, ES6)
- Can handle transpilation and module loading at runtime without requiring a manual build step
However, jspm itself is primarily a package manager. Its main advantages over existing package management solutions are:
- The tight integration with the SystemJS module loader for ES6 usage
- The fact that it maintains a flat dependency hierarchy with deduplication
- The ability to override package.json configuration for any dependency
- Allows loading of packages from just about any source (local git repos, Github, NPM) as any module format
https://github.com/jspm/jspm-cli/issues/335
https://github.com/jspm/jspm-cli/issues/844
According to those, SystemJS (jspm's module loader) has the following advantages:
- Able to load any type of module as any other type of module (global, CommonJS, AMD, ES6)
- Can handle transpilation and module loading at runtime without requiring a manual build step
However, jspm itself is primarily a package manager. Its main advantages over existing package management solutions are:
- The tight integration with the SystemJS module loader for ES6 usage
- The fact that it maintains a flat dependency hierarchy with deduplication
- The ability to override package.json configuration for any dependency
- Allows loading of packages from just about any source (local git repos, Github, NPM) as any module format
That's why MS gives out Win10 for free: there are zero reasons to stick with 7.
Here are two big reasons: (1) The IT department controls what's on your PC. (2) You have no idea how computers work.
Yep, there are a lot of strange peripherals attached to computers that are no longer supported. Win XP and 7 will be around for a while yet.
Out local hospital is still using IE7 - that's a lot of PCs that aren't going to get upgraded any time soon (funding cuts.)
Out local hospital is still using IE7 - that's a lot of PCs that aren't going to get upgraded any time soon (funding cuts.)
It was my understanding that it wasn't that those things weren't "not supported" but that the drivers will no longer be included with the base install.
Stuff like off-the-wall scsi drivers, or floppy drivers, or serial port mouse support.
You can still download and install the drivers for those things, but they won't be there right away.
Stuff like off-the-wall scsi drivers, or floppy drivers, or serial port mouse support.
You can still download and install the drivers for those things, but they won't be there right away.
I don't know about Windows 10, but the driver model changed significantly with Windows Vista, so XP drivers actually will not work out of the box on newer versions of Windows. So if you're using a really old peripheral that isn't maintained anymore, chances are you won't be able to run it on a modern Windows machine.
[deleted]
I'm curious, assuming physical connections are still possible(i.e. ye olde COM/Serial port), how well do the use of VMs hold up in mission-critical processes such as these?
[deleted]
Yeah, for geeks, maybe. But, for common people, the reasoning is the opposite: there are zero reasons to switch.
I think most people saw the annoying little flag in the notification area letting users to "reserve" the upgrade, so here's your reason: it won't go away until you do upgrade.
Again, that would apply to the geek user: he would upgrade just to get rid of the annoyance.
Common people typically handle annoying things in the "computer" realm: browser toolbars, pop-ups, advertising, crapware, malware. Yet, they don't upgrade because it seems "complicated", it's "technical", or something like that.
We, IT professionals as a class, have a hell of a lot to gain just by talking and watching common users.
Common people typically handle annoying things in the "computer" realm: browser toolbars, pop-ups, advertising, crapware, malware. Yet, they don't upgrade because it seems "complicated", it's "technical", or something like that.
We, IT professionals as a class, have a hell of a lot to gain just by talking and watching common users.
There are not that many THAT "common people" anymore with regards to technology. And even them buy a new computer ever 5 or so years or have someone who knows take care of their installations.
> There are not that many THAT "common people" anymore with regards to technology
In HN? Surely. In our little and self-centered IT shell? Mos' def'.
If you worked with and studied users, your opinion would change. Updates in particular are interesting; most people postpone them ad aeternum.
In HN? Surely. In our little and self-centered IT shell? Mos' def'.
If you worked with and studied users, your opinion would change. Updates in particular are interesting; most people postpone them ad aeternum.
it won't go away until you do upgrade.
Sure it will. Just uninstall the Windows update KB3035583, and there it is, gone.
This is by far the most common question my less technical friends and family have been asking about their computers recently. I must have done this for 4 or 5 different people already, and entirely unscientifically it seems other technically inclined friends are getting the same request. It appears that I don't know a lot of people who actually want a new version of Windows on their existing, already working PC.
Personally, I've been recommending ignoring any Windows updates that are not explicitly security updates for quite some time now. Microsoft seem to have developed an unwelcome habit of pushing things out via that mechanism that might be in their own interests but aren't necessarily in the interests of the users.
Sure it will. Just uninstall the Windows update KB3035583, and there it is, gone.
This is by far the most common question my less technical friends and family have been asking about their computers recently. I must have done this for 4 or 5 different people already, and entirely unscientifically it seems other technically inclined friends are getting the same request. It appears that I don't know a lot of people who actually want a new version of Windows on their existing, already working PC.
Personally, I've been recommending ignoring any Windows updates that are not explicitly security updates for quite some time now. Microsoft seem to have developed an unwelcome habit of pushing things out via that mechanism that might be in their own interests but aren't necessarily in the interests of the users.
IDK, bringing back the start menu sounds pretty cool. Also MSFT will basically handicap anything that is not Windows 10 as well, so there's that...
In the real world organizations are still stuck on Windows XP and especially in large organizations it can take months or even years until everyone is upgraded.
Windows 10 being free matters to users at home and small businesses, it doesn't matter to anyone else.
Windows 10 being free matters to users at home and small businesses, it doesn't matter to anyone else.
As a Windows Media Center user, I beg to differ.
> But seriously: use Babel.
Ugh, I find this to be excruciating. So you read about some new cool technology on HTML5Rocks and you want to play around with it. You have to:
* npm init
* npm install babel --save
* npm install browserify/webpack/greatest-thing-ever-of-the-week --save
* npm install gulp/grunt/broccoli/other-task-runner --save
* vi (gulp/grunt/broc/other)file.js
* Write some code to build your application.
* vi myapp.js (write some code to do your thing)
* > (gulp/grunt/broc) build
* Write an html file that includes your bundled es5.
* Open it in the browser. Yay! Cool I can debug now... wait a second I made a mistake.
* vi myapp.js and fix mistake.
* > (gulp/grunt/broc) build
* Oops I made another mistake. Better set up a watch-mode so I don't have to keep running build.
* npm install some-watch-thing --save
* vi (gulp/grunt/broc/other)file.js
* Add your watch code
* > (gulp/grunt/broc) watch
* Yay I can finally just fucking code now.
Ugh, I find this to be excruciating. So you read about some new cool technology on HTML5Rocks and you want to play around with it. You have to:
* npm init
* npm install babel --save
* npm install browserify/webpack/greatest-thing-ever-of-the-week --save
* npm install gulp/grunt/broccoli/other-task-runner --save
* vi (gulp/grunt/broc/other)file.js
* Write some code to build your application.
* vi myapp.js (write some code to do your thing)
* > (gulp/grunt/broc) build
* Write an html file that includes your bundled es5.
* Open it in the browser. Yay! Cool I can debug now... wait a second I made a mistake.
* vi myapp.js and fix mistake.
* > (gulp/grunt/broc) build
* Oops I made another mistake. Better set up a watch-mode so I don't have to keep running build.
* npm install some-watch-thing --save
* vi (gulp/grunt/broc/other)file.js
* Add your watch code
* > (gulp/grunt/broc) watch
* Yay I can finally just fucking code now.
So, one more step than normal if you want to use npm dependencies in the browser, which is what you described.
If you're just playing with code, here's a simpler workflow:
* npm install babel
* write file.js
* run `babel-node file.js`
Similar to your example, the only extra step here is installing babel. If it's excruciating, install it globally and save yourself forever.
If you're just playing with code, here's a simpler workflow:
* npm install babel
* write file.js
* run `babel-node file.js`
Similar to your example, the only extra step here is installing babel. If it's excruciating, install it globally and save yourself forever.
Even better, just npm install -g babel once on any machine you use. Then it's ready for any and every .js file.
Ours is a .NET shop and we don't have plans to update to VS2015 in the near future. Does this workflow suggest that, in order to take advantage of Babel, we will have to install npm on all our dev machines and servers?
dev machines yes.
Well I have to run it every time I edit a file, maybe you missed the second half of my steps, so I still need a watch mode thingy which means probably a build script like virtually everyone using Babel is doing.
Regardless, vi index.html is much simpler.
Regardless, vi index.html is much simpler.
While I feel your pain, and have spent a stretch or two in life-sapping Grunt Hell, this is kind of a sunk cost: ie, all this setup fiddling is necessary anyway for linting, test runs and so on - not just for the new shiny.
So, IMHO, you may as well stick the new shiny in before/after JSHint while you're in the (gulp|grunt|broc)file.
So, IMHO, you may as well stick the new shiny in before/after JSHint while you're in the (gulp|grunt|broc)file.
> While I feel your pain, and have spent a stretch or two in life-sapping Grunt Hell, this is kind of a sunk cost: ie, all this setup fiddling is necessary anyway for linting, test runs and so on - not just for the new shiny.
It's not necessary, I'm just wanting to hack at some new API I read about on the web. Assuming I need to set up a test harness, CI, and linting is putting the cart well-before the horse.
It's not necessary, I'm just wanting to hack at some new API I read about on the web. Assuming I need to set up a test harness, CI, and linting is putting the cart well-before the horse.
* npm init
* npm i -S babel
* vi file.js
* first line: require('babel/register');
* Yay, now you can finally just fucking code now.
Learn your tools: https://babeljs.io/docs/usage/require/
Learn your tools: https://babeljs.io/docs/usage/require/
I have to bundle it to run it in the browser (or use babel in the client which has an entirely different set of problems). I know these tools very well.
Try running a server which watches for file changes and then automatically recompiles without server restart, preferbly configured in the server instead of a CLI. I couldn't be nearly as productive with any other setup.
Sounds like you need Lineman: http://linemanjs.com/
You can always just have a boilerplate ready and `gulp watch` from the start
* git clone 'boilerplate'
* npm i
* gulp watch
* Yay I can finally just fucking code now.
* git clone 'boilerplate'
* npm i
* gulp watch
* Yay I can finally just fucking code now.
Welcome to modern web development
Oh absolutely Babel is awesome, just wondering.
I am confident full ES6 support will be really solid by March 2017. However, the community is moving incredibly fast, some companies are already using ES7 / ES2016 features!
In perspective, transpilers aren't so bad, especially Babel, who's differentiating feature from the start was readable output code.
Today, if targeting modern browsers you can use Maps and Sets. With polyfills[1] you can use the new Array functions, Promises, Symbols, full JS collections, iterators, etc.
[1] https://github.com/zloirock/core-js
In perspective, transpilers aren't so bad, especially Babel, who's differentiating feature from the start was readable output code.
Today, if targeting modern browsers you can use Maps and Sets. With polyfills[1] you can use the new Array functions, Promises, Symbols, full JS collections, iterators, etc.
[1] https://github.com/zloirock/core-js
[deleted]
Why? What is the thing you can do in ES6 that you can't in ES5? Features that affect execution speed or real memory consumption positively. Leave hipster features out.
That's an extraordinarily reductive view of improvements to a programming language. A basic example: cleaner syntax for anonymous functions will have (presumably) almost no effect on speed/memory either which way, but will make code more readable. Which is not a 'hipster' concern.
It's the difference between
var map = function (f) {
return function (list) {
return list.map(f);
};
};
const map = f => list => list.map(f);Also: "this" is bound for you in fat arrow functions without having to resort to function.prototype.bind or "var that = this;" trickery. That's an issue I've seen bite many people before and it'll be nice to have an easy way to avoid that.
Upvoted your comment so that everyone can see it.
ES6 has template strings, destructuring assignment, Map and Set data structures (and more). While you're right and it is not NEEDED, this is something that dramatically improves on the weakest aspects of ECMASscript.
Based on your comment, it feels like no addition is ever a good addition if you can express it with the building bricks you already have. With such a way of seeing things, we'd all be coding with assembly language, cause nothing really affects speed or memory consumption for the better.
ES6 has template strings, destructuring assignment, Map and Set data structures (and more). While you're right and it is not NEEDED, this is something that dramatically improves on the weakest aspects of ECMASscript.
Based on your comment, it feels like no addition is ever a good addition if you can express it with the building bricks you already have. With such a way of seeing things, we'd all be coding with assembly language, cause nothing really affects speed or memory consumption for the better.
No-no, there has been lot of features added to Javascript (i started writing it around 2003) that were not shimmable in earlier versions.
One reason to rule them all:
Generator functions.
Why it is a big deal one might ask. It is the BIGGEST deal in history of Javascript in my book because it allows you to do async that looks sync. No more callback hell. It is the single most important feature, as it eliminates async issues completely. And EVERYTHING in js is async. But in reality, you want to drop into async only sometimes. Now you are forced into it 100% time, even when you need the result of async call to decide what to do next. It gets tricky really fast.
Why it is a big deal one might ask. It is the BIGGEST deal in history of Javascript in my book because it allows you to do async that looks sync. No more callback hell. It is the single most important feature, as it eliminates async issues completely. And EVERYTHING in js is async. But in reality, you want to drop into async only sometimes. Now you are forced into it 100% time, even when you need the result of async call to decide what to do next. It gets tricky really fast.
I guess to each their own then. I really just want the new syntax features, modules, classes, const,maybe template strings will be nice too. I work with async ES5 code all the time and I don't have many problems with async when using promises. I know promises are also coming with ES6, but almost everyone uses them today in ES5.
Well promises help. And then they stop :). Stop helping. They just break under the weight. If you have promise chain that gets too long, you will feel the pain.
The whole thing is, when some IO returns 1 or 2. And your next step is to do a or b depending on the reply. How is your neat promise chain looking now? Then repeat 100 times :(
Not even mentioning error handling... and stack traces.
So i do agree that it depends what you do a lot. Maybe there are domains where it is not important... but i still need to see that one.
And i will take blocking IO with try/catch 10 times out of 10. Even when it is not critical. It is just nicer and easier to reason about.
The whole thing is, when some IO returns 1 or 2. And your next step is to do a or b depending on the reply. How is your neat promise chain looking now? Then repeat 100 times :(
Not even mentioning error handling... and stack traces.
So i do agree that it depends what you do a lot. Maybe there are domains where it is not important... but i still need to see that one.
And i will take blocking IO with try/catch 10 times out of 10. Even when it is not critical. It is just nicer and easier to reason about.
require('bluebird').coroutine function*() {}
Promises + Generators = The sweet spot.
Check out https://www.npmjs.com/package/coroutiner to make it stupid-easy to coroutine your entire app.
Promises + Generators = The sweet spot.
Check out https://www.npmjs.com/package/coroutiner to make it stupid-easy to coroutine your entire app.
That is one perfectly fine way to do it. But that is exactly what i want to highlight. The generators. You can combine them with promises, callbacks, even the CSP channels. But you need the generator. That is where magic happens and no amount of library code will do that for you, one needs compiler support (or a macro...)
Promises are certainly better than promise-free 2005 style callback code, but they do require that you reimplement language features like try/catch. Yield allows you to do asynchronous try/catch, which doesn't depend on some library getting the implementation right (libraries often lump rejections and thrown exceptions together) and looks more sensible anyway.
There are other advantages to yield as well. Entire design patterns like CSP aren't possible without it.
There are other advantages to yield as well. Entire design patterns like CSP aren't possible without it.
Proxies. You can't shim in the Proxy object. Ain't no hipster feature there.
You can't even transpile it without massively different output from the transpiler, which is a bit bad.
Map and set are much nicer in ES6 as built in objects.
imo map and set useless. Real advantage of maps only that you can use any type of keys, but really why not convenrt them to string represntation and put to simple object? Map .has method uses === for object search. For set the same, just use object with keys and dummy values.
New Safari (in iOS 9 and next OS X) will support most of the ES 6 features. I guess it depends on what you're developing for.
Even the latest Webkit is only on 50% on Kangax’s support table. I suppose that’s better than latest Chrome (45%) but much worse than latest IE (63%) or latest Firefox (66%).
To be completely fair, most of the Chrome ES6 features are disabled via command line flag for now. When they are ready (and stable) they will all be enabled at once, and the vast majority of people will get the update within a few weeks at most.
IE is at 14%. Microsoft Edge is at 63% and it will be updated in 6 week sprints like Chrome supposedly.
Unlike Google or Firefox or Microsoft (who is now shamed into competing) there is no incentive for Apple to be aggressive with their ES6 implementation. Safari will remain handicapped for another year, while the other browsers slowly but surely get full support. At least we only have to wait a year (Like we did for most old CSS properties to become unprefixed).
Unlike Google or Firefox or Microsoft (who is now shamed into competing) there is no incentive for Apple to be aggressive with their ES6 implementation. Safari will remain handicapped for another year, while the other browsers slowly but surely get full support. At least we only have to wait a year (Like we did for most old CSS properties to become unprefixed).
What incentive does Google or Firefox have for adopting ES6? How is it different to Apple?
But I agree with the sentiment - when every other browser is on multiple releases a year (Chrome at a release every 6 weeks!!!), it really is archaic when Safari is releasing only once a year.
I would love to see WebKit updates to Safari in the iOS and OS X point releases. I guess it comes down to Apple wanting to remain 'API stable' within each major OS release.
But I agree with the sentiment - when every other browser is on multiple releases a year (Chrome at a release every 6 weeks!!!), it really is archaic when Safari is releasing only once a year.
I would love to see WebKit updates to Safari in the iOS and OS X point releases. I guess it comes down to Apple wanting to remain 'API stable' within each major OS release.
Chrome went to a release every 5 weeks, Firefox stayed on a 6 week cycle.
The Final ES1015 (ES6) Draft
Am I the only one noticing the oxymoron there?
Am I the only one noticing the oxymoron there?
No. "Final Draft" is a very standard term in books/scripts/standards/legal docuemnts/etc (actually there's even a scriptwriting app bearing that name).
It's the final draft as in "the last in the series of draft revisions", meaning than after that the actual standard document is going to be voted / published -- at worse with very minor last minute corrections.
It's the final draft as in "the last in the series of draft revisions", meaning than after that the actual standard document is going to be voted / published -- at worse with very minor last minute corrections.
I believe thats exactly what it is - the latest revision of the document that will go on to be voted on and accepted.
>This draft has been submitted to the Ecma General Assembly members for their review and consideration. The GA will vote on approving it as a Ecma standard at their June 2015 meeting.
>Assuming GA approval, it will still be possible to make very minor editorial corrections in the published version.
>This draft has been submitted to the Ecma General Assembly members for their review and consideration. The GA will vote on approving it as a Ecma standard at their June 2015 meeting.
>Assuming GA approval, it will still be possible to make very minor editorial corrections in the published version.
I get documents from designers with names like "FINAL homepage v23 latest updated FINAL_2 (3).psd" all the time...
Expect the Final Final pre-Release post-Draft. ES6 will never get released.
It already is released: http://www.ecma-international.org/publications/standards/Ecm...
On a slightly churlish note, the typography / graphic design of the standardisation document is absolutely horrid. From the color choices, to the (many) fonts, to the early 90s type treatment to the fake laid paper texture on the cover to inconsistent spacing inside. Shiver. Okay, superficial, but only slightly so. I genuinely think that type and book design is important for communication.