Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Agreed. I spent the last few months building my first Node.js app (and MongoDB) and I resonate with a lot of what's being said here. I wouldn't want to discourage anyone from exploring Node or Mongo, because I think both are amazing projects and have huge potential, but I do think anyone considering either should stop and think carefully before taking the plunge.

Things that stick out in my head:

1. What the author says about the Node community moving fast is absolutely true. Be prepared to spend time upgrading to the latest versions often or deal with dependency hell as you try to ensure you've got matching legacy versions of libraries.

2. Coding async is weird at first, but you may grow to love it (as I have). Over the months, I've discovered many cool tricks and patterns that help keep the nesting to a minimum.

3. Be prepared to fill library gaps, and submit patches if necessary. This means not being afraid to dig into the source code of the libraries you're using. Most libraries have limited documentation so often the only way to figure out how to use them is to get in there and see how they work.

4. Best practices may not apply. In the case of MongoDB, I had to redesign my schema in order to run certain queries now that MongoDB won't support until sometime in the future.

All in all, I'm really glad for the experience and will definitely consider both Node.js and MongoDB for future projects. What will really be interesting is seeing what I miss about Node/Mongo after jumping back into Python/MySQL. :-)



> 2. Coding async is weird at first, but you may grow to love it (as I have). Over the months, I've discovered many cool tricks and patterns that help keep the nesting to a minimum.

Can you share a few? Either here or as a blog post?


If you have a function foo() that takes a callback as an argument i.e. something like:

  foo(..., function (n) {
     // closure over q, r, s
  });
Then what you can do is create a separate function, bar() that takes q, r, s as an argument, and returns a function:

  function bar(q, r, s) {
    return function(n) {
      // still has dependency on q, r, s
    }
  }
Once you have bar(), the foo() call above can be written as:

  foo(..., bar(q, r, s));
and you save one level of nesting. (This also makes the dependencies explicit, which is helpful.)

The main loop of

https://github.com/ithinkihaveacat/node-fishback/blob/ce5f9c...

does quite a lot of this, if you want a real example.


This technique reminds me of Lambda Lifting: http://en.wikipedia.org/wiki/Lambda_lifting


Why not to write it in a much simplier way? Like this:

  function bar(n) {
    // still has dependency on q, r, s
  }
  foo(..., bar);


Yeah, that's nicer if bar() can be defined at the same "level" as foo() but if it makes more sense to move it somewhere else the closed-over variables need to be passed.


We've been using the flow control helpers in async.js to help us with the nesting issue: (https://github.com/caolan/async).

We use the waterfall most, as it allows one to run an array of function in a series with a callback at the end of the series.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: