Non-Blocking I/O

[00:00:00]
>> First thing I wanna talk about when we talk about the differencs of different languages and JavaScript and then the runtime Node. One thing to keep in mind is something called a non-blocking I/O. So if you don't know what I/O means, that just means your input, output, things that go in and things that go out.

[00:00:18]
Non-blocking I/O just means, so if you've ever used another language like Ruby, or Python, or maybe even PHP, whenever you run some type of arbitrary code, there isn't an ability to run another piece of code in parallel without using more resources on the computer like another thread, right?

[00:00:38]
JavaScript, or in this case, definitely Node is different in a way where you can run things in parallel on one thread. And it does that by having something called an event loop. And basically, an event loop, I have a description here, but the best way I can describe it is when you combine it all together with event loops, callbacks, and things like that.

[00:00:58]
It's basically, you can think of it as like a registry for work that needs to be done, and then that work gets completed on whatever timer that is set, and then that registry will then call a function in your code to let you know that that work is done.

[00:01:17]
So that way things can happen in parallel, and this allows Node to basically, a really good example would be to allow Node to handle more concurrent requests as far as a server. So Node.js could probably handle way more concurrent requests per second than another framework by default without any optimizations.

[00:01:38]
That doesn't mean Node.js is faster, because it's not like, this is just a better framework for everything, you should use it. No, because it's actually not good at CPU intensive things, because it only uses one thread. So doing things like AI or machine learning is probably not the best example for Node.js, because by default, it doesn't use all the resources on the computer intentionally.

[00:02:01]
So people choose Python for that, right? So there's different use cases, but when it comes to handling concurrent things, Node.js is pretty good out of the box for that, and it's because of its non-blocking I/O. Yes?
>> Is there a difference between the event loop in JavaScript and Node?

[00:02:19]
>> No, it's pretty much the same thing as well. The implementation is obviously different, because we're talking about an event loop on a computer, and those resources versus an event loop that's in front of a browser that's using computer resources. But how you would perceive it as a person writing Node is pretty much the same thing.

[00:02:39]
So no, there really is no difference. It's a good question. I wanted to put that out there, because most operating system-level languages aren't like this. This Node.js is probably this runtime and this language is probably the only one that I know that it's like this by default. So it's a little different if you'd like, I've been using Ruby my whole life and you come here like wait, what is that?

[00:03:02]
How are you doing that? So it's a little different and it makes you think about how you write your code, and we'll get to that, but here's an example. So here's some blocking code. So blocking code basically just means it's synchronous. As in, everything happens from top to bottom the way that you wrote it, right?

[00:03:19]
So it's just a function that takes an ID, and it's a constant lookup. It's quick, and we're not talking about like how fast something is, but basically, the next line doesn't happen until the previous line is completed, right? It's just standard synchronous code. But then non-blocking code would be basically if I wrapped the retrieval in a set timeout for a second in which this callback was fired, now this is non-blocking.

[00:03:44]
So what does that mean? Well, that means if I had some code after this line here, that code would execute before this code would, right? Because that's happening a thousand milliseconds later, which basically is just telling JavaScript in this case, hey, register this work to happen later. So it's gonna bottom out at this call stack, and then it's gonna wait until that time period has happened.

[00:04:11]
And then when our work is ready to be completed, it'll call this function in which triggers this function here and then you get your result. So this is non-blocking, whereas most program languages, you can't do this. So it's very important to remember that as you see as we go through the examples and we build our app.

[00:04:30]
Any questions on this? Yes.
>> Could you clarify one more time what you mean by if you know JS, you already know 90% of Node.
>> I'm sorry, if you know JavaScript, then you already know 90% of Node, because Node.js is just a runtime for JavaScript. The language is JavaScript.

[00:04:49]
So if you've already used JavaScript in a browser, then it's literally no different than the JavaScript in Node. The only things that are different, which we will go over in a minute, are the things that it has access to. So it's a little strange, because most programming languages are languages and runtimes at the same time, like Python is a language.

[00:05:08]
It's also a runtime. Ruby is a language, it's also a runtime. So it's rare to see Ruby in a different runtime, where it doesn't have access to the things that normal Ruby would, whereas JavaScript is a language. Node.js is a runtime, the browser is also a runtime. So even though the language is the same, the environments in which they run in are two different environments.

[00:05:29]
So they have access two completely different things, which makes it feel like the code is different, but it's still just JavaScript. A function is still a function, you can do the same things as far as the syntax and the code goes. But what you have access to as far as the globals, the packages, the power, it's going to be different, but the language itself is the same.