One of the more annoying things about being a Java developer is the stigma the language developed far too early in its existence from being “that Applet language”. You'd mention Java and the first thing that popped into anyone's head was those annoying, out-of-place and usually worthless applications that dotted websites before everyone gave up on Java and turned to Flash for their annoying out-of-place and usually worthless applications. It was unfair1, and I would spend far too much of my time pointing out that when you took Java out of the web browser, it was actually pretty useful.
As such I feel I owe Javascript an apology as, if only through laziness, I have been committing the same sin in its name. When recommending JQuery to co-workers, friends, random passers-by and the occasional hobo (as I have been wont to do recently) I have tended to summarize its merit as “it makes Javascript not suck.” Which is rubbish. Javascript has always been perfectly cromulent. What JQuery does is make the DOM API not suck.
The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed and the results of that processing can be incorporated back into the presented page. — W3C
The fatal words here are “language-neutral”. And the particular definition of language-neutral that the W3C uses here is “Java and Javascript”.
The W3C only defines normative bindings for Java and ECMAScript, however we also reference known non-W3C DOM Bindings for languages other than Java or ECMAScript. — ibid.
This is a problem. Java is a strongly and statically typed language with a Smalltalk-style object model. Javascript is a loosely and dynamically typed language with a prototype-based object model. Force them to share an apartment and you've got an instant sitcom. Try to write an API common to both languages and you'll end up having to pick the lowest common denominator.
Which is why DOM manipulation looks like a Java API. Java developers, bless our hearts, are used to the kind of API that requires five lines of code just to populate an array. What JQuery and its ilk do is provide a way of manipulating the DOM that is idiomatic Javascript rather than a strange transplant from another language.
I guess the fact that there is starting to be such a thing as idiomatic Javascript demonstrates if not a maturity of the language, then at least a promising late-adolescence.
1 Java has since accrued more deserved stigmas, but that is a story for another day.
You know what's funny about this? I was just thinking today about the XML DOM API, and realizing that the reason it's such a total pain in C++ (I have no end of trouble keeping track of what needs deletion and what doesn't) is that it was written in a language with a Garbage Collector. Like Java.
Why do we even try to have language-agnostic APIs? It never really works out in the end (see: C++ CORBA bindings)
If you look closer, I think you'll find JavaScript's object model is more similar in style to Smalltalk than you realise. The whole class-based inheritance thing is a bit of a distraction.
Totally agree with the rest of your thoughts though.
OK, I know what static and dynamically typed are (they have a pretty clear definition), but "strongly typed" and "loosely typed" seem to be defined differently by anyone who cares to use those terms (see the aforementioned link). How are you defining them?
Aside from that, nice writeup. Javascript, despite some quirks, is a lovely language. It's the DOM which has always given me fits.
Mark Pilgrim gives a pretty good definition in the first chapter of Dive into Python (although he says ‘weakly typed’ rather than ‘loosely typed’:
A good article, with one major exception:
Java doesn't have a Smalltalk-style object model. Both languages are class-based however in Java method invocation has procedural semantics while in Smalltalk method invocation has message-passing semantics. This may seem academic but it has a huge affect on computer programs written in the languages.
I used "Smalltalk" as a shorthand for "single-rooted inheritance where an object's class determines its type, and methods are defined as ‘belonging’ to a particular class", to distinguish between that and things like CLOS's generic functions and Javascript's slots-and-prototypes approach. There are obviously significant differences between Smalltalk and Java such as Java's early binding of method calls.
That said, I've never programmed in Smalltalk beyond a few random pokings at Squeak. If anyone has a good link to the practical definition of the difference between message-passing and procedural semantics, I'd love to read it.
You're definitely on the right track here. Because the DOM is language-neutral, it has to abide by the least common denominator of any conceivable language and define a narrow, clumsy API.
(The only modern "feature" assumed by the DOM API is some sort of OOP, though PHP4 circumvented that easily by requiring the node to be passed in as the first argument to any function.)
Consider that every argument passed into a DOM function must be either a string, a number (including constants), a boolean, or null. (Plus addEventListener can take a function, obviously.) When Firefox implemented the WHAT-WG's proposed "document.getElementsByClassName," the proposal that one be able to pass in an array of class names was rejected simply because no other DOM methods accept arrays and they didn't want to cross the Rubicon.
Consider that the node collections returned by DOM methods aren't actually arrays, no matter which language you're operating it. In JS, you can use the bracket notation to refer to items in the collection, but this is a rare nugget of usefulness given to us by the ECMAScript DOM Binding; the spec itself provides for them to be accessed by an "item" instance method instead.
Consider that there's a DOM method that takes fifteen goddamned positional arguments.
So, yeah, even if there were no bridging or fixing or normalizing to be done, we'd still need JavaScript libraries to give us better APIs. All frameworks start out as macros for the tasks you do most often.
Actually, there are many more differences between Smalltalk and Java than simply (well, not simply at all) how you invoke a method.
Let's start with the very basics: Java classes are not Objects. At all. And since they aren't objects, they don't have to belong to a class either.
That alone not only makes Java very different from Smalltalk, but actually makes Javascript much more like Smalltalk than Java, at least in my eyes.
Then there's the question of late binding vs early binding. That's more of a question of flavour, imho, but it makes Smalltalk more akin to dynamic languages than a static language like Java.
Frankly, if you think Java is at all similar to Smalltalk, do yourself a favour and learn Smalltalk, if only the basics.
Er, I know all this. While I haven't done any Smalltalk programming “in anger”, I'm not exactly ignorant on the subject either. Suffice to say no commenter has actually mentioned anything I didn't know already.
Obviously, Java and Smalltalk are very different languages. Just as obviously Java's object model—that is, how objects are given identity and behaviour through classes, and how classes are organised into an inheritance hierarchy—is derived from Smalltalk's. The differences are real and important, but not relevant enough in context to deserve further remark in the post.