Practical ASP.NET

JavaScript for the ASP.NET Developer

Peter has been experiencing culture shock as he adapts to working with JavaScript, starting with the discovery that JavaScript isn't an object-oriented language.

• By Peter Vogel
• 04/29/2009

However, as I do more AJAX-style programming, I find myself developing a grudging respect for the language.

Part of the reason that I lacked respect for JavaScript was a fundamental misunderstanding on my part. Since I started programming, I've worked in either procedural or procedural+object-oriented languages. I've dabbled in various other language types (mostly rule-based languages like Prolog and XSLT or declarative languages like SQL) but I've always been true to my object-oriented langauges.

What has re-aligned my worldview is a book on JavaScript by Douglas Crockford called JavaScript: The Good Parts. Crockford's credentials for writing a book on JavaScript are excellent; among other qualifications, he's responsible for the JSON format which is the de facto standard for moving structured data between the client and server in AJAX-enabled applications.

As the negative reviews on Amazon.com point out, the book is short and definitely not focused on teaching you JavaScript (for that, I like David Flanagan's JavaScript: The Definitive Guide, also from O'Reilly Media). Instead, the book is aimed at bringing out the essential concepts of the language -- which I had been ignoring.

So this revelation of material well-understood by all "real" JavaScript programmers is the basis for this column: to describe, in terms that make sense to ASP.NET programmers, the fundamental concepts of JavaScript and how they are different from the object-oriented languages that we're used to.

Objects vs. Prototypes
Unlike the languages I use when writing server-side code, JavaScript is not an object-oriented language. Instead, it's organized around prototypes. In JavaScript you can define data structures and then either use them or copy them. The ability to copy a structure to create a new one means that any structure can be a prototype for subsequent structures. However, unlike a class in object-oriented programming where the definition is inviolable, prototypes or their copies can be extended or modified at any time.

This code, for instance, defines a data structure consisting of two variables: one called id (initialized with a zero length string) and one called dateOrdered (initialized with a Date object). This data structure can be referenced through the variable salesOrder:

var salesOrder = {
    id: "",
    dateOrdered: new Date()
 };

I can start using this structure immediately. This code, for instance, sets the id property to a string value. (And good news! The id property will appear in the IntelliSense drop-down list for salesOrder):

salesOrder.id = "A1230";

However, I can also create copies of this structure by treating it as a prototype. To copy the structure, I create a dummy function, set the function's prototype property to my original structure, then use JavaScript's new keyword to create a new version of the structure from the structure. This code creates a new copy of my structure and references it through a variable called backOrder:

var SalesOrderGenerator = function(){};
SalesOrderGenerator.prototype = salesOrder;
var backOrder = new SalesOrderGenerator;

I can now use this new copy of the data structure:

backOrder.id = "B4567";

If this process isn't different enough, JavaScript allows you to dynamically add a new element to your new copy simply by setting the element to a value. This example adds an outOfStock element to the backOrder version of the structure:

backOrder.outOfStock = true;

All of this is, of course, obvious to experienced JavaScript programmers. But for members of the ASP.NET community who are moving from creating server-side code to creating client-side code (i.e., me), there's a certain amount of culture shock involved.

It's not helpful that a familiar keyword like "new" appears in JavaScript. One of the best rules to follow in user interface design is: "Things that do the same thing should look the same; things that do different things should look different." Running across "new" as a keyword in a different environment initially looks helpful but, in fact, it just encourages me to think of JavaScript as an object-oriented language when it's not.

Still, I'm adjusting. Now, if I could only define a variable as a simple datatype...