An open question (rant) about Node.js

There is no performance reason to make developers hand-code in the continuation-passing style. That should be the job of a compiler or runtime environment.

Erlang does it. Stackless Python does it. Go does it.

The whole "look how fast Node is due to all my hand-rolled callbacks" is a total fallacy. It's a case of taking perverse pride in an accidental wart of your language.

Slowly the node community is maturing and beginning to realize that if they want to build robust, fault-tolerant software they need better primitives than hand-rolled callbacks. Hence the slowly rising mindshare of Promises, which are strictly better, but would be better still if the language itself baked them in implicitly (consider that nearly any value in a Haskell program is represented by a promise under the hood, but you never have to deal with them explicitly).

The superfluous obtuse complexity that node.js forces is what's keeping ninja programmers like us employed. If we don't keep switching to strange new things every few years, our wages will stagnate as there's less separating our rock-star tech from lower-salaried uncool "enterprise" software.

Being able to manually manage continuations rather than using a language that does it for us is a high barrier that keeps us in demand, the same way that having to manage memory manually keeps people from becoming C programmers. Losing this edge is not something we should encourage.

Just imagine - if all of these "learn to code" programs actually work, the market will be flooded with new programmers. Thankfully, if we make sure that they only learn easy things like Python, we can continue to convince the world that things like Node.js and MongoDB are the future. While the rest of the world is still catching up on basics like Python and Postgres, we'll be one step ahead of them.

People questioning Node.js like this more and more are a sign that we need to find the next hotness and move there if/when node.js sinks. If we can convince people to build more things in the next hotness, then we can get in early before the masses pick up on it, ensuring that we can maintain our spendy lifestyles and free lunches in SF.

(/s)

Even on Unix, if you wrote a server procedurally what you'd end up doing is having main() start a select loop that... dispatches incoming events to callbacks. All Node does really is to abstract away the select loop -- one less thing for the developer to worry about. The Node way is simpler than the conventional C way.

So no, there's nothing inherently superior about linear, procedural code, especially when such code is not at all how a computer system that must interact with the outside world works. Whether asynchronous, callback-driven code is confusing or not depends on what background you come from. Put an old-school scener in front of Node and he might form an entirely different opinion about it from OP.

If I want to prototype (performance is not a constraint), I'd use Ruby (or Python) before Node. If I need concurrency or if performance is a constraint, I'd choose Go (or Clojure, or Scala, or Erlang) before Node. I understand the argument about using JavaScript throughout the stack, but I see this as specious at best. Front-end and back-end development require different domain knowledge, not just language proficiency.

Perhaps using Node opens a project to a larger community of developers. But under this argument, using C or Java also seems a good choice.

In terms of why this model is compelling: it scales well, and it's a relatively simple model of synchronization. The 5-line HTTP server on nodejs.org scales to a very large number of requests per second. Having spent a lot of time in the heavily multi-threaded C world (and loving it, btw), it's much harder to shoot yourself in the foot with JS and this model, and the failure modes are usually less severe. (Many C programs use this model as well, including haproxy and much of the kernel.)

It's not all win. Blocked operations are harder to debug. But you can work around things like that, and overall it's a nice environment. And FWIW, once you're familiar with it, the waterfall pattern quickly becomes as second-nature as writing synchronous code. (More complex ones are still tricky, but the basics do become second-nature.)

[edit: I meant that there's no sane possibility of a hybrid between synchronous and asynchronous semantics. That doesn't mean you couldn't use a language feature to make async code look synchronous. That's a much more subjective discussion, but I prefer explicitness over compiler magic.]

In my head, there's no difference between async and sync. A synchronous call is just an async message + and async acknowledgement of receipt. If I write it that way, there's a lot of failure modes that I don't have to think about.

Also, in my head, concurrent code looks like a sparse group of people spread over a large, grassy, hilly plot of land shouting at each other from differing heights and many yards distance over the whine of shifting winds. I find it easier to reason about the shouts alone, instead of shouts + their responses, because a response is nothing but another shout.

This isn't some new Node-Sauce. The idea of an event-loop asychronous programming domain has been around forever in various forms, first in games and desktop GUI programming and the way one reasons about it hasn't changed, just because it has been applied to a new class of problems.

I suspect that there are two things going on here:

1. A LOT of people dislike Javascript. As a result, they're starting with that negative point of view and then finding reasons to support it.

This is not unlike people who argue about Python white-space. They're really saying "I don't like Python." The white-space issue is incidental.

2. Lack of experience / exposure

I suspect that folks who have trouble with this, frankly just aren't experienced enough. I'm not saying they aren't skilled, just not experienced in this realm.

Once upon a time, these same sorts of 'arguments' were used against Ruby ( ala the Rails explosion ). Nothing much has changed about Ruby, other than it has managed to be around long enough to influence a new generation of programmers.

Here's both a series and a waterfall example: https://github.com/visionmedia/co#example

* No Error handling. The process has to be restarted if something goes wrong.

