[tessro]

I love Giles. His first Archaeopteryx talk was one of the best Ruby-related talks of all time. He's way too harsh on Rails though. The original "blog in 15 minutes" demos that catapulted Rails into the limelight are still possible with Rails 3. Things like 'gem install rails' still work. If you are determined to skip bundler, you can do that too. What's more, unlike 2005, in the 15 minutes it takes to build a Rails blog, you can deploy to Heroku and have a live site running.

Node is fun. V8 smokes MRI. But Node's web framework ecosystem has a long, long, long way to go before one can reasonably say that Rails is a bad investment. If anything, we should be celebrating the number of options that are open to us. It's a great time to be developing for the web. Good things will come from Node's ascendancy, whether its frameworks dethrone Rails or not. The negativity is unnecessary.

[fullmoon]

I'd go further and say, that it will be very hard to have a good MVC framework with Node before the async callback mess is brought under control. Maybe we'll even need something like Iced CoffeeScript for this.

[weixiyen]

I'd caution against any "I'd go further to say" statements. Either you know because you've tried, or you don't and are simply guessing.

As someone who has made an MVC framework in Node.js and launched a production site using that framework, I can assure you that it's not hard to avoid async callback mess. I can also assure you that many others have had success doing this.

It's really not difficult to write beautiful, modular, and readable code in node.js without going past 80 columns and without using Iced CoffeeScript.

I suspect that comments like this only further reinstate the theory that most people are dismissing Node primarily due to the annoying amount of hype. There are better reasons to not use Node, but imo, this isn't a very strong argument.

[bphogan]

All the examples, github repos, books, and tutorials I'm seeing with my dive into node say exactly the opposite - the code becomes a mess of callbacks. It looks like enormous work goes into avoiding callbacks, similar to the amount of work that went into Rails in 2005 so that server-side folks could avoid writing JavaScript.

I'd love to see this framework you wrote. Is it open-source? or is it something you're unable to share?

[MatthewPhillips]

You have to think about async code differently than you think about synchronous code. In PHP you might write:

  $data = getData();

And people want to substitute the return for a callback in js.

  getData(function(data) {
    // Do something with data.
  });

That indeed does lead to callback mess. But when you are coding in js you rarely should use anonymous functions. I mostly just use them when I might want to perform recursion. Going back to my example, I would write the operation as an object like so:

  var SomeObject = {
    start: function() {
      getData(dataGot);
    },

    dataGot: function(data) {
      
    }
  };

JavaScript is an object-oriented languages; use objects! They make async painless.

[bphogan]

Wrapping things in objects doesn't seem to help me.

I'd still end up with this, thanks to callbacks.

    app.get('/documents', function(req, res) {
      Document.find().all(function(documents) {
        // 'documents' will contain all of the documents returned by the query
        res.send(documents.map(function(d) {
          // Return a useful representation of the object that res.send() can send as JSON
          return d.__doc;
        }));
      });
    });

Seems to me that what's missing is something that lets me write it in a more simple way. What I have here looks like an absolute nightmare of coupling. So if you have some suggestions you could point me to that show a little more detail, I'd be really grateful.

[MatthewPhillips]

I would create a DocumentRequest object that takes your req and res, then break apart your callbacks to separate functions on the DocumentRequest prototype. Then you would simply consume it with:

  app.get('/documents', new DocumentRequest);

[tomp]

> JavaScript is an object-oriented languages; use objects! They make async painless.

In the example above, you're unable to use ''this'' in the ''dataGot'' function (when invoked as a callback).

Object orientedness is very easy to get wrong in JavaScript, if you're coming from C++/Java/Python background.

[MatthewPhillips]

Right, I excluded the bind for the sake of simplicity.

I also forgot that it's this.dataGot. dataGot doesn't exist in that context :)

[fullmoon]

Your assumption that I have no experience, and have therefore based my statement on hearsay is incorrect.

[ypcx]

The async callback mess is not really a problem, there is about zillion patterns and libraries to handle it. The problem is error handling in callbacks, capturing stack traces from the async parent callers, and generally not crashing Node if you forget to try/catch your async handler. However, this problem is known, and this is being worked on in the form of "domains". Btw. Iced CoffeeScript doesn't solve this a single bit.

[stock_toaster]

> The async callback mess is not really a problem, there is about zillion patterns and libraries to handle it.

Doesn't that seem to imply that it is such a problem that people have come up with a myriad of disparate solutions to try to solve it?

[weixiyen]

If you have callback hell in your code, it's not because the problem hasn't been solved, but simply that you didn't put the effort to npm install a simple library.

I agree that it is a problem if neglected, but most people don't allow it to be a problem in the first place.

It's like knocking on PHP because it could be used for templating and business logic on the same file. Just because you could, doesn't mean you have to (or should).

I honestly don't feel that it's as big of a problem as people make it out to be. It's simply a minor annoyance. The error handling is the killer.

[ZenPsycho]

Error handling isn't a problem if you understand MONADS

[weixiyen]

Could you give a brief code example how monads eliminates the problem of error handling? Do you mean to put try catch in the monad around every async step it takes in? Just the API for how this would even look would be great.

[telent]

For "could be used for", read "was designed for".

[ZenPsycho]

Because shut up, that's why.

real answer: It's easy and fun to whine about things you don't get in a language/paradigm you don't know. So easy and fun in fact that's almost entirely what programmers talk about to each-other. But whining hardly gets anything done, does it. The answer is: It's not a problem if you know what you're doing. And that applies to all other instances of this programmer discourse pattern.