What's your preferred method for dealing with the Pyramid Of Doom; fibers (via fibrous)? AsyncBlock? Or should we all use Promises?
Ask HN: How do you deal with the NodeJS Pyramid of Doom?
1–8 of 8 posts
Re: Ask HN: How do you deal with the NodeJS Pyramid of Doom?
#2Instead of using lambdas why not name your functions (function expression) and pass those around instead like so:
var someFunc1 = function(){...}
var somFunc2 = function(){...}
someNodeBinder1(someFunc1);
someNodeBinder2(someFunc2);
That being said, this is why it is best to avoid large projects with node.
Re: Ask HN: How do you deal with the NodeJS Pyramid of Doom?
#3I would probably be using promises now if more libraries supported them. It seems like for now I'm left having to wrap functions myself... (let me know if I'm wrong!)
Re: Ask HN: How do you deal with the NodeJS Pyramid of Doom?
#4Promises, with q is my preferred method.
Re: Ask HN: How do you deal with the NodeJS Pyramid of Doom?
#5[deleted]
Re: Ask HN: How do you deal with the NodeJS Pyramid of Doom?
#6Instead of using lambdas why not name your functions (function expression) and pass those around instead like so: var someFunc1 = function(){...} var somFunc2 = function(){...} someNodeBinder1(someFunc1); someNodeBinder2(someFunc2); That being said, this is why it is best to avoid large projects with node.
> That being said, this is why it is best to avoid large projects with node.
Like Airbnb, Linkedin and MySpace?? You can handle even large codebases well with Node. Callback hell is overrated since a large chunk of your code still stays synchronous for most server side rendered Node.js sites. At the end you implement user concurrency not in your app rather in some load balancing entity abstracting this away from you core app logic. Then, writing a Node app isn't much different than writing a Ruby or Python app (if using the right patterns/tools/libs).
And you get amazing speed: I think most didn't get how fast Node.js is -- it's factor 100 compared to any other traditional scripting language (i.e. Ruby). Once people learned this they won't go back.
Re: Ask HN: How do you deal with the NodeJS Pyramid of Doom?
#7I'm not familiar with the "Pyramid of Doom" term, but I'm guessing Callback Hell? Apart from the mentioned use of promises, here's a short writeup of how to avoid getting lost in the abyss http://callbackhell.com/
Re: Ask HN: How do you deal with the NodeJS Pyramid of Doom?
#8Instead of using lambdas why not name your functions (function expression) and pass those around instead like so: var someFunc1 = function(){...} var somFunc2 = function(){...} someNodeBinder1(someFunc1); someNodeBinder2(someFunc2); That being said, this is why it is best to avoid large projects with node.
> That being said, this is why it is best to avoid large projects with node. Like Airbnb, Linkedin and MySpace?? You can handle even large codebases well with Node. Callback hell is overrated since a large chunk of your code still stays synchronous for most server side rendered Node.js sites. At the end you implement user concurrency not in your app rather in some load balancing entity abstracting this away from you…
First of all size is a relative thing. It depends on what you mean by big. I would not write a monolithic code base with JavaScript. That's just silly, and is the kind of thing that Dahl and Schlueter have, themselves, been debunking in order to place node in the credible spot it deserves.
Second, you're citing company's that use node in the niche roles that work great for node. For example LinkedIn uses node for mobile rendering, they use Java for everything else (http://hurvitz.org/blog/2008/06/linkedin-architecture) and (http://engineering.linkedin.com/technology). I really doubt that if anybody saw LinkedIn's use of node relative to their use of everything else they would call it "large".
Now relative to most Python and Ruby projects out there...
Yeah - you can use node for large projects