* No thread local storage equivalent. As a result you can't do simple thing like differentiate log originated from different http requests.

* Callback makes the code unreadable

* Javascript has no real method or in other words 'this' is not attached to a function and is determined by way the function is called. So you have to wrap most of the callbacks with _.bind()

* Mixing callback, promise and event emitter api introduce lot of boilerplate code.

* No stacktrace. Debugging error is PITA

* No preemptive scheduling. So you have to be extra careful that you never spend too much CPU time.

* No easy way to handle back pressure.

http://paulgraham.com/avg.html

I have to admit that learning to think in callbacks was initially an exercise in frustration. But it wasn't that hard.

Most of the pyramid-type issues can be resolved by applying principles that are also valid in synchronous environments (like modularity).

If modules and named functions aren't enough, you can subclass EventEmitter to further decouple. For more complex cases there's https://github.com/caolan/async, which makes many nontrivial async problems relatively easy.

Why is it so hard for so many people to appreciate Node for its merits? The code isn't going to execute in a perfectly linear way, so why should it have to be written as if it were?

> (...) try writing a function call that requires information from two separate HTTP API responses; I basically need to draw a diagram of what happens with async.waterfall for a task that, given synchronicity, would've been solved with a trivial three-liner.

It's a lot easier to handle asynchronicity in strongly-typed languages with monadic for comprehensions. In Scala, for example:

    val res: Future[Foobar] = for {
      a <- makeHttpRequestA()
      b <- makeHttpRequestBFromA(a)
    } yield new Foobar(a, b)

Synchronous code isn't simpler, it just hides complexity like caltrops in tall grass.

(slightly modified version of my post on Github)

However, this mistake has taught me something(s) very valuable -

1) Don't trade in a tried and tested framework for something like Node.js, that will open up a different level of problems altogether.

2) No matter what language you use, you WILL face issues at scale. Be it Node.js/Scalatra/Rails. You might as well face it with a tried and tested framework.

3) Don't re-write your own framework in something like Go or Haskell or C or C++ or etc. thinking it will be scalable, etc.

You will -

a) Waste massive amounts of time re-inventing the wheel,

b) Open yourself to possibly dangerous security vulnerabilities (Eg: Handling encrypted cookies),

c) Waste your time on things that don't really matter instead of on something that actually matters - The product itself.

4) Anything that you can scale by throwing more money at it is for the win[1]

Why am I talking about scalability, when the discussion is about Async. vs Sync. programming? Because of the reasons many people cite using Node.Js and the like. It's just not worth it. Focus on the product first and the architecture later. This comes from someone who wasted a year of his life doing everything above.

[1]http://highscalability.com/blog/2013/4/15/scaling-pinterest-...

Any program, of any type, has a synchronous story to it: data came in, then this happened to it, then this happened to it, then it left. If you follow the program execution, this is how it works.

It's very easy to reason about, right? And it's very easy to program this way.

One of the biggest breakthroughs in computer engineering was the idea of multiple concurrent processes (and nevermind that behind the scenes they were still running on a single processor!), and then later still true concurrent multi-processor architectures.

We developed operating systems and compilers and runtimes specifically to let us take advantage of that without the having to break from easy-to-reason-about synchronous code.

~

Node said, hell with it, everything is async all the time. This is really annoying at first, because there are many many times where sync is the best way to reason about something.

That said, there is some beauty in such a hard-line approach: if you are truly async, handling an error is the same as handling a task which takes too long. Once you've paid that price properly, you're fine. (This is also what makes Erlang kind of cool.)

The big frustration is that there really ought to be a way of writing synchronous-looking Javascript code (ES5) which--behind the scenes!--is multiplexed and made to run concurrently and without blocking. The mechanisms are all there for programmers to deal with exceptional failures (exceptions, anyone?), and so are synchronization points (functions having multiple arguments should probably join on the evaluation of those arguments before being invoked--that's something the interpreter should be doing already).

I guess what I'm saying is...why don't JS interpreters do lazy evaluation and late binding?

Why async by default? Because defaults should encourage best practices. It can handle C10K problem out of the box. With libraries like Q, the code can actually be rather easy to follow and maintain.

One of the biggest reasons why a multi-user server should be coded in async-by-default style is as follows: often, you want to obtain objects and not care about how they are obtained. In procedural languages, this isn't possible. Consider the following challenges:

1) Query sent to 10 different shards, wait until they all return, combine the results in the app, and then use them. In a synchronous language, you HAVE TO go to one shard, then another, then another, and the time is 10x longer. In an async style, it's only as long as the longest query!

2) Some of the objects may have already been cached, whereas others need to be obtained. In addition, the ones that need to be obtained shouldn't be requested more than once at the same time, but callbacks should be placed on a waiting list.

3) Various parts of your code (e.g. from different requests) might want to request the same object. Not only that, but you might want to batch your requests. That is to say, wait 10 milliseconds and see if any other (unrelated) parts of your code also want to grab some objects from the same DB table. Suddenly you are issuing a lot less queries because you can build middleware like this easily in JS. Not so in PHP for example - I would know. A lot is wasted there.

