And it's evil because it's blocking. So it's blocking the entire system to get you that data from the file, so the output would be accounts.txt, that's our first console.log. Then you would see "Hello Ruby", then you would see the ips.txt, the inside of that file, and then you would see "Hello Node!".
The benefit of this is that it's very easy to understand because that's how most of us learn programming. We'll learn to go from the first statement to the last at the bottom, from top to bottom, even some languages they have the numbers for the lines or the statements, so it's very easy to written about. It's like a recipe when you cook something, it's very logical.
So you go from top to bottom and everything at the bottom has access to everything at the top. So, when I'm console.logging content, that's my variable, basically, and it's defined on the line before the console.logs. So I know it's there, I know it's defined. In the non-blocking world, everything changes. It's like Alice going into the mirror, going into its Wonderland. Now, out of a sudden, if I want to console.log contents right after readFile, it would be undefined.
I'm sure a lot of you encountered this problem, because it's asynchronous. So right after readFile, it would be undefined. It'll be defined sometime in the future. Maybe 1 millisecond, maybe 100 milliseconds in the future, we don't know, but when fs will be ready, when that operation of reading a file would be finished, it will invoke the callback, which is the last function, it's the last argument in the readFile, and by invoking it, we will see the console.log.
So, the output of this code, and again, you have the source code, go and run it, see what results you have, so the results should be, //Hello Ruby->Hello Node->, and then, depending on which operation, what file is larger, which operation finished faster, you will see either accounts or ips first. So we have a racing condition here because the operation is not deterministic in terms of time, and then we also don't have the data right away.
We need to wait. But the benefit is that we can run multiple things in parallel, basically, we get a lot of performance boost using node.js and using this non-blocking code. So node typically is much faster than other platform. I say typically because it depends on your business case and what type of code you're running. But if it's input and output-bound, which means you're doing mostly input and output operations, not CPU-heavy operations, then your node system would be faster.
In some of the situations, I would say, for me, in almost all of the systems, I'm not that worried about writing applications, which have the limitation. So I'm not writing a Facebook, I'm not writing a Google applications, which heed the performance limitation. So for me, and probably, many of you, the input and output is not the bottleneck, the performance is not the bottleneck. We can throw more servers, we can throw more RAM at our application.
So reuse of the code is another huge benefit. If I'm writing for the browser, I can put that code on the server with very little modifications and it will work. I also learn quicker if there is one utility I use on the browser and on the server like Underscore, or Lodash, or Async, or Request, or Superagent, then, all of a sudden, I don't need to refer to the docs that much often.