The Final ES2015 (ES6) Draft
wiki.ecmascript.org
wiki.ecmascript.org
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.
And I'm not talking Babel or any other tools like that, I'm talking straight up ES6.
But seriously: use Babel.
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.)
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.
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.
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.
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.
Windows 10 being free matters to users at home and small businesses, it doesn't matter to anyone else.
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.
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.
Regardless, vi index.html is much simpler.
So, IMHO, you may as well stick the new shiny in before/after JSHint while you're in the (gulp|grunt|broc)file.
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.
Learn your tools: https://babeljs.io/docs/usage/require/
* git clone 'boilerplate'
* npm i
* gulp watch
* Yay I can finally just fucking code now.
Not according to Kangax's table.[0] Both Fx 39 and 40 beat out Edge, with 65%, 66% and 63% respectively.
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
var map = function (f) {
return function (list) {
return list.map(f);
};
};
const map = f => list => list.map(f);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.
Because as soon as you might have "toString" or "__proto__" as a key things go all haywire.
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.
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.
Promises + Generators = The sweet spot.
Check out https://www.npmjs.com/package/coroutiner to make it stupid-easy to coroutine your entire app.
There are other advantages to yield as well. Entire design patterns like CSP aren't possible without it.
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).
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.
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.
Am I the only one noticing the oxymoron there?
>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.
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.