If you come from a background of already writing javascript heavy apps, the browser is async so there shouldn't be as steep a learning curve.
People say this, but it's not really true. Yes, browsers are async in the sense that your code gets invoked by the browser as events occur. But once your client code gets control, it nearly always proceeds in a completely synchronous fashion. If all you're doing is changing a few dom elements in response to a button click, that happens quickly and all is well, but woe betide if you need to do some long-running computation in the browser... what are you going to do? Build your own event loop with setInterval and chop things up into short-running pieces? That's certainly uncommon. So client-side JS programmers typically don't have much experience with organizing their own code asynchronously, and the learning curve for doing so is still steep.
(There is of course one big exception to what I'm saying, namely communicating with the server via XHR. But not so big that it teaches you how to write a complex program in a non-blocking asynchronous style.)
What I really mean is JS Apps that use XMLHttpRequest or JSONP -
I found that prepared me pretty well for asynchronous disk reads and asynchronous http requests, I was already doing that in my browser code and it ported quite cleanly to node. (I use a wrapper method that chooses whether to use XMLHttpRequest or http.request based on the environment)
I should note one thing that tripped me up in the beginning is forgetting that I was in a shared environment for my scripts. I typically design server stuff to be 'shared nothing' by default, and you have to be a little careful in node as that is not the default way of running node services and at first I was sometimes sharing objects by accident.
People say this, but it's not really true. Yes, browsers are async in the sense that your code gets invoked by the browser as events occur. But once your client code gets control, it nearly always proceeds in a completely synchronous fashion. If all you're doing is changing a few dom elements in response to a button click, that happens quickly and all is well, but woe betide if you need to do some long-running computation in the browser... what are you going to do? Build your own event loop with setInterval and chop things up into short-running pieces? That's certainly uncommon. So client-side JS programmers typically don't have much experience with organizing their own code asynchronously, and the learning curve for doing so is still steep.
(There is of course one big exception to what I'm saying, namely communicating with the server via XHR. But not so big that it teaches you how to write a complex program in a non-blocking asynchronous style.)