

JavaScript Language Abstractions - boucher
http://ejohn.org/blog/javascript-language-abstractions/

======
esessoms

        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.
    

I thought as a member of this mythical group I should speak out. I'm sure
there aren't many of us.

First, history: Roughly ten years spent programming in JavaScript (it's hard
to believe it was that long) before GWT came out in 2006. Immediately tried
GWT, found it too heavyweight, and returned to JavaScript (jQuery,
specifically) for another two years, before finally really moving to GWT over
the course of the last six months.

Experiences: It really is not possible to write a significant GWT program
without good knowledge of JavaScript. I think, on average, every Java class I
write has one JSNI (JavaScript Native Interface) method, usually to work
around some deficiency in the library but sometimes just to circumvent Java's
type system. That's not counting the classes that are pure JSNI that exist to
wrap up some JavaScript functionality.

It has also been my experience that it takes roughly 4 lines of GWT code to do
the work of 1 line of JavaScript (with a good library such as jQuery). That's
from comparing LOC counts on a handful of medium-sized projects I implemented
with both technologies.

So, why? The thing that keeps me using GWT even though it is an incomplete
abstraction that requires more code is _organization_. Partly that comes from
the fact that OOP is a better fit for GUI programming than the functional
paradigm. Mostly it comes from having a nice build system that lets me
organize my code in the traditional Java hierarchy. There are lots of ways to
try to organize large JavaScript projects---I think I've tried them all---and
none have every really felt satisfactory to me.

In the end, most of the time when I'm writing a web page I reach for jQuery
first. But when the functionality of a web page crosses over some ill-defined
threshold such that I start thinking of it as an application in itself, I
change my tools and reach for GWT, all for the benefit of (to me) better
organized code.

YMMV.

(Edited for formatting.)

~~~
smanek
I don't get why people so want to abstract around Javascript itself - it's a
great language. It supports OOP and functional programming (although,
admittedly, the prototype object system does take some getting used to) and
it's dynamically typed. You even get a REPL! (e.g., via firebug). I would
argue the js is far better than Objective-C and Java, and at least on par with
python.

Now, some of the DOM manipulation stuff is just annoying, but that's what
jQuery is for :-D

What do you like better about Java's object system than JS's? I prefer JS's
because it isn't as constraining - it doesn't force you to use it the way its
creators imagined. It's possible to write good JS code, it just takes some
self-constraint.

~~~
boucher
If the DOM is annoying, jQuery is no better. It's DOM++, at best. jQuery is
still the DOM, just slightly prettier. If you really believe the DOM is
annoying, why not just get rid of it?

People embrace the DOM because its there, but that isn't necessarily a good
reason. If jQuery is the C to DOM's assembly (not a particularly apt analogy),
why shouldn't we want to branch out to a higher level language? That's one of
the reasons we built Cappuccino.

Cappuccino is built on top of the DOM, because its the only thing that makes
sense right now in the browser world. But we do our best to make sure
developers don't need to worry about the DOM. Of course, as Spolsky would tell
us, all abstractions leak and ours is no exception. But, Objective-J is just
JavaScript. All the DOM is still there for you to poke at if you must. And the
point of Spolsky's article was _not_ that abstractions are bad, just that you
should learn what you're abstracting, then use it. Abstractions do save us
time, even when they leak.

As far as Objective-J itself is concerned, there were clear motivations for
building it. JavaScript lacks dynamic message sending. It lacks classical
inheritance. It lacks an import mechanism. We looked at what we felt was
missing, and what the best way to fix it was. Turns out, Objective-C was
created with exactly these same goals. It was a natural fit for what we
needed, right down to implementation level details.

It's important, then, to realize that Objective-J is _not_ about being
Objective-C in the browser. It's a better JavaScript. It's a strict superset,
so if you just want to use JavaScript, go ahead. If you want to benefit from
our hard work and new features, like dynamic code importing, then you can use
Objective-J. It even has a REPL:
<http://tlrobinson.net/misc/console_bookmarklet.html> (and a command line
version, objj)

Objective-J is also far different in its implementation than Pyjamas or GWT.
It's nothing but a preprocessor and a dynamic runtime. It is _not_ a compiler.
This means that, in general, the post processed code looks like a slightly
uglier version of what you really wrote.

    
    
        [object message]
    

is just

    
    
        objj_msgSend(object, "message");
    

In that small syntactic change, you're actually conveying a great deal of
meaning, and enabling some really powerful features. All with effectively no
run-time performance cost, and with no need to compile since the Objective-J
preprocessor runs in the browser.

~~~
smanek
Some of that sounds very impressive. Truth be told, I haven't played with
Cappuccino much yet - but your post just inspired me to go take a closer look
at it. Thanks.

------
olavk
The problem with abstractions like GWT is that they build a completely
different and incompatible abstraction and on top of JavaScript. The benefit
of extensions like packages, type checking and so on may be large, but the
cost is also large because you have to abandon compatibility with existing
code and libraries.

Mascara (<http://ecmascript4.com/>) is a different approach - it extends
Javascript with classes, types, namespaces and so on, but it does it in a
backwardly compatible manner, so you can still utilize your old code, use
JQuery and so on.

~~~
boucher
I don't think you understand how Objective-J works (or GWT, or many of these
other tools). You can use any existing JavaScript code in combination with
Objective-J code. You can use any existing JavaScript code in combination with
GWT too, if you do a little work.

Writing an ECMAScript4 to JavaScript translator is really no different than
writing an Objective-J to JavaScript one, except Objective-J runs in the
browser, not on a python script running on a server. Objective-J runs natively
in the browser, an impressive feat.

