{"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":176,"created_at":"2014-11-29T04:33:13Z","updated_at":"2015-02-04T00:39:40Z","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/72767951","html_url":"https://github.com/iojs/io.js/issues/11#issuecomment-72767951","issue_url":"https://api.github.com/repos/iojs/io.js/issues/11","id":72767951,"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-04T00:39:40Z","updated_at":"2015-02-04T00:39:40Z","body":"@zxqfox there are userland promise libraries that outperform callbacks right now since allocating a closure is more expensive than allocating a promise object (just ask @petkaantonov ). I don't see any reason native promises wouldn't cross that barrier eventually. \r\n\r\nA lot of people don't like a lot of things but breaking APIs without an _extremely_ good reason is a big no-no IMO. Let's not jump above our heads here with streams. \r\n"}}