Skip to Content

Accelerate your JavaScript Development

Javascript is a powerful language if you know how to use it for more than simple roll-overs. But, taking on a large scale Javascript based application can be time consuming, and troublesome. The benefits may very well be worthwhile, but if you do all the code yourself, your project might take longer than you'd like to complete.

Enter the libraries. There are a HUGE number of specialized libraries on the Net, for things like Ajax, animations, drag/drop, etc. In the past year or two, these libraries have begun to be consolidated into high level packages that can accomplish a whole lot in a very efficient manner. Making use of these packages can make your life very easy, and remove the need to manually code common functionality.

At the moment, there are two dominant libraries you might consider:

These packages provide a core set of functionality which is then expanded on by other packages or plugins.

The packages

prototype.js has some very good ideas and does help simplify your coding. However it does have one unfortunate drawback - it's name. Prototype means something within JavaScript itself, so there is often confusion when talking about this package. For example, if I were to tell you to use prototype to solve your problem, would you use the prototype.js library, or would you use the prototype base object native to Javascript? (in JS, you can say something like "myobject.prototype.myfunction = function () { ... }" to assign a function to ALL instances of "myobject". Prototype in this case is NOT the same thing as the Prototype library.) Perhaps a future release will do something to address this.

jQuery is remarkably similar to prototype. They both take the idea of a function called "$". Saying "$('div')" will return an array of all DIV elements on your page in both libraries. But jQuery takes this to the next step and allows some fancy techniques to select items. Yes Prototype does as well, but jQuery is almost at the point of being able to use regular expressions within that string to identify objects.

At first glance, these libraries seem to be nothing more than a wrapper for some core javascript functionality, but with less typing. For example, the following 3 lines all do the exact same thing:

document.getElementById("mytarget"); //native Javascript
$("mytarget"); //prototype.js
$("#mytarget"); //jQuery

They all return a reference to an element with "mytarget" as it's ID. If this is all there was to jQuery and Prototype, I'd say they weren't worth the time and we'd be better to stick with native Javascript. But there is sooo much more here.

Anyone who has written an Ajax routine using native Javascript knows there's a bit of work needed. Get an instance of the XMLHttpRequest object (which in itself requires a factory method to be cross browser compliant), then a send request has to be built, and finally a method needs to be created to handle any response - when the request is finally completed. So let's say we wanted to replace the contents of a div with something fed to us from a php file. With native JS, the above routine still holds true. But here's how it's done with Prototype and jQuery:

new Ajax.Updater("mydiv", "myfile.php");


All that hard work boiled down to one line of code. Sure, there's more happening under the hood, and you really do need to understand how to do that yourself to take full advantage of things, but to use one line like that? What a HUGE time savings on that one point itself.

Other packages are starting to make an appearance as well. MooTools looks very promising in terms of what it can do for our interface. And I'm sure that others will make an appearance in the next year or two.

Bring on the BLING!

Built on top of these two packages are some amazing tools. Two quick examples are Scriptaculous (for Prototype), and Interface for jQuery. (Warning: Interface doesn't play nicely with Konqueror yet.) Take a look at the demo pages for these tools, and consider that all the effects you see are mostly one or two lines of code. This opens amazing potentials for much more dynamic interfaces. jQuery has even more plugins for it - ranging from easy rounded corners of your block elements, to popup windows (via divs, not real windows) and easy tab interfaces for your dynamic elements.

And there is moo.fx for MooTools. Again, there will be others here as well.

Which package should you use?

If you are using Ruby on Rails you already have Prototype and Scriptaculous as part of your arsenal. You can still use another package if you'd like, but the basics are in place for you.

If you are using other server side languages, jQuery would be a good place to start as it seems to have a bit more responsive support group (via mailing lists and IRC).

In practise though, you'll be selling yourself short if you don't learn all the packages. This takes time though, so focus on the ones you need.

If you don't need a package right now, but want to decide which is best for you, design yourself a quick application of some sort. Then set yourself some tasks to accomplish - maybe drag and drop? or animated effects? Now start with one of the packages, and see what it takes to accomplish those tasks. When you are done, start over with another package to do the same tasks. Decide which of these packages you like to work with, based on an informed opinion rather than "well, I learned XXX first".

What does it all mean??

These are but the next evolutionary step in how we interact with our data via web pages. These packages will make it easier to write complex applications, and will make it harder to determine if an app is web based or desktop based. These packages are bringing us closer to the elusive web based desktop. Web pages are no longer simple brochure type things (though they can be), or even a personal web site (though they still can be). Web pages are now entering a time when an average web designer/developer can create highly complex applications - even more complex than blogging tools. The type of applications that required a highly skilled developer to create just a short while ago. (We developers have no need to worry though - understanding server side code, and databases in depth will always be needed.)