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 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.
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 often add this information explicitly.
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.

These six points are partly responsible for Java’s excellent tooling. Without them, it is doubtful that JS will ever catch up. Apart from that, JavaScript does well. 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.

 

From http://www.2ality.com/2011/02/six-things-javascript-needs-to-learn.html