It is so good to see ES moving again, after a decade in the wilderness. EC5 wasn't an aberration, and there are lots of productivity improvements in this and coming in ES7. A big thankyou and congratulations to the people who worked so hard on this. The work of a standardisation committees is often a thankless task.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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?
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.
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.
> 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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.