JavaScript Love Hate

I have to admit: in all those years of web development, I was quite reluctant to write any JavaScript code.

In the early days of ASP.Net, JS was either not required or not (easily) possible to implement the functionality we know today. This changed with the arrival of the Ajax Control Toolkit that simply injected pre-built pieces of JavaScript code into a page using server-side controls, or by manually typing a couple lines of code.

The main reason for me, though, was that you cannot compile JavaScript.

You have no idea whether your piece of code actually works – you need to run it to see whether it’s ok. Combine this with the typical behavior of IE on a dev machine, popping up a message box whenever a JS error occurs, or different parsers with different sensitivities to well- and mal-formedness of code in different browsers (missing a semicolon, adding a comma too much), and it’s easy to see that for people used to compiling code there was a lot to dislike.

Also, until quite recently, there were simply too many JavaScript libraries available to make a sensible choice between jQuery, prototype, ext-js, and several others. Fortunately (or unfortunately, depending on your preferences), this has changed, as illustrated in this chart.

But the times, they are a-changing. Today’s web applications are inconceivable without proper client-side functionality and asynchronous server communication, all implemented in Javascript. As Scott Hanselman cited more than a year ago, “JavaScript is Assembly Language for the Web“.

Why do I write all this? Well, I finally brought myself to write my first JavaScript application. The ASP.Net MVC project is essentially just the container for JS code, and also implements the Ajax backend using Controllers that return JsonResults.

While programming in JavaScript “for real”, I got quite fascinated about the things that are possible in JavaScript, and the project soon reached 2000 lines of code. However, as it goes with first projects, the code soon became unmanageable and needed a cleanup. The code implemented various dialogs with partially dynamic fields and validation, a hierarchical database browser and a web directory browser, but it was a mess.

The first restructuring was to avoid global variables as much as possible, encapsulate the Ajax calls in a static object, and each dialog in one function, with the event handlers implemented as local function variables.

But all this code with its anonymous parameters and asynchronous callbacks passing untyped (in JavaScript, but typed in C#) parameters to the success() functions is still difficult to understand (“write-only”).

The latest innovation that gave me a prospect of typed, compilable, and modular programming is called TypeScript, an extension to the JavaScript language that compiles to JavaScript (CodePlex). It installs as new project type and item type in Visual Studio, and its support for typical IDE functionality such as Intellisense, Go to Definition, Find References, etc. is quite good, judging from first glance.

Finally, a couple of links to introductory news articles that drew my interest for TypeScript:

• Here comes TypeScript: Microsoft’s superset of JavaScript
• Why does TypeScript have to be the answer to anything?
• Microsoft: TypeScript isn’t a JavaScript killer

Give it a try!