JavaScript on my shoulder

At first, I did not want to write this blog post, out of respect to Brendan Eich, the creator of JavaScript and to Dmitry Soshnikov, an outstanding ECMAScript theorist who has provided great insight and superb material about JavaScript. You have to understand the conditions and constraints under which JavaScript was made; and if you add to those the unsurpassed engineering that went into its interpreter to achieve its multiple paradigm support, then you will really appreciate the awesomeness of Brendan Eich. And if you read Dmitry Soshnikov’s material, not only will you fully understand JavaScript, you will also be truly amazed by his knowledge and all-encompassing presentations and explanations. He is unbelievably good.

But appreciation and admiration can only get us so far. For example, what would have happened if Newton had not expressed his own opinions and had instead suppressed them out of respect for Aristotle? Then certainly we would not have advanced in Physics that much. And what would have happened if Darwin had not expressed his own opinions and had instead suppressed them out of respect for the ministry? Then certainly we would not have advanced in Biology that much.

We have to express our opinions and pinpoint the things that bother us. So, this blog post is against JavaScript. I wrote it specifically to bash JavaScript, because I find that JavaScript is a language that has a very bad syntax. I intend to explain my point of view. But I first want you to really understand what urged me to decide to write this post.

Of course, JavaScript’s omnipresence is one thing that makes me consider putting it under harsh criticism. As the chosen client-side scripting language of the web, it should be rather good; at least one would hope so. But what really motivated me to go against JavaScript is the amount of young people I see studying it and feeling proud that are becoming JavaScript experts. In my opinion, they should certainly become JavaScript experts, since they will use JavaScript. JavaScript is used more and more. Now, in Windows 8, it is becoming a first-class language. JavaScript is also used in the server side as well, with Node.js for example. But, in my opinion, JavaScript experts should not be proud of their expertise. And they should not be proud, because JavaScript has a bad syntax and is a bad language, really.

Young people and web designers have to learn JavaScript and become experts. The problem is that the knowledge of this language bestows upon them a skewed and deformed view of what the traits of a good language should be. Since, by learning JavaScript, they will become able to support themselves and their families, they will be able to earn a decent living, and, they will be sought after by recruiters and employers, it is dangerous that they will consider JavaScript as a rightful approach to programming. They may of course appreciate the benefits of being able to have a job, but we should not let them fall into a wrong sense of appreciating programming languages. We should not have JavaScript poisoning the view of programmers, especially young ones.

When I see young people going down a wrong path, I always feel sad, so that is the reason I decided to write this blog post, after all.

My biggest complaint, as far as JavaScript is concerned, has to do with its syntax. JavaScript uses the “function” keyword and construct. With that, it achieves to be procedural, object oriented, or rather, prototypical, and also, functional. Yes, JavaScript is a multi-paradigm language and this is actually desirable. The problem is that there are very subtle changes in the language syntax for such huge variations in programming behavior.

Functions in JavaScript are first class citizens. Now this is something that a big fan of functional programming like me, should appreciate. But, again, the problem is that functions are used for everything and it is hard to understand what exactly they accomplish each time.

Let us take closures for example. JavaScript can have functions behave as regular functions, or it can have functions behave as closures. But there is no such keyword as “closure”. There is no keyword for closures at all. To create closures, you have to write a parent function that has a child function inside it and that it (the parent function) returns the child function. The child function is then a closure. So, the way you write and structure your program defines not only how the programs’ elements behave but what the programs’ elements are. I do not like that. I think it would be better if you could explicitly denote the definition of each element.

And we haven’t even started. Things go downhill from here onwards and I am not sure I want to go that road. You see, functions are also used to perform object oriented or, rather, prototypical based inheritance and also functional programming. Although there is the keyword “prototype” to denote objects (functions) that will be used as prototypes, the whole prototypical inheritance implementation is convoluted at best. It is not easy to create inheritance in JavaScript, because the syntax does not help. As a matter of fact, it is messy.

Another thing is that although prototypical inheritance is superior to object oriented inheritance, JavaScript almost forces you down the path of prototypical concepts, whether you want it or not. And this is not helpful either.

By using functions for everything and having a syntax that hardly differentiates between vastly different programming techniques and paradigms, JavaScript code appears, at least to me, as a foggy, muddy, dangerous swamp. A swamp that you had better stay out of, if you can.

