“The year 1995 and forth was a crazy time. Java made its entry to the mainstream and was ready to rock the world, and soon enough intelligent folks at Netscape brought the Netscape Navigator and things changed. Everybody could immediately understand that these two would change how we interact and think about computing.
The first was intended to be used on all the devices whereas the latter would define a new computing system inside another.
var yoJavascript = parseInt(‘Oops!’);
if (yoJavascript == yoJavascript) {
console.log(‘Hello Javascript!’);
} else { // Civil War
console.log(‘Gotcha!’);
console.log(
But soon enough it was observed that Java and its browser technology (Java Applets) were not optimized and finely tuned to be able to be used inside a lightweight browser environment. They were heavy, required steep learning and sometimes would not behave exactly how we wanted to. Then entered Javascript by Netscape. Java and Javascript shared synonymity in names, but they were (are) not the same; in fact they were (are) very different. Where one was (is) compiled and statically typed, the other was (is) interpreted and dynamically typed. Where one would not leave OOPS for a second, the other would not even think about it (till now).
Cut to 2016, both Java and Javascript have seen a lot of changes. They have become more mature, optimized and now have a definite set of users/developers and have definite goals. Javascript, in fact, is waiting for another overhaul change (ES6) and now powers many web applications thanks to a new groundbreaking technology called the AJAX (supported by JSON). You can now consume APIs and show or change data on your browser without even having to refresh the page. This is a big benefit.
But there is also a downside to Javascript. Even though everybody now uses Javascript to power their web applications, the developer community has not really accepted the language to the fullest. Plenty of us still think about it as a poorly made one which should be used just to fulfill the immediate purpose and then be left behind. There can be many reasons behind it, and to list a few:
1) The name. The name ‘Javascript’ attracts a lot of confusion. The word ‘Java’ in it gives an impression that somehow it’s related to Java and the word ‘script’ might tell you that it’s sort of a scripting language. Both, relatively are not true enough.
2) Few poorly made language choices. And the gotchas. Let’s admit it. Javascript has few poorly made language choices. It has few concepts which do not go well. Also, it has too many ways to do the same thing which is at times, confusing.
Let’s take an example of creating a function which takes 2 numbers and returns the added value:
Way 1: function addNumbers(n1, n2) { return n1+n2; }
Way 2: addNumbers = function(n1, n2) { return n1+n2; }
Way 3: var addNumbers = function(n1, n2) { return n1+n2; }
Way 4: var addNumbers = function iCanNameAnything(n1, n2) { return n1+n2; }
Way 5: var myFunctions = { addNumbers: function(n1, n2) { return n1+n2; } }
… and many more
Where all of these ways have different meaning and usage, it’s very confusing for the beginners and sometimes for professionals too to choose the best one. (If you ask us, 3 and 5 works best for us.)
Apart from having these way-too-many-ways to perform something, javascript has some tricky concepts (gotchas) which needs utmost attention. Sometimes it can be a pain to debug some error caused by one of the javascript gotchas and you might get frustrated. One example can be seen at the beginning of this post. The method ‘parseInt’ returns NaN for anything apart from a number. But in javascript, NaN is never equal to itself and thus NaN == NaN will return false. Now that can be explained in a mathematical way treating NaN as infinity, could it not be designed in a better way? We gotta have a question.
(Common Javascript Gotchas is a great source for more of such javascript gotchas.)
3) The trial and error approach. Javascript comes built-in with all the modern web browsers. Now that helps developers like us to directly and easily dive into programming and building javascript applications; it has a cost. The cost of building trial and error approach. As its very easy to start coding into javascript, we sometimes do not really learn the concepts. As its just matter of seconds to change the code and see the changes reflect in the browser, developers tend to build the trial-and-error approach. Also as programmers, we like solving big and complicated problems which require us to write big and complicated algorithms and somehow javascript has failed to provide us the same.
But even though javascript has its limitations and the gotchas, there is no denying that its ruling the browser ecosystem. At Haptik too, we use javascript extensively. In fact, our chat app Athena, which helps our assistants to solve your queries, is made with React (a javascript framework by Facebook). Also one of the most popular javascript libraries; jQuery powers our many in-house tools. And thus we love Javascript.
But as we speak about Javascript, we take immense care to make sure we follow high standards while coding in Javascript. We learn the basics, understand the data structure (yes! Javascript has a data structure), create algorithms and code. This along with the following measures helps us to reduce the number of errors in our Javascript code and helps us to scale.
Measure 1: The lints. We love (or hate :P) lints. We have lints for almost all of our languages, be it for Python (we use Python and Django for our backend) or Javascript. We have integrated these lints with our Github repo and thus any pull request tells us all the possible javascript errors we have made while coding and helps us to fight the basic mistakes. If you are interested in knowing how does that work, here’s a great read.
Measure 2: Coding guidelines. We believe prevention is better than cure. And that is why we follow strict javascript coding guidelines. As we spoke before about way-too-many-ways to do something in Javascript, we have curated for ourselves the best possible ones. But being overprotective, we might not want to share those here (:P) but here’s a great article about good practices in Javascript.
Measure 3: Object oriented Javascript. We are big believers of object oriented programming. Even though Javascript do not directly inherit the OOP concepts, we have workarounds to make it work like one. Here’s a great read to do so in ES5.
Measure 4: Libraries. We constantly look for great libraries in Javascript and try to use them. We believe that these libraries help us not to reinvent the wheel and also allow us to prevent the common mistakes. One classic example would be of using React in Athena. We previously used to use jQuery to power Athena and when things got messy we pivoted to React. You can read about it here.
With all that being said, to make Javascript more awesome, here comes ES6! ES6 is about to release in full force (it’s already released but has partial browser support) and it has a few much needed language changes. One very welcome change would be the introduction of the keyword “let”. Now we have something which creates block level scope of variables unlike the old “var”; and many more improvement like classes and promises.
Apart from the futuristic ES6, we have many present libraries/frameworks which has changed the javascript paradigm. To name a few, AngularJS, Ember.js, Backbone.js, Ext JS, React have created different design patterns and solved different use cases and are doing great. And who can not like the power of Node.js, the server-side Javascript. Now we have the power to use Javascript in server side to act like any other backend technology. This not only allows us to think and code in only one specific language for both frontend and backend, it also allows us to port the same code back-and-forth and with a little tweak your code starts working in both the places. Bingo. In fact we loved NodeJS so much, we are considering it for one of our upcoming awesome project (Surprise Surprise!) and we are finding it promising enough to replace any of our existing technology stack. And if you are not so sure about the performance of NodeJS, you might want to look at these benchmarks.
So what do we think is the biggest problem with Javascript? Mindset. We, developers, do not treat Javascript to be a programming language which needs as much attention and learning as any other language. But at Haptik, every one of us believes that Javascript is just like any other programming languages and you should learn it first before implementing. Javascript has come a long way and it needs its due respect. And with ES6 it is going to be more matured and with browsers becoming more powerful we can do more creative stuffs with Javascript. So if you are a javascript junkie like we are, then do drop us a note at hello@haptik.co and we would love to hear what you have to say. We hope, together we can improve the quality of Javascript coding and the mindset too 🙂
Lastly, here’s a great watch from the man himself, who has seen Javascript fall and rise:
This post is written by Nabendu Karmakar, Full Stack Engineer at Haptik.
