{"action":"created","issue":{"url":"https://api.github.com/repos/iojs/io.js/issues/11","labels_url":"https://api.github.com/repos/iojs/io.js/issues/11/labels{/name}","comments_url":"https://api.github.com/repos/iojs/io.js/issues/11/comments","events_url":"https://api.github.com/repos/iojs/io.js/issues/11/events","html_url":"https://github.com/iojs/io.js/issues/11","id":50414959,"number":11,"title":"Feature Request: Every async function returns Promise","user":{"login":"pragmadash","id":887952,"avatar_url":"https://avatars.githubusercontent.com/u/887952?v=3","gravatar_id":"","url":"https://api.github.com/users/pragmadash","html_url":"https://github.com/pragmadash","followers_url":"https://api.github.com/users/pragmadash/followers","following_url":"https://api.github.com/users/pragmadash/following{/other_user}","gists_url":"https://api.github.com/users/pragmadash/gists{/gist_id}","starred_url":"https://api.github.com/users/pragmadash/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pragmadash/subscriptions","organizations_url":"https://api.github.com/users/pragmadash/orgs","repos_url":"https://api.github.com/users/pragmadash/repos","events_url":"https://api.github.com/users/pragmadash/events{/privacy}","received_events_url":"https://api.github.com/users/pragmadash/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/iojs/io.js/labels/discuss","name":"discuss","color":"02d7e1"},{"url":"https://api.github.com/repos/iojs/io.js/labels/future","name":"future","color":"e102d8"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":180,"created_at":"2014-11-29T04:33:13Z","updated_at":"2015-02-04T01:50:09Z","closed_at":null,"body":"Now in node we have callback or EventEmitter model to deal with async calls by default. But in my opinion it is better if every async function returns a native Promise (from new version of V8). \r\nIt does not break backward compatibility and supports optional callback if needed.\r\n\r\nIf so we just do not need to install additional package for promises like q or bluebird except additional functionality is needed.\r\n\r\n---------------------------------------------------------------------------\r\n\r\n***EDIT 2014-12-11 by @rvagg***\r\n\r\n*Comment lifted from [here](https://github.com/iojs/io.js/issues/11#issuecomment-66615563) so it's easier to see for newcomers to this conversation.*\r\n\r\nThis was discussed at the TC meeting yesterday, see #144, the aim was to be able to provide at least some kind of statement as feedback in this issue. I don't think the issue needs to be closed and can continue to collect discussion from those who feel strongly about this topic.\r\n\r\nThe feedback from the TC about incorporating a Promises-based API in core goes something like this:\r\n\r\n**A Promises API doesn’t make sense for core _right now_ because it's too early in the evolution of V8-based promises and their relationship to other ES* features. There is very little interest within the TC in exploring this in core in the short-term.**\r\n\r\n**However, the TC is open to change as the feature specifications and implementations in ES6 and ES7 are worked out. The TC is open to experimentation and providing the most optimal API for users, which may potentially include a Promises-based API, particularly if newer features of JavaScript work most optimally in conjunction with Promises. The speed of the language specification process and V8 implementation will mostly dictate the timeline.**\r\n\r\n**It should be noted that a callback API is unlikely to ever go away.**\r\n\r\n---------------------------------------------------------------------------"},"comment":{"url":"https://api.github.com/repos/iojs/io.js/issues/comments/72775518","html_url":"https://github.com/iojs/io.js/issues/11#issuecomment-72775518","issue_url":"https://api.github.com/repos/iojs/io.js/issues/11","id":72775518,"user":{"login":"benjamingr","id":1315533,"avatar_url":"https://avatars.githubusercontent.com/u/1315533?v=3","gravatar_id":"","url":"https://api.github.com/users/benjamingr","html_url":"https://github.com/benjamingr","followers_url":"https://api.github.com/users/benjamingr/followers","following_url":"https://api.github.com/users/benjamingr/following{/other_user}","gists_url":"https://api.github.com/users/benjamingr/gists{/gist_id}","starred_url":"https://api.github.com/users/benjamingr/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/benjamingr/subscriptions","organizations_url":"https://api.github.com/users/benjamingr/orgs","repos_url":"https://api.github.com/users/benjamingr/repos","events_url":"https://api.github.com/users/benjamingr/events{/privacy}","received_events_url":"https://api.github.com/users/benjamingr/received_events","type":"User","site_admin":false},"created_at":"2015-02-04T01:50:09Z","updated_at":"2015-02-04T01:50:09Z","body":"@zxqfox I really don't want to make this about bluebird - but it's a lot faster now than it was in those benchmarks more than a year ago and I'll reiterate again: You need _less_ ticks to allocate a promise than to allocate a closure when passing a new function as a callback. \r\n\r\nNo one is suggesting a userland promise library in core - the point is given time and cooperation there is no reason (native) promises in core would not be at least as fast for the average user as callbacks. Speed shouldn't be an issue here.\r\n"}}