(Replying to PARENT post)
Wasn't that the original selling point of Node? That it used callbacks for async and that it was easier that way?
👤hvs🕑12y🔼0🗨️0
(Replying to PARENT post)
It was easier until we discovered even cleaner ways, and most of the Javascript community began to adopt them. But node chose to stick to the "old" ways. (Not really old, but not as shiny and new as the alternatives)
I feel like promises don't need to be part of core though. It's easy enough to wrap the standard library in userland and just have other things depend on the wrappers.
👤CyruzDraxs🕑12y🔼0🗨️0
(Replying to PARENT post)
ES6's generators and the `yield` keyword plays very nicely with callback-based code, doesn't require any changes to the underlying libraries and gives you a much nicer syntax to work with.
👤nadaviv🕑12y🔼0🗨️0
(Replying to PARENT post)
As the post said, there are plenty of libs that add additional functionality in place of callbacks. Let everyone choose the way that works best for them.
👤driverdan🕑12y🔼0🗨️0
(Replying to PARENT post)
You can use fibers. We are doing that via common-node (https://github.com/olegp/common-node/) and are very happy with the choice at https://starthq.com
👤olegp🕑12y🔼0🗨️0
(Replying to PARENT post)
I don't understand. Can you not just roll in a promises library (like Q)and call it a day?
👤dclowd9901🕑12y🔼0🗨️0
(Replying to PARENT post)
A lot of short node.js code snippets you run into on the web use anonymous callbacks, and I agree, that gets ugly very quickly, but if you bind callbacks to methods on prototypes the code remains pretty readable.
👤9999🕑12y🔼0🗨️0
(Replying to PARENT post)
Take a look at ToffeeScript https://github.com/jiangmiao/toffee-script
👤ilaksh🕑12y🔼0🗨️0
(Replying to PARENT post)
I agree 100%. But still, a lot of people are complaining about some of the Node.js API choices.
They are complaining because it makes programming more difficult , and the truth is , async programming is hard when it relies on callbacks.