I chose to abandon Code with Node by Ian because I see it as a course on building your usual REST web application, which is something I don't need and the course I shouldn't pick in the first place. I expected the course to teach me more about Node.js. I know that Node.js is mostly about building web applications, therefore I can't really avoid getting out of that topic entirely. But my goal now is to learn more about Node.js itself, and therefore back-end programming. 

Although the course can fulfill a few of those purposes, what I want to learn is more about Node API itself and not about learning packages, assembling them, and finally building an app with it. What I want is to learn more about advanced topics such as Streams, File System, and Process. Node.js is so much more than Express and Mongoose is what I'm trying to prove. And learning more about its API can be helpful for my later projects.

For that purpose, I have two books as my candidate. One is Node in Action by Mike Cantelon. And the other is Node.js Web Development by David Herron. The former is published in 2014 and the latter in 2020. Both of the books covered roughly similar to what I want to learn, but Node in Action focuses more on Node.js while Node.js Web Development focuses more on cloud deployment.

Basic Chatroom application using Socket.io

Based solely on the topic discussed within the book, I would choose Node in Action without a doubt. But looking at its published date, I feel reluctant in picking it up. Why? Because old books are using old technologies, therefore old versions of Node.js. While the core concept of Node.js itself will remain relevant throughout many different releases, it's inevitable to have at least a few parts of it to become obsolete right now. Well, a quick thought later and I come up with the conclusion that I will face the obsoleteness because again, the topic discussed within the book is just simply too good for me to ignore.

Let's do a quick recap of the book because I actually picked the book three days ago and I just wrote my first entry today. The book started with a bird-eye view of what Node.js is, starting from its origin, the usage of V8 engine, the asynchronous-evented nature of it, and many more. Then it went and built a basic real-time application.

Building a "complete" application at the initial phase of the book is the way of learning which I favor the most. I love building unknown things and writing codes that put me into questioning mode. Without knowing anything, it will be inevitable for me to go adventurous to prove my hypothesis of the code that I wrote. I will certainly go to its documentation, StackOverflow, and articles throughout the Internet. This is also why I love Pro React 16 by Adam Freeman so much because it also started with a complete app to overview what React is.

Cut short to the end of the application, my biggest fear of picking an old book is showing its ugly head. Yes, Murphy's Law is scary sometimes. My code throws an error. Wait? Just an error? If it is that then you can simply fix it right? Yes, true. But the error originated from the Socket.io package. 

If the error came from third-party packages, there's little I could do about it (unless I go into the code, fix it, and make a PR that is). The error thrown caused by the package is the usage of "process.eventEmitter". To give you a spoiler, the answer for this problem is that I use the latest LTS version of Node.js (v14) which does not handle events using eventEmitter anymore and created an isolated API instead. But at the time, I expected the problem would come from the incompatibility of Node.js and probably the ES6+ code that I'm writing.

The first solution that I came up with is to upgrade the Socket.io version from v0.9.6 that is suggested by the book to Socket.io v1. An upgrade to the nearest major release. To say the least, this is the stupidest solution out of the later ones because different releases are likely to have breaking changes, that is the feature that you are using in version 0 is likely to be removed in version 1. The result for this solution is still the same eventEmitter problem.

Next is the assumption of me using ES6+ code that could possibly affect the old packages. Let's see for example if the package is using "this" keyword for their callbacks and still relying on it, and on the other hand I'm using arrow functions for my callbacks, the code could mess up somewhere is what I think. I couldn't ascertain this theory, but I think it's possible. The answer for this is to use Babel and use it to transform the code so that it could be read by the older version of Node.js. 

It's rare for me to manually set up Babel because on React projects, I could rely on "create-react-app" to kickstart my project. While the config is rather simple, learning the nature of how it works is the challenge. I have a specific kind of working directory structure and I couldn't get Babel to transform my code in the first few tries. After getting around the head a few times, the answer for this is the usage of config files and determining the "root" of my working directory. The Babel code transform is working and I'm ready to try it again. And….. it still pops up the eventEmitter error.

For the last try, I tried to install a much older version of Node.js, version 6 which was released around the same time as the publishing of the book, that is 2015. After installing and using Node.js v6, it's still throwing tantrums. It says something like "fn.bind" isn't a function. Again, it originated from the Socket.io package. At this point, I was pretty much desperate and decided to sleep with it.

The next morning, I searched for that particular error on Google, and what I found is something truly simple and explains why my first solution is a very dumb thing to do. It's caused by the breaking changes of Socket.io between version 0 and version 1. The answer is to revert back to Socket.io version 0. And finally, it works. The solution took me only 10 minutes of my morning and it pisses me off.

While it still pisses me off, I ended up with a pretty solid development environment with Babel installed in it. I can write a few of the latest JavaScript features without getting afraid of it not being able to be read by Node version 6. It's not a requirement of the book to install Babel, but it's good for me in the end. And I learned my lesson. Breaking changes are truly a pain in the backside.

That sums up my three days of dealing with turd. I will continue on reading this book at least until next Sunday before continuing on my PetTake project. Thank you for reading my post and I hope things go well for you as well.

 This free site is ad-supported. Learn more
​