Javascript, Node & Asynchronous I/O — The Awesomeness, The Fatigue, The Musings & The Woes — Part 2
If you haven’t already read the Part 1 of this post, please go ahead and read that first. Although its not going to hurt you too much but it is going to give you an idea about the “The Awesomeness” part, the good part first, and then you should consider the “The Fatigue” part, the bad part later. To have a neutral view or a balanced perspective of the entire thing. I don’t want you to have bad ideas of Node or Javascript by just reading this part. My humble request. :) with a happy smiley face.
Javascript — The Fatigue and its Woes
Javascript is the web language. Its an interpreted language (Well to know more about languages, how compiled languages differ from interpreted ones and what does this even mean, or is it even right to call a language compiled or interpreted, check out one of my previous blog here). It runs on the Web. Actually it runs on web browsers, the clients. Javascript runs on V8 engine which comes built in inside browsers. NodeJs is a runtime engine based on V8 but allows javascript code to run on regular systems on server side and not just client side in the browsers.
The late entry
In general, python, ruby, java, c/c++, php, some compiled language, some interpreted, but they all run on server side and cannot run on client side, that is a browser. Browsers have the V8 engine and hence interprets the javascript code (since its an interpreted language) and thus are able to run javascript on the web but not the other languages tailor made to run on systems directly and hence good for server side.
But javascript is the only language that made entry to regular system after being just a client side language. Node Js is not the language but the runtime engine (you can say its like V8 but made to work for running on system directly and not just in the browsers) and not a language. Javascript is the actual language, nodejs is the engine which executes the javascript code. For example, java is the language and JVM is the machine which executes the java code. Cpython VM executes cpython (generally called python) code. Do you get my point? No? Okay, lets do a quick nutshell of my mentioned language related blog post here itself.
The interpreted language
Lets talk about java or java based languages. Java is the language, you code in java and then you compile your code. The compilation converts your raw code into some java bytecode which you then try to run on the system. But actually you run the java bytecode in a JVM. Its a special VM which is tailor made to run java applications.
Lets look at another language, every application you run, runs on a system. But when you try to run a program which is basically the code you write which is nothing but plain text, it has no meaning to the system, for the system it is just a mere text file, with lines of strings which have no meaning, no instructions. So for the system to run, it needs instructions, it needs a language it understands, machine code or assembly code. So there comes the need of a compiler. A compiler coverts your raw text code into machine readable file or code which can then run on the system. To be honest, there are a bunch of other processes that happen during the abstracted compilation process which we talk about, like ast generation, linking, shared library loading, assembly code conversion, etc. But we are abstracting away all that and saying the entire process is the compilation process and the end result is a file or code which you can run on the system.
C/C++ do what we talked about in the above paragraph. Whereas Java takes a little bit of a different take. Its doesn’t compile the code down to machine code which ties the output to a particular system and its architecture. On the other hand, Java compiles down to some pre-machine class or code which is universal and every system can generate that irrespective of what the architecture of the system is. And this universal code can be run universally across all machines. But how? Every machine is unique and it needs its own instruction set to run any code. There comes the magic of JVM. JVM is the VM which comes in different flavours for different systems and architectures but thats all. After that every universal compiled java code which I mentioned, some pre-machine code, which when run on the JVM, further compiles the code into machine code which then actually runs on the JVM. Its a VM after all, it can run code as if its the sole system itself. JVM is a just-in-time compiler which does some optimizations and helps to run the java code faster.
Now lets talk about python, python is an interpreted language, actually the implementation of cpython is an interpreter. So python code which we write and run via the python code.py command interprets the code line by line and runs on the Cpython VM which is like JVM for python but not as good as JVM. JVM is JIT compiler hence super fast. Cpython is interpreted, hence slower. And also one of the main reasons for why python code runs slower than java by multifold times.
Javascript similarly is interpreted, and it runs only on the web(Well, I know you are probably frowning at this moment, but you already know that I am lying) in its custom made VM called V8.
And NodeJs is an engine like JVM which is based on V8 which allows javascript which only runs on the web gives the capability to run javascript on systems directly on the server side.
The fatigue, the dilemma
There are too many choices. When you start using javascript it feels good but then you have to go through a rabbit hole of libraries and packages and you will start feeling the choice fatigue, infamously known as the javascript fatigue (one among the other infamous jargons like the callback hell). Over experiencing something or over exertion of something causes it’s fatigue.
When you start writing javascript code, either for web or in the backend using node, you will slowly need a bunch of other tools to accomplish your work. This is because node is pretty sleek and thin and thus lightweight. It doesn’t come with all the libraries that you get by default when you use a language like python. But okay, this is still good given you don’t always need those libraries and thus lets you keep your process lightweight.
But the problems start when you try to use a library for a particular task. The choice fatigue happens when you see so many options for a single task. Since none of them are official and some good guys trying help the node community by contributing to a project which we can use but there are so many good guys now a days and thus you feel the pain and difficulty to decide to go with which of the good guys. Never hurt a good guy. Seldom found on planet earth. Which library do you want to use for that particular task you want to do?
Zero days since last new javascript framework — James Ward
Not only this, there are so many new concepts that start popping from here and there and they never stop.
While working on a simple web app, you first start thinking about a good web and networking library or a framework. This is our habit when we come from the python or the ruby world. We have a number of choices there too but thats about it, once we choose a framework like Django, or Flask in python or Sinatra or Rails in ruby, we are certain that we will get everything from these framework, there will be no more fishing expedition for other requirements. Well there will be but for special cases. Most of our needs will be covered by these frameworks already.
But in javascript/node world you first learn about web frameworks like express, fine. This is awesome. But then you start hearing about other frameworks, like hapi, koa, strongloop’s loopback. Well, this happens in all the languages. Options are good. Right? Fine, I will consider that. But then people start talking about configuration over code, code over configuration, then things like opinionated framework, un-opinionated framework. I never heard those terms, when I wanted to use a library in python. I only heard and read about the differences in their functionality but not terms like opinions, configurations etc in choosing a library.
Well, since node js is awesome, we will try to understand that this is a new ball game and these terms are actually meaningful and we will consider again. Well, then comes things like task runners, grunt, and I am again thinking I just wanted to start a server. I just wanted to do node server.js but people are talking about using a task runner? Okay okay, I will use one. But the moment you start using it and try to google about it to know how use it more proficiently, you are flooded with blogs and articles about how grunt is old and obsolete and why you should start using gulp instead. They again put some arguments about configuration over code and vice versa. I feel irritated but I will still start learning gulp. You are asking why? Because I don’t want to get old, I want to feel young and remain so and binge on Netflix infinitely, this is why, what else would it be, duh!. And to the surprise, its awesome. I quite like it. Its working. I feel young again.
Now when you start coding more and you are just about to get it alright, you start feeling confident and want to follow good design principle and be a good developer and do what good developers do, modularise your code to keep it clean and reusable. But then again, it comes to your knowledge that there are tons of way to this thing too. Are you serious, where are the family values, node? Why can’t you just agree on something for a single time? Node, you are really pissing me off. And node’s family agreement issues put you down again and make you learn about commonjs, require js, amd modules. But since you are good you abide by node’s hurting behaviour.
Now what? So, then you keep writing code again hoping you have finally understood node and its issues and starting to forgive node in return of its awesome service. So you get back to using google (silly, how else developers will code now a days? ), and then they tell you to start minifying stuffs, uglifying stuffs, linting stuffs, autoprefixing stuffs, do some live reloading, babelify stuffs, browserify stuffs, watchify stuffs, then some time hot reload sutffs, etc. Again, I just wanted to write a simple web application. And I still haven’t been around to finish it yet. :/
Well, all those tasks are important but the thing is when you are in the python world, the focus of your entire workflow changes, and in node + javascript world, you keep hearing about all these and how task runners are inexplicable part of your project. My focus now shifted from writing my web application code to making my gulp run a hundred small tasks. And sometimes you keep searching about better packages which will help you complete those tasks. See, this is the shift of focus and time I am talking about.
In fact you just can’t write code, you are tempted to use ES6 and ES7 standards and for that you have to babelify and watchify and browserify and what not. You can’t even just write the code in the syntax you want and just get away with it. For that you have setup up a full blown build script by either using gulp or webpack. This is so unfair! Python would have let me create the next Instagram by this time.
Well, I understood the importance of all that and I started respecting it. And life seemed to get back to normal eventually. And now you hear about this awesome front end framework React.
Well, its 2016, if you don’t know about React then you are pretty old and have generation gap issues.
So I started leaning about React. But what happened to Angular, which you learnt so dearly and put so much of effort in understanding it finally and though your frontend woes are gone and suddenly you tell me I should use React and give up on Angular. Thats rude and unfair, really. Told you if you come back to node or js just after 6 months, Rome would be built in one day I guess. Well, React is great. I am now full of energy if you ask me to do frontend work unlike earlier when it gave me uneasy experiences on writing those client side javascripts.
So before you really get your hands dirty with react, you are thrown back to the task runner world and they recommend (force in disguise) to use webpack and tell you how this is the next shift you should make and how gulp is gong to be obsolete again and give you examples of how gulp took over from grunt and how a similar thing is going to happen with gulp just to convince you to use webpack. And a gulp user starts feeling cornered. Sooner than later you found yourself got lured and writing webpack plugins.
So by now I must have used, got irritated, changed and changed again several libraries to do the same thing over and over agin but with a new look, new feel. Feels like changing mobile phones now a days, even that stays for 6 months. In js world, if you come back to work after 6 months, you have completely made yourself obsolete, all the libraries and packages you may have used to make your application work six months ago, must have changed already, or may have got a new design, ornamented, they just got revamped and you would not know them anymore.
Saul: “How’s it going?”
Me: “Fatigued.”
Saul: “Family?”
Me: “No, Javascript.”
Irony is, I want to reap the benefits of async I/O and node. So I keep accepting the frustration. Now you want to use the application, you want to do logging. And guess what, you are surrounded with so many options and their names, oh my, you will never be able to know what they are for. Bunyan, winston and 5 others, which one to use? You first need to read 10 articles just about how to do logging in node or what are the best ways to do logging in node js and only then you will get convinced about either to use bunyan or winston or those other 5 libraries you came across during your quest to figure out the above.
It doesn’t stop there. You are a good programmer, and like every good programmer you want to test your code (I know, we are not good programmers). So you go for finding some good testing libraries or tools in node js. And you are swamped again by huge number of libraries. I mean if I want to name them, I would get confused really, which one does what. In python, we have unittest, nose, pytest, and a couple of mock libraries and they just do their work and with competency. But here we have libraries called mocha, chai, sinon, tape, istantbul, and more, and if you can tell me which one does what, you are a pro. But really for a beginner, this really sucks. You get choice fatigue and there are so many choices for everything, you don’t know which one to use where and for what purpose not until you read up 10 articles or even more to really get a grip about things.
And everyday you will hear some new library that came up. There are so many, so many really. And everything is like some js, koajs, hapijs, videojs, and so many.
Conclusion
I have tried to be a little satirical about things here, part 1 was the good of node, this one was the bad of node. There is another blog which tries to explain the similar javascript fatigue problem in a more satirical manner. Do read that post. Here is the link.
If you have survived all this, then congratulations, you are up for the next award day, I am nominating your name for sure, please tell me you name. But it also means, you know the potential of node and how its single threaded nature and async I/O helps you to do a lot of things and gives you an edge over many other languages. So till you get yourself killed by the fatigue, Go Node!
