Programming Microsoft ASP.NET 4 - Dino Esposito [470]
As mentioned, although JavaScript is definitely a stable language that hasn’t faced significant changes for a decade now, virtually any broadly used library is packed with forks in code to distinguish the behavior of different browsers and ensure the same overall interface.
One of the first rules—if not the first rule—you should follow to write rich client applications is get yourself a powerful JavaScript library that adds abstraction and features to the JavaScript language and that works in a cross-browser manner.
Flaws and Workarounds
JavaScript has a number of drawbacks, both technical and infrastructural. In spite of all these factors, though, JavaScript works just great for the majority of Web applications. And nothing any better has been invented yet.
All things considered, the limitations of JavaScript can be summarized as two elements: it is an interpreted language, and it is not fully object oriented. The former drawback makes the language significantly slower than a compiled language. The latter makes it harder for developers to write complex code.
The Google Chrome browser (which you can read more about at http://www.google.com/chrome) is the first browser with an open-source JavaScript engine that compiles source code to native machine code before executing it. As a result, Chrome runs JavaScript applications at the speed of a compiled binary, which is significantly better than any bytecode or interpreted code.
An analogous capability is featured by Internet Explorer 9, which compiles the JavaScript code in the background, leveraging the full capabilities of the underlying hardware. Generally, all browsers (including Mozilla-based browsers and Opera) are evolving their JavaScript engines to achieve performance as close as possible to that of native code.
Because JavaScript is so popular and widely used, planning a significant overhaul of the language is just out of question. For years now, libraries built on top of the core language have been providing facilities to work with remote endpoints, parse data into JSON, and produce UI widgets.
As you saw in Chapter 20, JavaScript can be used to write code that follows two radically different programming paradigms: functional programming and object-oriented programming (OOP). JavaScript is neither 100 percent functional nor object-oriented, but it borrows concepts from both qualified functional and object-oriented languages. This inevitably creates some noise regarding the programming techniques you can employ. As a developer, you must be ready to accept compromises that might not be acceptable in a fully qualified functional or object-oriented scenario. To use JavaScript at its best, you probably have to mix functional features with object-oriented (OO) features.
What You Write JavaScript Code For
The client-side code you are called to write is no longer, and not just, plain scripting of the document object model as it was when the language was introduced. Today, you often use JavaScript for some client-side logic and input validation. In particular, you use JavaScript to download data from the server, implement Windows-like effects such as drag-and-drop, resizing, templates, popup and graphic effects, local data caching, and the management of history and events around the page. You want the JavaScript code to be maintainable and unobtrusive.
Any in-browser JavaScript inevitably deals with the DOM. The DOM, therefore, is the primary object model you need to work with. Any other object model you might want to introduce risks being cumbersome and partially unnecessary.
If you have to write your own framework to support some server-side