JavaScript

From APIDesign

Current revision

JavaScript was designed as a scripting language by Brendan Eich. As such it was for a long time considered an outsider among languages. However its presence in browsers and its ability to give HTML pages life makes it more and more attractive. But let's be honest - JavaScript is weird and nobody would use it, if it hadn't had its browser presence advantage. Real projects deserve real languages and as such I am huge supporter of Toni Epple's DukeScript idea.

Yet Another Assembly Language

For me personally, JavaScript is just another assembly language. An object oriented assembler people were seeking for in 80-ties. JavaScript as of 2015 is a famous target instruction set (just like Z80 or i386). Many languages compile to it. The reason is simple: if you want your program run everywhere, you need it to run in a browser and JavaScript is the language all modern browsers speak. As such we have a way to translate C (via Asm.js) to JavaScript as well Java (via my bck2brwsr VM or TeaVM). I don’t see any reason why people should code in assembler anymore. And certainly I am not going to do so myself – I rather spend a year to create a framework than to write directly in JavaScript.

I know large group of people that are fine with JavaScript, but face it: It’s a “Write Once and Never Touch Again” language. You write your code once and ship it when it works. Later, when you are asked to change something in it, you are afraid to touch it. No refactorings, as no tool can guarantee that your code will behave the same after refactoring (unlike in more restricted languages like Java), no huge changes – touch it only lightly and with care. It is often easier to start from scratch.

I hear complaints of this kind from executives everywhere. Especially if they have one gang of Java programmers and another of JavaScript developers in-house. They tend to see the latter as less reliable geeks always trying something new, but never delivering long lasting product. It may be a clash of generations (as JavaScript guys are usually younger), but I believe the root cause is the assembly nature of JavaScript.

OOP Assembly Set

To illustrate why I believe JavaScript is another assembly language, let’s think about a way to invoke original implementation in an overwritten method. In Java you’d use super keyword:

protected void aMethod() {
   // do something before inherited behavior
   super.aMethod(); // invoke original behavior
   // do something after inherited behavior
}

This is a common construct in classical object oriented languages, not only in Java. It makes it easy to do something programmers do frequently – for example, specializing behavior when subclassing. However super has its limitations: you cannot call super.super.aMethod() – e.g. skip level of inheritance. You cannot call super.aMethod on some completely different object, etc.

JavaScript does not have concept of super – however it has something more powerful: there is a call function where you can specify the actual method/function to call, on what object (e.g. this) and with what arguments. You can use the call concept to simulate super, but you can also use it in a number of other ways. It is flexible, but low-level. It is something that belongs to assembly language, but not something regular developers should use when coding their business logic.

I have to repeat myself: if you keep coding in JavaScript, you end up like everyone who’s using assembler: feeling powerful at first, but constrained in the years to come.

Impossible

Using JavaScript for any real project is impossible - maybe not impossible in the finite automata sense, but certainly as impossible as getting threading right. I am sure people will still try. People will still deliver good enough results, and people will have conferences to worship the way they do the things they do. In spite of that I am convinced Java has a lot of more to offer - Especially when we talk about Java as a language not bound by restrictions of HotSpot VM like in case of DukeScript.