4 ms·

NodeJS: you needed 5% of your code to be async, so we made everything async so you get to write awkward async-but-not-really code for the other 95%, too. That's

• taurath 11y ago
  In a typical web API in node that I've seen, by function count I'd say around 60-70% of code is asynchronous.
  • ashark 11y ago
    Well yeah, I usually end up writing lots of async code because you pretty much have to since all the libraries assume that's what you want, but shoehorning in dependencies (promises, callbacks, callbacks mutated into promises by a promises library—it's a mess) until it could have just as well been written as at most two threads. So it's async in pattern but not in fact.
    • taurath 11y ago
      Most of the time that IS what you want in general in node, as if you start running anything with even moderate CPU time (let alone a call to an external service) you block the event loop and chug the system. The big performance gain you get with node in the form of max simultaneous connections per clock you get from not blocking. Most (95%+) of packages I've seen use callbacks, and maybe ~10% expose promise interfaces even if they use them internally.
• dboreham 11y ago
  Despite the downvotes, you are absolutely correct. My feeling, after working on a moderately complex server application in Node is that it was designed for only very simple applications that can be done with one level of callback. I find the "it works this way because its better" cult quite irritating. It works that way because the #*(^#$&^ JS interpreter isn't multithreaded.
  • to3m 11y ago
    It wouldn't even need to be multithreaded, I don't thnik. You could have some green threads-type system, using asynchronous I/O, a single-threaded server, and something along the lines of Lua's yieldk. Have a new script spring into life for each connection, suspend it when an I/O operation starts, and resume it when the results are ready (or when something goes wrong). I think this will be what Erlang does. (I'm sure there are potential problems with this, but hopefully it would be overall no worse than the current situation, while being easier to work with.)
  • qaq 11y ago
    on the browser side modern browsers support webworkers on the node side https://www.npmjs.com/package/webworker-threads https://www.npmjs.com/package/webworker-threads
• bm1362 11y ago
  Compare this to Go, what % of go code do you think lies inside a go routine?
  • ashark 11y ago
    Potentially almost all of it, but the point is that if _most_ of your requirements are "get thing, do thing with it, decide other thing to do based on that" you don't have to spin off three goroutines to accomplish it (roughly the equivalent, as far as wasted effort/mental overhead goes, of needless promises/callbacks which are abused to work out identically to performing those things in sequence). You do it all in one. Maybe it's just me, but I find that most of the time what I need to do can be boiled down to between 1 and 3 (and usually on the lower end of that) lists of things that need to be done in sequence (threads, if you will) and that Node is a poor fit for that, since its ideal case seems to be doing dozens of things, none of which depend on one another, then collecting them at the end, which is something I rarely ever need to do—if I do, typically the the "dozens of things" are really just one or two things with different data and therefore are very easy to parallelize without resorting to Node's typical patterns. I'm sure there's a workload where async-all-the-things makes things easier rather than harder, I just haven't run into it. [EDIT] "rarely never" to the intended "rarely ever"
    • bm1362 11y ago
      To be clear, I agree. I've argued for explicit concurrency rather than always asnyc. I prefer Go over Node for this very reason.
• ilaksh 11y ago
  Use async/await with babel.