Javalobby
Did you know? DZone has great portals for Python, Cloud, NoSQL, and HTML5!

Dr. Axel Rauschmayer is a freelance software engineer, blogger and educator, located in Munich, Germany. Axel is a DZone MVB and is not an employee of DZone and has posted 228 posts at DZone. You can read more from them at their website. View Full User Profile

Six things JavaScript needs to learn from Java

02.14.2011
Email
Views: 5611
  • submit to reddit

We Recommend These Resources

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

Published at DZone with permission of Axel Rauschmayer, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Pavel Tavoda replied on Mon, 2011/02/14 - 6:30am

But generally what you want is GWT. Or at least you can find more pros than cons in GWT for your dream.

Axel Rauschmayer replied on Mon, 2011/02/14 - 10:19am

Good point. I’m a big fan of GWT’s. And you are right, its tool support makes a huge difference. Also, it does clever things with compiled CSS, images, etc.

Points in JavaScript’s favor:

  • The language has a lot of momentum and enthusiasm behind it. Just as Oracle kills some of Java’s momentum. (Note that I’m not an Oracle hater, Sun has made its own share of mistakes and Oracle does bring stability to the platform.)
  • JS Harmony is going to be one heck of a language. Optional type guards plus dynamism will enable some great development environments.
  • Node.js is shaping up to be a great server environment. This increases the appeal of going all-JS on both client and server.

Andrew Spencer replied on Mon, 2011/02/14 - 11:29am

The main reason Java achieved those things was the control Sun had over the technology: a single language specification, a single set of standard libraries and a single spec for the runtime environment.

It'll be years before we can get anything similar for Javascript, because even if a standard is agreed tomorrow (which it won't be), we won't be able to benefit from it until most users have stopped using the non-standards-respecting browsers. You only need to look at IE 6 to realise how long that can take...

Pavel Tavoda replied on Mon, 2011/02/14 - 12:15pm in response to: rauschma

I can't agree with 1st and 3rd point.
  • I feel Java momentum with each release of each framework. I feel big Java momentum in areas like OSGi, cloud, GWT, JSF, ... . Isn't "momentum" some marketing term anyway ;-).
  • I don't believe in untyped server side. I can imagine to program client side where untyped is advantage because of user interface dynamics and nature, but NEVER for server side. I guess Groovy or PHP can give you more value than JavaScript on server side.
Of course this are my very personal subjective feelings of hard core Java architect.

Balint Persics replied on Mon, 2011/02/14 - 1:19pm

"In JS, if you want to do inheritance, getting by with just the language is painful. "
JavaScript is not a true OOP language, basically and truly it is a funcional programming language in the sense that functions are first-class entities, that's why there are prototypes, not superclasses.

Axel Rauschmayer replied on Mon, 2011/02/14 - 1:27pm in response to: pavel.tavoda

  • Java definitely also has a lot of momentum. JVM languages are a prime example. You can also call it "excitement" instead of "momentum" if you want to. In the user-facing part of applications, JavaScript currently has a more compelling story (with web browsers) and I think that leads to a lot of mind share.
  • JS on the server does not have to be untyped if Harmony really brings type guards. The killer feature of node.js is its asynchronicity where current JavaScript practices are a surprisingly elegant fit for the server.
So GUI-wise and server-wise, JS currently is avant-garde, similar to Ruby on Rails a few years ago. Just like with RoR, I’m sure other platforms will adopt some of the JS innovations.

Axel Rauschmayer replied on Mon, 2011/02/14 - 1:33pm in response to: persicsb

Yes and no. Prototypal inheritance, if done well, can be very elegant [1] and feel more object-oriented than class-based inheritance. If you don’t do inheritance, object-orientation works well in "pure" JavaScript, otherwise you need to use one of the APIs.

[1] http://www.2ality.com/2010/12/javascripts-prototypal-inheritance.html

Pavel Tavoda replied on Mon, 2011/02/14 - 2:55pm in response to: rauschma

- Yes I agree with you in first point but for me this mean GWT. I can do same as everybody in JS just with all features you requesting in your blog with GWT. JS is library like any other native code inside, and bellow JVM.
- In second point, I'm sorry but standard servers in Java have very good threading model with thread pools, limit(ed) queues, session model, .... You can't (or very hard) achieve better throughput as with tuned Java servlet engine. Look for tuning, monitoring, settings, async support in any popular servlet engine (tomcat, jetty, weblogic, ...).
- RoR is now more avant-garde than year ago, and I'm unsure about any JS innovation which Java can adopt. Specially looking on your blog, you are simply missing Java features in JS.

Antonio Santiago replied on Mon, 2011/02/14 - 4:29pm

I agree completely with your first 5 points. Great post Axel !!!

Ahmed Al-hashmi replied on Tue, 2011/02/15 - 1:10am

Agree

Dominique De Vito replied on Tue, 2011/02/15 - 5:31am in response to: rauschma

While JS is evolving and going closer to Java, IHMO it "validates" GWT future.

This makes good points for GWT.

The JS evolution is somewhat funny. In the past, some people said JavaScript was related to Java, or even, was a Java evolution. It was a false piece of news. But these days, it starts to become somewhat true.

A false piece of news may become real as Java and JS move closer

 

Axel Rauschmayer replied on Tue, 2011/02/15 - 8:54am in response to: dv103856

Yes, if you invent your own class system and compile JS to JS, you might as well compile Java to JS (and have better tools to boot). With JS Harmony, things will change, because JS will become a very compelling language.

Roger Voss replied on Tue, 2011/02/15 - 9:41am

Implement Adobe ActionScript 3 as a compiler that generates JavaScript code. It does all those bullet points and has additional niceties such as namespaces.

Yes, Google has already done this approach with GWT, but ActionScript3 is a much better synergy of the goodness of JavaScript fused with the goodness of Java. Whereas GWT is just straight Java syntax.

So a JavaScript progammer will tend to feel more at home in ActionScript3 and can still readily do the dynamic things of JavaScript.

If this is kept to just a compiler and nothing more, then it will be more universal than GWT and potentially usable with all JS frameworks.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Controlling complexity is the essence of computer programming.
— Brian Kernigan