A lot has been mentioned in this thread regarding what the "node team" thinks or agrees with.
Here's the official policy of the node team: https://github.com/joyent/node/wiki/node-core-vs-userland If we don't absolutely need something to be done in node core, we're not going to. The feature set of node core is considered roughly complete at this point. We're not going to add brand new features. We are in the phase of polishing and refining what we have. (For example, with the new streams API, or the modifications being made to Domains as more people use them and find issues.) A control flow pattern fancier than callbacks and event emitters will probably never land in node core. This kind of stuff belongs in npm for many many reasons. We try to minimize the amount of stuff we have to all agree on. If there was anything at this point that I could manage to *remove* from node-core, I'd do it gladly. Node is way too big as it is. On Sun, Dec 30, 2012 at 6:56 AM, Tatumizer <[email protected]> wrote: >> I have used this boilerplate so many times that I can type it without >> thinking. > > I don't see much of error processing there. It's like programming without > exception mechanism - you have to handle "err" return code in each line. > Doubles the amount of code, in the end you can't see forest for the trees (I > already can't see forest for the trees in the proposed optimal solution, but > maybe it's only me) > >> My app currently has several thousand such calls. > There are many very successful systems written completely (or to the large > part) in assembly language. > > COSTS is the keyword. > >>Its design decisions were made with an eye towards simplicity and >> performance, not elegance or purity. > > Elegance SELLS. > > But again, if there's no problem, no point to discuss the solution. > > > > > > > > > > > On Sunday, December 30, 2012 6:39:08 AM UTC-5, Bruno Jouhier wrote: >> >> FWIW the problem of implementing async/await semantics with a pure JS >> library has been cracked: >> http://smellegantcode.wordpress.com/2012/12/28/a-pure-library-approach-to-asyncawait-in-standard-javascript/ >> >> Unfortunately it involves a lot of extra grinding. So preprocessors and >> fibers are still the best practical options. > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
