3 ms·

Like others have said, callback hell is fixed with async/await, yield/generators, and even lightweight libraries like fibers and promises. Personally, I dislike

• nrjdhsbsid 10y ago
  Single threading was not intentional. It's because they used js, now they're trying to sell it as a feature. They've tried to implement threading several times but it's a huge change to the V8 engine and js isn't designed for it. Promises/async were needed to make the language usable because it's stuck on a single thread. The normal solution is to just use multiple threads and people have been doing g that for many years in other languages
  • jayajay 10y ago
    "its because they used js" But, this was intentional. As for them implementing threading, I am not sure about the history here. Was it like: "We used JS and knew we were going to have a ST environment, but because people wanted MT, we tried..." Or, was it more like: "Let's use js and we'll of course need MT like everything else... oh wait... nvm."?
    • Matthias247 10y ago
      I second that. JS is singlethreaded by intention, and IMHO it's ok that way and the reason why the ecosystem mostly works and async libraries can be reasoned about. There are JS implementations (like Nashorn on JVM) which are multithreaded, and imho they would be a much poorer choice. Once you have callbacks and multithreading in a single system there are dozens of things you need to care about (from which thread will callback be fired, how to synchronize that with the remaining logic, ...) and the complexity grows immensely. I think that's exactly the scenario that the JS inventors wanted to circumvent.
      • nrjdhsbsid 10y ago
        Java and c# manage threads+async just fine. You're overestimating the difficulty of using then together. In practice you just add the word async or await and go about things normally like in node. Js is single threaded because it was designed that way, not because it's a good design
        • Matthias247 10y ago
          I disagree. In my experience from seeing lots of code multithreading issues are one of the most common. E.g. in Android or C# GUI frameworks it's a super common error that people try to manipulate GUI elements from a background that just invoked their callback - which is not allowed. The issues there are typically that people without much experience don't even think about from thread an event can be fired - and what you should do if it's another one than the main thread. Even if you know about these problems it's often not clearly documented what the threading model of libraries is. Afaik the JS creators explicitly intended to avoid these issues by using a singlethreaded model.
          • nrjdhsbsid 10y ago
            The most common use case for node is probably as a web framework. At least in this case multithreading doesn't cause issues in c# or java. You just add an async decorator to your methods and it works. You're defending the single threaded model as if multithreading is a problem but it's just a feature. you could choose not to use it if you don't mind the performance penalty, just like async. Node not having multi thread support is definitely a negative.
  • 0xCMP 10y ago
    It was very intentional. The original developer wanted to create an event loop based system because at the time the C hackers had begun to learn how fast those systems could be for the purpose the parent comment mentioned (io bound, network servers, etc.) and instead of using something like lua he chose javascript to give it wider appeal.
• jsjohnst 10y ago
  JavaScript is single threaded. This wasn't an intentional choice of Node.js, unless you consider @ry picking JavaScript as the basis for your claim. "Non-blocking" code however was the original claimed benefit of Node.js for the reasons you mentioned.
  • jayajay 10y ago
    This seems like nitpicking to me.