[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.

[halo]

The reason people use jQuery is because the default mechanism for accessing elements is longwinded and ugly. It's the exact same reason people use xml.etree.ElementTree over the W3C-style xml.dom.minidom in Python's standard library. Assuming that people want rid of it completely because they want a better interface is a rather bold assumption, especially when you consider the flexibility using the DOM provides.

[boucher]

I find, in your own words, recognition of several reasons JavaScript fails for building complex systems.

"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).

[olavk]

JavaScript is pretty limited. It lacks features like packages, classes and so on. Brendan Eich, the inventer of JavaScript, have stated that the language was frozen prematurely due to political rather than technical reasons.

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.

[tc]

I don't get why people so want to abstract around Javascript itself

Macros.

http://common-lisp.net/project/parenscript/

[esessoms]

Oh, I don't for a second dispute that JavaScript is a much more elegant language than Java, and I would also put it on par with Python. Remember, jQuery is always my first choice.

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.