The Practical Client

Introducing: Practical JavaScript

In the first installment of Practical JavaScript, Peter Vogel describes how a client-side skeptic evolved into a JavaScript fan thanks to several tools and a book. He also shares why he's concerned about TypeScript and where he's going to take this .NET-oriented JavaScript column over the next few months.

• By Peter Vogel
• 04/22/2013

Five years ago I wrote a column about JavaScript and AJAX in ASP.NET, where I asked if these tools were ready for prime time. And my conclusion was: No, they weren't.

I think I'm still getting angry comments on that post.

How the World Changed
Since then, whether I liked it or not, more of my coding involved JavaScript. (You can see that involvement in the articles I've written since then about JavaScript and client-side development in the original Practical ASP.NET column and its successor, the current Practical .NET column.) Over the last seven years, I've been using JavaScript and JavaScript tools more and more often to implement line-of-business (LOB) applications.

Some of the things that bothered me about JavaScript have changed since I wrote that first column. Tool support, especially in Visual Studio, got much better. More important, we've been flooded with great libraries, and jQuery especially revolutionized client-side development. I'd written code that manipulated the HTML Document Object Model (DOM) before jQuery, and I'm here to tell you that it was no fun (in fact, it was negative fun: it sucked fun out of other things around it). jQuery made many things better.

After jQuery, the most important JavaScript tools for me were the ones that implemented the Model-View-Controller (MVC)/Model-View-ViewModel (MVVM) in JavaScript. While server-side developers were building more sophisticated and more maintainable code on the server, client-side code was just one step up from spaghetti code. The MVC/MVVM libraries changed that. My favorite library in this area is Knockout, which does a great job of supporting a separation between the model and the view without forcing me to adopt a whole new way of writing code.

How I Changed
But other issues raised in that prime-time column remained: JavaScript isn't a data-typed language. That means there are an enormous number of errors that programmers typically make that the compiler can't catch. Consequently, the only way to find your problems is to run tests. The appearance of test-driven development (TTD) JavaScript libraries helped here -- I've been using QUnit, primarily because (I'm told) it's the TDD package of choice for the people behind jQuery. But, as far as I was concerned, tool support was only making an unpleasant job slightly easier.

Testing is inherently expensive, time-consuming and unreliable. When writing LOB code you need to maximize the functionality you can deliver in any period of time and for any set amount of money -- and you need to be reliable. In the LOB application development environment, the more that the compiler can catch, the better off you are. So I kept complaining about JavaScript.

That is, until I read "JavaScript: The Good Parts" (O'Reilly Media, 2008), by Douglas Crockford. Crockford's point is that people who don't like JavaScript (that would be me) were missing the point. I was trying to force JavaScript into my predefined object-oriented view of how languages were supposed to work. JavaScript isn't based on object-oriented programming; it's based on the idea of the prototype. Or, at least Crockford's belief is that the good parts of JavaScript are the prototype-based parts. He's convinced me that his belief is true. There are some costs around that (no data-typing, for instance), but there are also a whole lot of benefits.

This Column and the Immediate Future
And now Microsoft has come out with TypeScript, which is described by Mark Michaelis in his recent article, "A TypeScript Primer." I should be thrilled: TypeScript gives me the things I was whining about in JavaScript, with data-typing being the most important. It also includes a whole bunch of automated, compile-time checks along with a bunch of object-oriented support.

But instead, I worry: Am I going to lose all the special features of JavaScript that I've come to value over the last four years?

You just can't make some people happy, I guess.

It seems to me that there's only one way to find out how I feel about TypeScript: build something. So, I'm going to use TypeScript to build what I'd consider a client-side LOB application. I'll use something familiar: a single page that allows the user to select a customer and see all the sales orders for that customer. The user can then add, update or delete any of the sales orders. My expectations are that I'll be able to use TypeScript to create an MVVM structure within my page; that I'll be able to integrate with the libraries that I normally use (including Knockout and QUnit); and that I'll be able to communicate with the server using both older tools (Windows Communication Foundation [WCF]) and newer tools (the Web API).

This is early innings for getting started with TypeScript -- it's not yet at version 1.0, for instance. There are also some significant constraints if you want to use it in Visual Studio: it's currently only supported in Visual Studio 2012 and, even then, only for C# projects. If you want to use TypeScript outside those bounds, you can download a command-line compiler from Node.js. But TypeScript is an important enough technology to make it worthwhile to start examining it early in its life.

And, starting next month, that's what I'm going to do.