But I do not usually compare JavaScript and JavaScript code to a swamp. I usually compare them to a stone. I like to give a fictitious example. Let us say that a young person comes to us and she wants to learn how to do things. So we give her a stone. Now, when she comes to us wanting to nail a nail, we teach her how to use the stone as a hammer. When she comes to us wanting to cut something, we teach her how to use the stone as a cutter. When she comes to us wanting to eat, we teach her how to lay food on the stone as in a plate. Now, the stone might not be the best artifact for each of those purposes, but it gets the job done and our young apprentice may be content. But someone has to tell her to either find another multi-tool or use different tools all together. The stone is good for none of these uses.

The same goes for JavaScript. A person might use it and learn how to perform tasks and write programs using different techniques and paradigms, but she will be using a bad, implicit syntax that corresponds more to a hacker trying to cram things together than to a clear approach to coding. Just like the stone, JavaScript syntax is good for none of the paradigms JavaScript supports.

Skeptics might say that I should “put my money where my mouth is” and come up with a design and syntax that is better than JavaScript’s. I am not sure if I want to do that. But it certainly can be done. First, if I really had to do it, if I really had to create a multi-paradigm scripting language for the web, multi-paradigm but prominently prototypical, then I would use functions as first class citizens, but I would make sure that every technique and paradigm was clearly and explicitly defined and named.

But I do not think I should go down that path. One of the reasons is that it has already been done. And it has been done with a whole lot of different approaches. Oh, yes! What, you though that all those JavaScript libraries that come out are to provide more functionality? Well, usually, their only purpose is to hide the ugliness and craziness of JavaScript’s syntax. And, thankfully, some of these libraries have done a pretty good job.

Now, skeptics might again argue that, since these libraries are written in JavaScript, I am being very ungrateful to JavaScript. Since a scripting language such as JavaScript gives you the tools to change it, then it really has awesome abilities and I should not complain. Of course JavaScript has awesome abilities. I am not complaining about its abilities, though, but about its muddy syntax.

Another reason I would like to be excused from providing my own design and syntax for a replacement to JavaScript, is because I believe that the ultimate replacement has already being introduced. I am talking about Google’s Dart. Dart is a language that can replace JavaScript and that is object oriented and not prototypical. But I think that this is for the best. An object oriented philosophy is what all programmers seem to want and strive for, when it comes to the usual use of JavaScript programming.

When I read about Dart and when I saw it afterwards (very soon after it was released for the first time), I felt vindicated. I was thankful that someone thought and felt exactly like me, because everything about the Dart language was exactly as I would want it to be. This should have been the client side scripting language that the web should have had from the get-go. Unfortunately, some strange twist of fate forced JavaScript upon us, way back then.

Now, experts have expressed some objections about Dart. But experts’ objections have nothing to do with Dart in comparison to JavaScript. We are past that. Dart is way better, no doubt about it. Their objections only have to do with Dart being less advanced than it could be. But the point I am trying to make is that Dart shows us exactly what we should have had as a scripting language for the browsers. Finally we can understand what we have been missing all this time and what a horrible substitute we had in its place.

I would like to make clear that most people learn JavaScript out of necessity and not because of its merits as a programming language. If instead of JavaScript, Dart (or something like it) was introduced in the beginning, the web and the world would have been better and fairer places.

Although JavaScript is needed and it is imperative to have a very good knowledge of it, people should not be proud when they become JavaScript experts. JavaScript is a language with bad syntax that tries to cram every paradigm into a few syntactic hacks, which makes programming cumbersome and unintuitive. It is obvious that if we had the luxury of starting over, JavaScript would have never been chosen as the client-side language of the web. It would have never been chosen as anything other than an ingeniously hacked assembly of sorts; an academic experiment that should have never been released in production.

About Dimitrios Kalemis

I am a systems engineer specializing in Microsoft products and technologies. I am also an author. Please visit my blog to see the blog posts I have written, the books I have written and the applications I have created. I definitely recommend my blog posts under the category "Management", all my books and all my applications. I believe that you will find them interesting and useful. I am in the process of writing more blog posts and books, so please visit my blog from time to time to see what I come up with next. I am also active on other sites; links to those you can find in the "About me" page of my blog.
This entry was posted in Web design. Bookmark the permalink.