ASP.NET AJAX 1.0 Beta 2: Closures to Prototypes

Posted on November 12, 2006  |  

Posted in Development

No comments yet

I mentioned two posts by Bertrand Le Roy, From closures to prototypes part 1 and part 2, in my previous post. Although closures look hip and 1337 kids use them to declare JavaScript “classes”, the what’s-new whitepaper lists some very valid points for the switch. Instead of rehashing them, I’m going to simply rip them for your perusal.

Prototype Closure
The constructor is required. The constructor contains the member declarations.
The notion of “private” is handled by convention. Members are defined with a name that includes the “_” prefix. Members are truly encapsulated (private) to a class.
Members are effectively shared, which reduces the memory used by object instances. Members are instance-based, which increases the memory used by object instances.

Prototype provides a good load time in all browsers; in Firefox, prototype has significantly better load time. In all cases, script load time should be imperceptible to the end user.

The main performance benefits of prototype are significantly less memory usage per object, and significantly faster object instantiation.

In Internet Explorer, closure has slightly better load time.
Support for a tool’s IntelliSense and statement completion can obtain some type information based simply on reflection without having to create the types. Tool support for IntelliSense and statement completion would require executing code by instantiating classes to get the required type information.
While debugging, private members can be seen in the debugger. While debugging, private members cannot be easily seen by the debugger. Viewing member values in a tool (IDE) would require a number of steps.

For more details + an example, see the Prototypes and Closures section.