Programming Microsoft ASP.NET 4 - Dino Esposito [441]
In the prototype model, members are shared by all instances as they are invoked on the shared prototype object. In this way, the amount of memory used by each instance is reduced, which also provides for faster object instantiation. Aside from syntax peculiarities, the prototype model makes defining classes much more similar to the classic OOP model than the closure model.
The choice between closure and prototype should also be guided by performance considerations and browser capabilities. Prototypes have a good load time in all browsers; indeed, they have excellent performance in Firefox. (In contrast, closures have a better load time than prototypes in Internet Explorer.) Prototypes provide better support for IntelliSense, and they allow for tool-based statement completion when used in tools that support this feature, such as Microsoft Visual Studio. Prototypes can also help you obtain type information by simply using reflection. You won’t have to create an instance of the type to query for type information, which is unavoidable if closures are used. Finally, prototypes allow you to easily view private class members when debugging. Debugging objects derived using the closure model requires a number of additional steps.
Note
Whether you opt for closure or prototype, writing complex JavaScript code requires a lot of discipline. An interesting pattern to explore is the Module Pattern, which essentially introduces the concepts of namespaces and dependencies in JavaScript code where no such elements exist natively. A good introduction to the pattern can be found here: http://www.adequatelygood.com/2010/3/JavaScript-Module-Pattern-In-Depth.
Cross-Domain Ajax
For security reasons, all XMLHttpRequest calls within all browsers are restricted to the Same Origin Policy (SOP). In other words, all browsers proceed with an XMLHttpRequest call only if the destination URL is within the same origin as the calling page. Because XMLHttpRequest uploads cookies, a user authenticated on a site (say, contoso.com) might end up on another site (say, thebadguy.com) and leave there her authentication cookie. At this point, from the thebadguy.com site an attacker could make an XMLHttpRequest request to contoso.com and behave as if it were the original user. In a nutshell, script-led cross-domain calls are forbidden.
The problem is that sometimes cross-domain calls are useful and entirely legitimate. How to work around the limitation? Generally speaking, there are four possible approaches:
Using a server-side proxy
Using Silverlight or Flash applets and their native workarounds to bypass SOP
Leveraging cross-domain-enabled HTML tags such as