JavaScript Wrap Up

1. The Javascript engines at the time were some of the slowest interpreters out there. Things that would make Ruby look like a speed demon, so they were not commonly used.
2. XMLHttpRequest did not exist at that time — the only way to do dynamic content way back then was to have a 1 or 0 pixel width/height frame (no iframe, yet) where Javascript code would cause it to navigate to a new URL, then read out the contents of the frame, and then update the *real* page. But the only consistent way to get contents from the frame would be through the DOM on an HTML document — so your Server-Side Javascript would have to generate raw HTML (not something it was terribly good at), then the client side would have to use the DOM (which was also comparatively slow just like Javascript) to read the contents and then inject the contents where it should go.

In reality, pretty much no one did this. Since most web pages were basically static content injected into specific sections of the HTML markup, languages good at string manipulation, Perl, ColdFusion, ASP, and PHP, took hold. Javascript was too cumbersome, not because Javascript-to-Javascript doesn’t make sense, but because there was this thick Javascript-to-"String Manipulation of HTML"-to-"DOM Manipulation of HTML"-to-Javascript interface between them. Not only was the HTML an abstraction, but the server side used an entirely different mechanism from the client side to work with that HTML, so code sharing was much lower than you’d expect.

On jQuery, it is a fine library, but we should note what it *really* is: the product of slow-to-react browser developers implementing different features at different rates. Did you know that the classic jQuery functionality, the actual querying of DOM elements by using CSS selector rules, is built into the DOM?

Suppose you wanted to get all elements that have the "comment" class attached to them.

jQuery:
var comments = $(‘.comments’);

DOM:
var comments = document.querySelectorAll(‘.comments’);

That’s not so bad. 4-5 months from when a concept is prototyped by independent developers to when the w3c produces a useful standard for browser developers to implement (guaranteed faster since they can use the internal CSS engine’s code that grabs the relevant HTML nodes from their internal HTML data structures, rather than use the abstracted APIs given to Javascript).

It took over *two years* for the fastest browser (Chrome) to implement the functionality and over *three years* for the slowest (Opera) to do so. I think that also demonstrates just how much faster it is to get useful applications written in Javascript versus static languages.

A one year period between when you could first start using the DOM interface to when you could rely on it across all browsers, while you could use jQuery to do the same thing for over two years already, and jQuery would detect whether or not the DOM provided the desired API method and use that instead if available, so you maintain cross-compatibility between all browsers and get the best performance available to each browser.

Because of that, jQuery started to expand to take over other DOM APIs, such as XMLHttpRequest, which only became unified between all of the browsers around the time of IE 7 (and now they’re adding new functionality to it that is in Firefox 6, Opera 12, is coming to IE 10, and Safari/Chrome don’t have a release schedule for).

jQuery doesn’t do *anything* that the DOM can’t do, but jQuery is a single target and the DOM has actually been a constantly-shifting target. For any significant DOM manipulation, it’s better to target jQuery and let it figure out what DOM calls should be done for the browser it’s running in.

jQuery doesn’t make sense in GNOME’s implementation of Javascript, in generic Node.js applications, in MongoDB, etc. Javascript the *language* has nothing to do with the DOM, only Javascript the *browser scripting language*, which until recently have been one-in-the-same, does jQuery make sense.

Are there flaws with the language? Yes. Javascript’s type coersion is complex (mostly because + is used for both addition and string concatenation, which is another flaw), there are rarely-used features of the language that are being phased out (the with keyword, for instance), and as I mentioned earlier, Javascript is gaining a module system (currently it’s below the level of C — no standardized pre-processor for including other Javascript source. You have to explicitly concatenate the files [or in the browser, specify multiple <script> tags]), and it’s getting optional strict types for higher-performance code.

I’d argue that there are far fewer issues with the Javascript syntax and semantics than with C++, and that’s part of why rapid prototypes (like experimenting with new networking protocols I mentioned in my last email) are so much easier in the language.