Root of all evil is not the exact term I would use, but they do make writing decoupled code that is testable, and easy to read and maintain more difficult than when using alternatives such as promises.
I think the complaints stem more from the superiority of the alternatives to the status quo than they do from any truly demonic attributes of callbacks. That said, I agree with the approach outlined here. Once there is a clear winner in userland, bring it into core. Until then, roll your own. On Tuesday, August 13, 2013 11:14:56 PM UTC-4, Andrew Kelley wrote: > > I'm glad that people like Isaacs are leading the charge here instead of > some of these wild opinions being thrown about on this list. > > I think that I speak for a silent majority when I say that I honestly > don't understand why people say that callbacks are the root of all evil. > Callbacks are amazingly convenient. They're simple to understand, simple to > use, and have surprisingly effective abstraction power. > > On Tuesday, August 13, 2013 1:57:44 PM UTC-4, Isaac Schlueter wrote: >> >> There's been a lot of debates, theories, and requests about Node's >> core API patterns on this list lately. I'd like to clarify the actual >> plans of the project on these points. >> >> >> Callbacks will remain the de facto way to implement asynchrony. >> Generators and Promises are interesting and will remain a userland >> option. >> >> Streams are more consistent, faster, and 100% backwards compatible as >> of 0.10. The "compatibility mode" aka "old mode" is folded into the >> API more cleanly. You can `pause()` a flowing stream, and then start >> calling `read()` again safely. We'll keep exposing streams from core >> APIs, and advocating extending the stream base classes in userland >> programs. >> >> Domains will be refactored to support more generic >> continuation-tracking systems, to enable alternative error-handling >> mechanisms in userland. Eventually the Domain module will be a thing >> that could be done in userland, but it will continue to be bundled >> with the Node binary. >> >> There will be no changes to the module system. None. It's finished. >> It's been finished for over a year. Any proposed changes must come >> with a clear reproducible bug that cannot be worked around or >> addressed with documentation. >> >> TypeScript and CoffeeScript will not be added to core. However, as >> the module system will remain locked, anything that works today will >> keep working. >> >> A stable C API shim will be added such that binary addons can be >> code-stable (and perhaps, binary-stable) across stable branches of >> Node for the most common use-cases. Note that the V8 API changed >> *significantly* in 0.12, so basically every binary addon is broken >> today. Also, it's very difficult to bind to the appropriate >> openssl/zlib/c-ares/etc. We're addressing that. >> >> As new language features are added to V8, they'll make their way into >> Node. We have no plans to "auto-enable" any specific flags. Sniff >> for what you need, and throw with a helpful error message if it's not >> available. >> >> The VM module is being refactored to bring the features of the >> "contextify" module into core, so that contexts work like everyone >> expects that they should. Multi-context support is being added to the >> VM module API as well. >> >> Synchronous child process execution is being added, at long last. >> >> v0.12 is nearing feature completion. Once we get there, we'll be >> trying to get everyone to use it. After v0.12, there will probably >> not be any API changes before v1.0. Between v0.12 and v1.0, we'll be >> focusing on performance, bug fixing, and stability. >> >> >> We are done making breaking changes at the Node.js layer. If your >> program runs today, we're doing everything we can to make sure that it >> will run next year, albeit faster and more reliably. >> >> This is not a democracy. However, there's plenty of room for >> everyone's opinion. If you want to make exciting dramatic breaking >> changes to node-core, and you can't find satisfaction by writing >> userland npm modules, then please fork joyent/node, give it a new name >> and logo, and go as completely crazy as you want. >> >> OSS FTW. >> > -- -- 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 --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
