Blog For .NET

Like many .net shops, my team has chosen jQuery for its javascript framework. We chose it because most of the team is very new to javascript and jQuery is both accessible and powerful. We’re looking to add client side functionality (mostly UI effects) without concern for cross browser compatibilities.  Modal popups, custom validation, and UI effects are all popular uses of jQuery for us.

Javascript coding is big paradigm shift for Asp.net developers. The standard Asp.net tools (viewstate, update panels, postbacks) complicate even the simplest javascript. Simple operations like:

• dynamically instantiating javascript objects from the server
• binding behaviors to controls with runat=”server” (dynamically determined client ids)
• making asynchronous web service calls
• reference resource files before they’re needed – e.g. ensure that the $ function is defined before calling $(document).ready(…)

Like other javascript frameworks, jQuery provides some methods for finding and manipulating elements in the DOM. It also provides support for basic ajax calls, array manipulation, and event binding. In essence, it’s 10% helper methods (event binding, collection traversal) and 90% visual effects.

jQuery’s API abstracts away entirely the concept of “execution context“. This concept makes javascript fundamentally different from C# and therefore makes javascript less accessible to C# developers.  Without it, however, jQuery doesn’t provide support for object oriented programming because the developer cannot set the context in which a method will execute. This in turn leads developers to write spaghetti code by binding various DOM events to essentially static functions.

Suppose for example that we have the following requirements:

1. Show a page with a textbox and a button called “show modal”.
2. When the button is clicked, show a modal window with an “OK” and a “Cancel” button.
3. In the modal window, show the content of the textbox.
4. When the user clicks “Ok” call a web service and pass the value of the textbox.
5. When the user clicks “Cancel” hide the modal window.

The requirements don’t seem that difficult to implement at first – using the jQuery API we can bind to the click events of the “Show Modal”, “Ok”, and “Cancel” buttons using inline javascript e.g.

$(document).ready(function(){$('OkButton').bind('click',...)}

Note: each function will need to reference at least one DOM element. e.g. the “Ok” button needs to reference the modal window in order to hide it.

What happens, though when our requirements change? For example:

• The “Show Modal” button is used multiple times on the page.
• Based on state/permission the “Show Modal” functionality should be disabled.
• The button controls have “runat=server” on them and therefore have a dynamically determined client id.
• The page needs to lookup information (possibly via web service) based on the value in the textbox and include that information in the modal window.

As the client side logic becomes more complicated the need to encapsulate the logic into an object(s) grows – a central place for the logic of binding/unbinding events and handling. In javascript methods acquire state through closures – a combination a function a context (state)  - jQuery just isn’t made to do this.

jQuery doesn’t help novice javascript developers learn javascript. It empowers us to create web 2.0 applications with no knowledge beyond web 1.0.

Consider the common pattern event binding pattern in jQuery :

$("a").click(function () {
    alert("Hello World");
});

What happens when the jQuery library hasn’t been downloaded yet? There’s now a race condition between this code being rendered and the jQuery library being referenced.

Here’s another pattern commonly used in jQuery for object initialization:

(function($) { $.plugin = function(data) {... some initialization...})(jQuery);

As soon as the file containing this text is referenced in the page, the plugin is defined and initialized. As a pattern, we’ve now tightly coupled library definition and object instantiation. This works well when initializing singleton objects, but doesn’t work when instantiating multiple objects of the same type, perhaps using the object’s prototype definition.

jQuery’s focus on a static API and lack of support for classes or execution context changes make it somewhat limited for broader application development. The MS Ajax Extensions and prototype frameworks already provide these capabilities. They also provide the backbone for the Ajax Control Toolkit and script.aculo.us respectively. While jQuery is more accessible than these other frameworks, it comes at the cost of learning and leveraging javascript.

1 Comment »