Visual Studio Magazine

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

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

Reader Comments: