Home

The Initiation

This series is intended for people who have somewhere between beginner to intermediate level of JavaScript knowledge - someone who is already familiar with the major JavaScript constructs.

So, I joined this new start-up and their code stack was Node.js based.
I had no prior experience with Node.js or JavaScript as such.
While I still consider myself a JS noob and am still learning to tame the mighty Kyuubi that JS is, I already feel I’ve come a long way from where I started.

I come from a Java background. I’ve done OCPJP certification and I prize the knowledge of OOP concepts that it gave me.
The Java ecosystem is powered by its firm adherence to OOP principles and concepts.
This might be disliked by many newbies but it’s this same characteristic that is loved by Java veterans.
It’s like the military. It might be tough for the recruits but after you devote yourself to it, it becomes a part of you.
It brings you stability, order, conformity. And you get so used to it that the rest of the world feels flawed once you retire.

Now, being the Java enthusiast that I’m, imagine the nightmares I’ve had when I was exposed to the hip culture of JavaScript.
They say JavaScript is very flexible and forgiving. I say it has no discipline.
All OOP concepts are thrown out of the window.
While Java's error handling is known for its robustness, JavaSript doesn’t even have a proper error-handling mechanism.
It is so flexible that I can write dirty code and get away with it. And if I haven't been vigilant and handled my errors right, it might break my entire single-threaded Node.js application.
Also, it's largely asynchronous.
So, consider JavaScript to be a world where even your most heinous crimes are easily forgiven and overlooked. And, in fact, you'll actually have a hard time just trying to not be a criminal

Now, Node.js has the Node package manager (npm); something roughly similar to pip for Python or Composer for PHP. (I would've also mentioned Maven for Java. But, Maven does a lot more than package/dependency management.)
It lets anyone publish node packages. So, there could be many packages out there that are not well written. And you might use one in your project, thinking that it’s flawless, since it came from a trusted source.
But one of its methods could be faulty, might throw an error and you would totally miss it unless you have proper checks in place.
You can't even tell what kind of errors an external library can throw until, one day, it actually does!

Consider this scenario.
There’s an external package X with a method that is faulty.

//library_method.js
module.exports = function (){
    throw new Error();
}

You use this method without realizing it was faulty. It might work great while it is working.
Then, on one fine day, it'll throw an error. But this library-method error will get masked through the execution flow and you'll have to put extra effort in debugging.

const library_method = require('library_method');
function m1(){
    library_method();          //the real source of error that you missed to handle
    ...                        //you thought the error was in your code
    return x;
}
function m2(){
    let a;
    try{a = m1()}
    catch(e){a = 0}            //and handled it wrongly in calling method
    return a;
}
function m3(){
    let b = m2();              //Now, the erroneous data will propagate through the system
                               //until it finally causes a new error. Though sometimes, it might go unnoticed
    return 10/b;               //Even if it does throw an error, the stack trace will point to m3(). Not library_method().
                               //Not helpful while debugging
}

Now, this was a very crude example. But, the basic point I'm trying to convey is, I've trust issues with JavaScript and I take any code written in JavaScript with a grain of salt.
TODO: include https://www.kb.cert.org/vuls/id/319816/ https://github.com/joaojeronimo/rimrafall https://medium.freecodecamp.org/what-i-learned-from-showing-my-work-on-hacker-news-48c54d78d5f4

For small-scale projects, it might not be a big deal.
But for any industry level application, it is very easy to form an unmaintainable jungle of code if proper coding standards and conventions are not followed.
Now, while most organizations do have their coding standards and conventions decided at the start of the project, I'm just saying that JavaScript's flexibility adds a certain level of difficulty to it And since JavaScript is so flexible, it's an added responsibility on the organization's part to determine appropriate coding standards and conventions for the developers to use.

In Java, if there's a faulty method that throws CheckedException, the code won't even compile until I either handle the error or specify that my method m1() could throw the same CheckedException using throws keyword. (More on Java exceptions here)
So basically, if my compiler can tell that some code is dicey and can cause a problem, it'll either force me to be a man and handle the problem myself. Or ask me to be responsible enough to notify any person who uses my code, about the problem and force them to handle it.
In JavaScript, I wonder how many people even know that there are 7 core error types present. I wonder if anyone uses them.

Now, I do not intend to make this a JS vs Java rant wiki.
It’s been just 3 months I’ve been working with JS and I already feel the leash around my neck when I go back to using Java every now and then.
Instead, I intend to ELI5 (Explain Like I'm Five) all that I've learned so far.
This post here, however, does a good job of summarizing JS vs Java. Not as a rant either. But, in a more scientific way.

The above problem is just something that has taken away my sleep since the time I've started programming in JavaScript. And turned me paranoid over the code I write.
But, I’ve learned so much in this brief time that I felt the need of documenting it.