jQuery: When does a library become a language?

jQuery is a great JavaScript library which allows web developers to write cross platform code, but some of its syntax looks like it is based more on Ruby than JavaScript. When does a library become a language?

So first of all, what is the difference betwen a programming library and a programming language?

A programming language is a means by which we (as humans) can give instructions to a computer to get it to do various tasks (algorithms, computations, etc...). They are largely artificial constructs created for human readability which then need to be compiled or interpreted into actual instructions which the computer can then carry out. A compiler turns a program into machine readable instructions ahead of time (compile time) where as an interpreter does so on the fly (runtime). Languages such as C and Java are generally compiled and JavaScript, Perl and Ruby are generally interpreted. While there is no real reason why this has to be the case, these factors normally affect the syntax of the languages in question.

A library is a collection of functions and methods of (normally) common actions which are not expressed in the original language. These are not included in the main language because not everyone will need to use them all the time. They are also written independently of the main language compiler/interpreter and they also encourage code re-use (so not everyone needs to write their own String.trim() function for example).

Because of the fact that there are many JavaScript interpreters out in the internet and JavaScript developers cannot control which one will be used to interpret their code, a few years ago some people released their own framework/libraries which iron out these differences and allow developers to write one set of unified code from which any browser differences could be abstracted out into the library.

The most popular of these are Prototype and jQuery.

jQuery primarily gives developers a generic way to access and manipulate DOM elements (one of the main differences between browsers).

However, the syntax used looks very different from plain old JavaScript.

Here is a typical JavaScript loop.

var elements = getElementsByTagName("div");

for (var i = 0; i < elements.length; i++){

alert(elements[i].id);

}

Here is the same loop in jQuery

var elements = $("div");

elements.each(function(i){

alert($(this).attr("id"));

});

Do these look remotely alike?

How about this?

JavaScript

var element = document.getElementById("myDiv");

alert(element.innerHTML);

jQuery

var element = $("#myDiv");

alert(element.html());

To the untrained eye, one might think these are different languages.

jQuery is not another language though, not only does it use the same JavaScript interpreter, not only is it useless without JavaScript (i.e. it is not independent), but in jQuery you are really creating and manipulating a jQuery object and you are given the option to access the JavaScript object it references using the get() method.

It is possible though to write a language based on another language. The Ruby runtime is essentially built on the C++ framework. JavaScript runs in browsers written in C++ as well. These languages have no direct relation to C++ in their syntax though. In theory you could probably write a C++ compiler in Ruby should you want to (though that would be pointless and slow). You can write programs which translate programs from one language to another (the Google Web Toolkit translates Java into JavaScript).

I would argue that jQuery is a dialect of JavaScript or else even a kind of JavaScript slang. It differs from the main language, but it doesn't veer far enough to be completely independent or incomprehensible.

IE6 Update

Calling all web developers.

The folks over at this site have done something wonderful.

http://ie6update.com/

Basically, you include this code on your site, and all IE6 users see a drop down bar which looks like an ActiveX update and links to download IE8.

This is such a brilliant idea. If MicroSoft won't force people to upgrade, then we, as a community, should.

CSS Hacks = Lying

There are many similarities between using CSS hacks and lying.

First of all, what is a CSS hack? A CSS hack is a means by which you can get different browsers and browser versions to see and render your stylesheets differently so you can give them different directions (ironically though it's normally done to achieve pixel perfect cross platform web pages). They are also mostly done for Internet Explorer (which for some reason refused to implement standards based CSS until recently).

CSS hacks mostly exploit bugs in a particular browser such as the Star HTML hack. This hack was used to get code to run in IE6 and lower in a different manner than other browsers.

IE also introduced conditional comments which allow you to add an extra stylesheet to "fix" any CSS issues. This is not technically a hack, but it does require you to write and maintain extra CSS.

There are also more subtle types of hacks to make up for some things that are missing in IE like the IE min-height hack (which adds min-height style functionality to IE).

So why is using a CSS hack like lying?

Well, when you tell a lie not only are you telling an untruth, but you are essentially telling one person a different story than someone else. This is not admirable behaviour, but you can probably get away with it, once or twice. However as you have no control (mostly) which clients can see your site this is akin to lying to someone whilst there are other people in the same room. After telling the lie you then have to sneak over to all the other people and tell them a story and hope the first person doesn't cotton on.

Often with lying (as with CSS hacks) telling one lie requires you to tell another one (and to keep track of all the lies you tell). You then end up with a snowball effect wherein you lose track of what is true and what is not and you end up with more code than you ever needed.

Why use CSS hacks in the first place?

Because not only do these little CSS browser differences open hacks, they often are the cause for rendering differences between the browsers. There is a temptation to therefore use other hacks to fix these differences.

So there is often a judgement call to be made as to how far you can push a hack, and pile hack upon hack. At some stage compromises need to be made in the design.

So basically, I am not saying one should never lie, in web development (like in life) there are times when you need to use hacks and there are times when you need to lie. Just be careful not to do it too often (and document it carefully).

One more thing, if you are going to be using a lot of JavaScript to move your page elements around, you need to be doubly careful about using CSS hacks as there are some browser differences that don't reveal themselves when a page is static (but do so when a page is dynamic).

Getting Search Engines to read Flash Content

Ok, so I lied. While Google supposedly now does index Flash content, what this article is really about is a quick a dirty way to get search engines to index your pages which contain Flash without having to display that content to the user in the HTML.

Basically this technique relies on swfobject (http://code.google.com/p/swfobject/). One thing swfobject does in dynamic mode is allows you to specify alternative content in a div for non flash users which gets switched out via JavaScript once the page loads:

    <script type="text/javascript">
    swfobject.embedSWF("myContent.swf", "myContent", "300", "120", "9.0.0");
    </script>

    <div id="myContent">
      <p>Alternative content</p>
    </div>

So basically you can duplicate the content which goes into the Flash app in the Alternative content section. Search engine spiders index HTML, but don't run JavaScript so are none the wiser that the user is actually going to see a Flash app.

The best case scenario is when the content in the Flash app is dynamic so you can easily duplicate it in the HTML. Static text needs to be manually copied. Most app related text will be instructional in any case and not really suited for search engines.