7 ms·
When a native Promise incurs a rejection but there is no handler to receive it, a warning will be printed to standard error. Probably the most important change
by dcgudeman 10y ago
When a native Promise incurs a rejection but there is no handler to receive it, a warning will be printed to standard error.
Probably the most important change other than improvements in es2015 support.
- wmichelin 10y agoSounds like a step in the right direction!
- CSDude 10y agoI wish the browsers moved on with the support as fast as Node so that we can get rid of stupid hundreds of MBs dependencies to transform a arrow function.
- minitech 10y agoBrowsers already support arrow functions (and did before Node), but there’s no reason to break compatibility with old browsers just to get arrow functions. If that’s the only thing you’re transforming, my advice would be to stop and just use function () {}.
- TAForObvReasons 10y ago> we can get rid of stupid hundreds of MBs dependencies to transform a arrow function. Depending on your target market, you may be stuck on ES5. Your users' browser behavior determines when you can remove the shims and transforms, and if they aren't upgrading you can't really force them to upgrade the browsers.
- komali2 10y ago>force them to upgrade their browsers Please yes
- tracker1 10y agoThe engine that Node is using is already in chrome, and iirc all the major current versions of browsers already have 97% support (tail call opts withstanding, I think for safari this is still a vNext issue). You can use one of a number of modern targets which will avoid the need for the various polyfils etc... but if you need current safari and any IE support, you will at least need dual build paths, which isn't too bad. I kind of wish there was a babel preset that was meant to be used in conjuction with Financial Times' polyfill.io
- hzoo 10y agoI've been working on https://github.com/babel/babel-preset-env/ https://github.com/babel/babel-preset-env/ and there's a similar request although using babel-polyfill rather than the service https://github.com/babel/babel-preset-env/issues/20 https://github.com/babel/babel-preset-env/issues/20
- qaq 10y agoHmm Node is trailing chrome what exactly are you talking about?
- BinaryIdiot 10y agoSo two things. First, it doesn't matter how fast browsers moved. Currently they're moving pretty damn quick if you ask me but it doesn't matter because you need to know your audience and what browser(s) they use. Second, I don't understand the want or need to include "hundreds of MBs dependencies to transform a arrow function". Why do you have to use an arrow function? Yeah it looks nicer but if you're complaining about how much dependency it brings in why not just not use it? Don't get me wrong I like ECMAScript 2015 but if you don't want to bring in the huge amount of transpiler dependencies ECMASCript 5 is still super easy to write.
- algesten 10y agoExactly my point. Arrow functions and destructuring assignments are great, but we've put up with function() { ... } for the last 20 years, so I'm pretty certain we can wait a couple of more years and not get bogged down in these crazy tooling chains to achieve so little. and if we insist on crazy tooling chains, how about getting some real benefit – like coffeescript (?-operator anyone) or typescript (yes, typing can help, just look at swift)?
- tiglionabbit 10y agoThey do. Try writing an arrow function into your browser's console right now. http://caniuse.com/#feat=arrow-functions http://caniuse.com/#feat=arrow-functions
- nilliams 10y agoYes, this footgun is why I've been really wary of the of the `fetch()` plus es6-promise polyfill bandwagon. I've been giving that a wide berth. Examples why: - http://requirebin.com/?gist=8f13d5147c1c252ab1691115bfa8b7c5 http://requirebin.com/?gist=8f13d5147c1c252ab1691115bfa8b7c5 - http://requirebin.com/?gist=06e8c85fcaca56c9651c6aabd0d91476 http://requirebin.com/?gist=06e8c85fcaca56c9651c6aabd0d91476
- tracker1 10y agohow is that any different than any other ignoring of potential errors... fs.saveFile(file, function(err){}); I'd spent most of the last month dealing with a codebase that ignored potential errors systematically... which was a HUGE problem when you WANT to throw an error down that hole... "turtles all the way down" and they're eating all the errors. It's not limited to Promises, or even unique.
- nilliams 10y agoBecause it's not just an 'ignoring of errors', it's the fact all exceptions (as in actual errors from the runtime) are silently swallowed. In your example, if you typo in that function body, an exception will be thrown, your program will exit and you will see the stacktrace. var fs = require('fs'); fs.writeFile('foo.data', function(err){ // A typo here will lead to an exit and stacktrace sadsad }); Whereas in the Promise examples it is quite literally silently swallowing ALL exceptions thrown, including typos etc. It is limited to Promises, because they're supposed to help us deal with error propagation, and pass exceptions through to `.catch()` handlers. But if that catch handler is missing, crickets, even for outright invalid code. That doesn't happen with any other construct in JS afaik.
- WorldMaker 10y agoIn that example the same error gets thrown with a Promise because you're talking about mostly a JIT error at file load time. (Promise.resolve().then(() => I am a syntax error)) The parent's point is that you still aren't doing anything with the callback errors (that first parameter to most node-style callbacks) and those silent swallows are a lot harder to deal with than Promise's silent swallows because node callback error handling is a convention that is easily missed/forgotten/ignored, whereas Promises always "bubble" exceptions "down the chain" and fixing global unhandled exception handlers in Promises is a lot easier (and done at a platform level) than fixing a codebase full of bad node-style callbacks.
- aroc 10y agoI came to the comments section to post this exact comment. This is a hugely impactful change! Super happy to see this land.
- scrabble 10y agoBluebird already has this, and is more efficient than native. But this is definitely a step forward.
- m1sta_ 10y agoI'm not debating the point, but how is that possible?
- sotojuan 10y agoI'm not sure how it's possible but it's definitely not rare. Lodash' methods are faster than their respective native implementations (Lodash `map` > `Array.prototype.map`).
- STRiDEX 10y agohttp://programmers.stackexchange.com/questions/278778/why-are-native-es6-promises-slower-and-more-memory-intensive-than-bluebird http://programmers.stackexchange.com/questions/278778/why-ar... I'm not sure all of it still stands. Bluebird is in C. Native is in javascript. Edit: i'm wrong
- deleted 10y ago[deleted]
- bananaoomarang 10y agohttps://www.reaktor.com/javascript-performance-fundamentals-make-bluebird-fast/ https://www.reaktor.com/javascript-performance-fundamentals-...