JavaScript Language Abstractions


The other day I was looking at pyjamas (which bills itself as a GWT-like tool for Python). I was also reminded of the semi-recent release of Objective-J.

Pyjamas, GWT, and Objective-J all hinge around a central concept: Abstracting away the authoring of JavaScript-heavy web applications by allowing the developer to program entirely in their natively language (be it Python, Java, or an Objective-C-like-language accordingly).

This is a large abstraction – much more so than what is provided by most JavaScript libraries – you are programming in another language which is outputting JavaScript code. You are likely to never see a DOM object or any pieces of the native JavaScript language.

I worry about large abstractions like this for a number of reasons.

When you use a pure-JavaScript library (such as jQuery, Prototype, Dojo, Yahoo UI, etc.) you are still programming using the JavaScript language. In the case of jQuery a large number of users, who have either never programmed JavaScript before or never programmed before, acquire a good grasp of how to use JavaScript – accented by the use of the library. A pure JavaScript library makes annoying tasks simple, the largest of which being cross-browser support. It does nothing to dilute the quality of the JavaScript-authoring experience. In fact I would argue that JavaScript libraries do much to give JavaScript a particular style and feel. Code written with Prototype feels very different from code written with jQuery – and this is fine since it’s giving the user the option to develop in the JavaScript language how they best see fit.

In the case of these language abstractions you are gaining none of the benefit of learning the JavaScript language. When a leak in the abstraction occurs (and it will occur – just as it’s bound to occur in any abstraction) what resources do you have, as a developer, to correct the problem? If you’ve learned nothing about JavaScript then you stand no chance in trying to repair, or work around, the issue.

It could be stated that these tools could work well if a developer already has some knowledge of JavaScript but neither pyjamas nor GWT sell themselves as such (Objective-J recommends, but does not require, some basic JavaScript knowledge). I think such a developer (one that has strong knowledge of both JavaScript and Java/Python/Objective-C and still feels compelled to use one of the abstractions) doesn’t really exist – at least not in any significant numbers. A developer who is capable of authoring JavaScript code should naturally gravitate towards authoring as close to the final product as possible. It will give them greater flexibility when developing and allow for the greatest amount of control.

A huge benefit of JavaScript is that it’s a proverbial melting pot of experience. Developers from all backgrounds code in it (those who program Java, PHP, Perl, Ruby, .NET, or any other server-side language) and it lends a lot to the style of JavaScript code that you see in the wild. By writing in a single-language stack you miss out on this collaboration with other developers. Java developers now only communicate other Java developers (for example). While this may be fine for some projects it certainly limits your range of experience that you can draw from.

All of this being said these stacks have some excellent features that you can draw on. In the case of GWT you can use all of the normal Java-debugging techniques and continue to develop in your IDE of choice (even including Eclipse integration). Additionally since the framework has full control (both client and server-side) it can selectively send parts of the codebase depending on the browser. This is very interesting and having this full stack for development makes it quite lucrative.

I should mention here that I’m a creator of a JavaScript language abstraction: Processing.js. You can write Canvas visualization using the Processing language (no apparent JavaScript involved). I included support for the straight Processing language for a single reason: Because it would allow for all the Processing demos to be able to run unchanged. Beyond that I don’t really see a good use for using the Processing language abstraction to author scripts. Some people have done it but I don’t really encourage it.

Instead you can use the full Processing API from JavaScript:

  1. var p = Processing(CanvasElement);
  2. p.size(100, 100);
  3. p.background(0);
  4. p.fill(255);
  5. p.ellipse(50, 50, 50, 50);

I consider this to be a good compromise: Take the good parts from one language and bring them to JavaScript to allow for the greatest amount of flexibility and control – without a massive abstraction.

Posted: December 6th, 2008


If you particularly enjoy my work, I appreciate donations given with Gittip.

124 Comments (Show Comments)



Comments are closed.
Comments are automatically turned off two weeks after the original post. If you have a question concerning the content of this post, please feel free to contact me.


Secrets of the JavaScript Ninja

Secrets of the JS Ninja

Secret techniques of top JavaScript programmers. Published by Manning.

Ukiyo-e Database and Search

Ukiyo-e.org

Japanese woodblock print database and search engine.


John Resig Twitter Updates

@jeresig

Infrequent, short, updates and links.


via Ad Packs