Six things JavaScript needs to learn from Java

The amount of creativity currently happening the realm of JavaScript (JS) is simply amazing. People invent all kinds of nifty tools and extensions. But with that comes fragmentation and the proliferation of JS frameworks has turned JS into an assembly of incompatible sub-languages. In contrast, Java has standardized the following six things and JS should do the same. After listing them, this post points out consequences (tooling!) and future developments.

1. Standardized inheritance: Java has acceptable inheritance built into the language (although primitives are a nuisance and traits or mixins would be nice). In JS, if you want to do inheritance, getting by with just the language is painful. Thankfully it is easy to extend it and that lead to some very nice inheritance APIs. But there are simply too many of them. And most of them are much too complex. The most minimalist yet elegant solution I have seen so far is John Resig’s Simple Inheritance [1].
   
2. Standardized modules (packages): Similarly to inheritance, JS can be extended easily, but there is no common standard. CommonJS might find some mid-term traction, though.
3. Standardized type information: I am not using the term “type annotations”, in order to avoid confusion with Java’s annotations. Having type information is natural in Java, because it is statically typed. JS is a more dynamic language and does not strictly need it. However, many APIs do include types as comments or in external specs. For example, Mozilla uses Web IDL in specs such as the IndexedDB API. It would be nice to have the standardized option for adding this kind of information so that tools have something to work with. Static analysis, e.g. done via DoctorJS, can infer many types, but I would still like the option to add this information explicitly. As an aside, if an IDE did type inference, then I would love to see the inferred types, e.g., next to the formal parameters of a function.
4. Standardized API comments: Java has JavaDoc, JS has several competing standards.
5. Standardized unit testing: JUnit is the dominant standard for unit testing in Java, while almost every JS framework comes with its own implementation.
6. Standardized runtime library: While Java’s runtime library is not perfect, having it is great. JS should have more standardized APIs and save JS frameworks from reinventing the wheel. An even better example of useful built-in functionality is the runtime library of Python. This would allow one to use JavaScript for many scripting tasks. node.js packages are an important start.

These six points are partly responsible for Java’s excellent tooling. Without them, it is doubtful that JS will ever catch up. So you can read this post as a check list of things that an IDE has to tackle in order to be truly useful (understand inheritance, the structure of the code base, typing, etc.).

Note that apart from the above mentioned points, JavaScript does well compared to Java. Most of the JS core has always been pleasantly succinct (closures, first-class functions, object literals, etc.). ECMAScript 5 is now universally accepted as a standard for the next JS version. And what one reads about the version after that, JS Harmony, is very promising.

Which of the above points present long-term problems? I expect (1) and (2) to eventually become language features, but it would still be nice if everyone could agree on standards until then. (3) might make it as type guards into JS Harmony. (4), (5) and (6) can only be tackled via standardization.

Related post:

1. Lightweight JavaScript inheritance APIs