JavaScript for the ASP.NET Developer
Peter Vogel

April 29, 2009

I've always had a jaundiced view of JavaScript (see my column " JavaScript and AJAX in ASP.NET: Not Quite Ready for Prime Time " and the subsequent reader comments).

It's always seemed to me that whatever benefits may result from late binding, the inability in JavaScript to specify a datatype for a variable kept the language from being a "real" programming language -- at least for business purposes.

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...

About the Author