JavaScript Language Abstractions
ejohn.org
ejohn.org
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.
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.)
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.
I only assert that once your (well, my) code base grows beyond a certain size---for me, a few thousand lines, but probably an individual threshold---JS can start to become unwieldy. That "unwieldy-ness" is a problem that Java/GWT does solve. In these cases I prefer Java precisely because it is more constraining.
"It's possible to write good JS code" implies that it's not easy or obvious, and "it just takes some self-constraint" implies that in fact you have to be damn good to understand what you're doing.
That's fine, but mere mortals need a programming language too. Fact is that most large projects are not made of up entirely A+ developers (nor should they have to be).
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]
objj_msgSend(object, "message");
Macros.
Luckily core JavaScript is also pretty flexible, which is what allows you to implement your own class system, package system and so on, on top of vanilla JavaScript. And this is basically what language abstractions like GWT, Cappuchino, Pajamas and so on does. They are basically a set op macros on top of JavaScript.
I just think they throw out the baby with the bathwater by implementing a different language on top of JavaScript rather than just extend and improve existing JavaScript in a backwardly compatible manner. This forces the language abstrations to create their own set of libraries, which will never be as good as the native JavaScript libraries. You get caught in a ghetto, and isolate yourself from the broader JS communkty.
My own approach is to embrace and extend JavaScript in a bachwardly compatible manner, such that you can still use the large amount of native JavaScript libraries. Ideally "language abstraction" should be orthogonal to library abstraction. I want a more powerful JavaScript, but I also want to keep using JQuery.
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.
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.