Understanding EventEmitter | Understanding Node.js Core Concepts FREE VERSION 

Hi Arthur, sorry for my late response... I think it's necessary to mention these computer science terms, due to two main reasons. One is that some students already possess some knowledge in CS, maybe they have studied CS in university, or somewhat somehow have learned these concepts through their experience, and then mentioning them here will make the concept easier for them to grasp and make better connections in their minds. And another is that some people are just curious to know and would research some of these terms and learn about them, which will ultimately result in a deeper knowledge of the technology. The downside is that some students neither have a CS background nor care to learn about them and these terms may only confuse them if used too much. But I should take better care here, focus on a more complete and accurate use of these terms, or maybe give a pdf file with each video that incorporates all these terms with some description and probably links to learn more... I hope I could make some improvements in this regard! and thanks for your comment Arthur!

I noticed that too. The loop simply doesn't reach 0 index. And it's perfectly fine to compare functions (objects) in JS. How the author could not know that? It's quite a serious mistake.

It's coming up next after File System, Streams, Net and then HTTP!

Waiting for your next video 😅

@@manasupadhyay266 +1 :D

@@Cododev Please bring it on. Include HTTP/2 and HTTPS.

Wondering too

Yeah you're right Arthur, I should've paid more attention to that fix haha. The issue is exactly what you've mentioned, it regards all the onceWrapper functions as the same thing. We'll face the issue if we declare multiple once listeners with a unique event name. For example, 3 once listeners on an object listening to the event 'bar', and each one logs the number like this: '...occurred 1.', '... occurred 2', '... occurred 3'. Now, if we run myE.emit("bar") a hundred times, for example, we should get the logs in this order: '... occurred 1.', '... occurred 2', '... occurred 3'. But, in our code we get: '... occurred 1.', '... occurred 3', '... occurred 3'. But anyway, thanks for mentioning this. I'll try to come up with something better (the node.js solution is also pretty interesting, with 2 wrapper functions, a fired state...), in the meantime I'll update the video description to mention this issue, thanks again!

@@Cododev I think the code from freecodecamp is designed to be run with named functions because removeEventListener is trying to compare two references and if you push anonymous functions onto the array when adding listeners there are no references to compare. No sure though since I've only just started learning this quirky, weird language and I haven't really tried the code yet, lol. Great channel.

Think of the EventEmitter class an interface that classes that extend it must abide by. There's not much point on simply extending the EventEmitter class and not implementing the necessary emitters.

Not necessary for this particular example, but useful if you want to create a class that contains its own methods, those methods in this case would typically be listeners.

That is a great point! Thanks for mentioning it!

Whenever the code that extends the EventEmitter class throws an error and emits as 'error'

The error event will occur if we do .emit('error', ). It doesn't have to be automatic, you could manually do this. So imagine you have a classroom object extending the EventEmiter that has an event called 'newStudent'. Now in your code you could have a limit for number of students, let's say 30. If we try to add another student once we reach the limit, then we could emit an error indicating that. Hopefully this code will clarify that for you: classroom.on("newStudent", () => { if (students.length < 30) { // adding a new student to our database... } else { classroom.emit('error', new Error("Cannot add more than 30 students.")); } }); // A place to handle all the errors relating to the classroom classroom.on("error", (err) => { // sending the error that was occurred to client res.status(400).send(err.message); });

Hi Carnaru, thanks for your comment! Well in response I have to say that is certainly not true. While it is possible in the tech world for a new thing to come out and take over another, Node.js will stay here for years to come. And if it’s going to be overtaken by something else, that’s not going to be Go or Rust. Rust and Go are great technologies, I love working with them, but it’s important to know that Node, Rust, Go, Java, and Python… are just tools and each tool is good for some specific tasks while another may not suit that job well. Now comparing these together will take at least an article and I can’t really say all that in a comment. Go is better at concurrent programming and multi-threading, but still, if you combine Node and C++ (you’ll get the best of both worlds), you’ll come up with something impossible to beat by Go or Rust. I’ve seen lots of articles online saying the cons of Node, but most of them are outdated and really the authors don’t have enough knowledge of Node so they just throw wrong facts at people (mainly it’s because good tutorials and resources that teach node in depth out there are so scarce). Also, for learning purposes, we should focus on the core concepts, topics like Databases, Operating Systems, Security, Algorithms and Data Structures, and Networking. Node is a great candidate to use to learn these things, and honestly, it doesn’t really matter what you pick to learn these, just master them with whatever you feel most comfortable with, and I promise you if later you want to move to another back end technology, it’ll be a cinch! Best Regards

Rust will certainly take over. The laws of physics are being written in it as we speak.