Hacker News Reader

Comment by fullmoon | Hacker News Reader

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.

View on HN

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.

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?

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.

> 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.

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 :)

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.

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);

Thanks for this. Been thinking about this. Could you recommend a book on patterns like these?

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

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.

> 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?

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.

Error handling isn't a problem if you understand MONADS

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.

this is just a sketch to give you an idea of what I am talking about. right well you've probably used jquery before, so the api would look something like this. You start with a sequence of async actions you want to perform.

$(ctx).geturl("http://example.com).parseExample().renderTemplate().end();

Now this is a bit different from jQuery since all the methods here do is push method names and arguments onto a stack. it's the .end() method that reads in the stack and goes through and executes it. This means that each method along the way we've constructed a partial computation value- that is, the stack, which we can pass around as a value- just leave off the "end" method...

var scrapeHN = $(ctx).geturl("http://example.com).parseExample().renderTemplate();

now we can modify the computation by turning it into an error handling monad...

var ecm = ErrorCatchingMonad(scrapeHN, errorCallback);

this wraps each method in the monad with a try catch block, and calls the callback if an error gets thrown, and stops the chain from getting executed further. in fact this is how the origial monad was created

var $ = DeferringMonad(scrapingAPI);

which takes a normal jquery style plugin interface/chaining api and turns it into that deferring stack type api with an end(); method.

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

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.

Reply on news.ycombinator.com