4) Let's consider #1 some more. The queries may go to other HTTP endpoints - do you really want to wait that long for I/O? Furthermore, even if they are going to local MySQL shards, your site becomes slower with an extra factor of O(log n) with the number of users. Kind of like when you use a relational database instead of a graph database for one-degree-away lookups. It could have been O(1) but instead you introduced another factor of O(log n). Not terrible, but certainly gives you a 5-20x cost down the line.

I personally still think it's a good thing, but that could definitely be debated on the server side. Unfortunately, if you want to have the advantage of writing one code base that can run on the browser or server, then it must work the same in both places.

It's not about performance, it's about <del>parallelism</del> concurrency.

If you don't care for Node's ability to handle multiple requests <del>in parallel</del> concurrently, with a single process with only one thread, than you might not have a need for Node at all. Why not use Ruby or Python?

If you really want to force Node into being a dumb scripting engine, you could use the various sync functions that Node.js provides. Problem is, they block the entire thread. But if you want to, you can. And I believe with some clever hacks, you can use the blocking nature of (for example) the fs sync functions to make other calls (including http requests) synchronous as well. But unless you use Node to build something that's not a server (people build command line tools with it as well), I don't think you want to.

By using synchronous functions, everything Node is built for will go down the drain. Everything done will be done in sequence, and during the time the sequence of operations has not finished, the Node runtime will be unavailable to serve any requests.

I suggest you look into promises as a somewhat saner way to deal with asynchronicity than callbacks, although you can pretty far with just the Async library. The future might be in Generators, a new feature of EcmaScript 6. This is available in V8. You can use this in Node 0.11 (unstable) if you use the --harmony flag. See here for a nice writeup: http://blogs.atlassian.com/2013/11/harmony-generators-and-pr...

Because if you do not make it the default, then most libraries you use will make the choice for you by going sync.

I see as a great opportunity completely squandered so that it would cater to the masses: "you don't have to learn anything new!"

Sometimes I think web tech likes being as shoddy and thrown-together as possible.

Because if your web server blocks every time it accesses a file, or talks to a database, or communicates over the network, then it won't take many requests at the same time before it's completely bogged down.

Yet in trying to set up some experiments that use a server-side git integration, I bumped into the kind of code described in this thread, and I find it super difficult to understand the async way of doing things.

Here’s an example from the homepage of nodegit, which seem to be among the best maintained libraries that wrap libgit2. Thus I imagine it represents idiomatic node.js What the code does, is console.log details of all the repositories commits, git log style.

  // Load in the module.
  var git = require('nodegit'),
    async = require('async');

  // Open the repository in the current directory.
  git.repo('.git', function(error, repository) {
    if (error) throw error;

    // Use the master branch (a branch is the HEAD commit)
    repository.branch('master', function(error, branch) {
      if (error) throw error;

      // History returns an event, and begins walking the history
      var history = branch.history();

      // History emits 'commit' event for each commit in the branch's history
      history.on('commit', function(error, commit) {
        // Print out `git log` emulation.
          async.series([
              function(callback) {
                  commit.sha(callback);
              },
              function(callback) {
                  commit.date(callback);
              },
              function(callback) {
                  commit.author(function(error, author) {
                      author.name(callback);
                  });
              },
              function(callback) {
                  commit.author(function(error, author) {
                      author.email(callback);
                  });
              },
              function(callback) {
                  commit.message(callback);
              }
          ], function printCommit(error, results) {
              if (error) throw error;
              console.log('SHA ' + results[0]);
              console.log(results[1] * 1000);
              console.log(results[2] + ' <' + results[3] + '>');
              console.log(results[4]);
          });
      });
    });
  });

How then the actual callbacks work, I’d be happy if someone can explain that to me—why do I pass a function to an attribute of the object? Why don‘t I just return the value?

Because the code is not written in a lineair way, I have to keep looking back and forth between callbacks to get a mental picture of what it does.

For the record, what this translates to as synchronous Python:

  from pygit2 import Repository, GIT_SORT_TOPOLOGICAL
  repo = Repository('.git')

  for commit in repo.walk(repo.head.target, GIT_SORT_TOPOLOGICAL):
       print 'SHA %s' % commit.hex
       print commit.commit_time * 1000
       print '%s <%s>' % (commit.author.name, commit.author.email)
       print commit.message

In that sense it is interesting that the Meteor team chose to use the package Fibers, that allows one to write node.js in a procedural style. I imagine something like that is necessary for server side JS to become really mainstream in web design…

I now use Flask and Python instead of Node.js and it's a total pain reliever. Not having to deal with Javascript is a win on the server side (JS on client side is enough) and the python stack is good enough to handle every bit of Node.js

Truth is, Node.js is in a bubble. I find it that even people who have never programmed before insisting that their new website be written in Node.js.... It reminded me of the dot com bubble, when your grandma would explain to you her rationale for buying dot com stocks (they had no idea).