Section 11.7. What s New in JavaScript
11.7. What's New in JavaScriptThough the ECMA working group hasn't issued a new specification release, work on JavaScript continues. JavaScript 1.6 introduced new array methods such as indexOf and lastIndexOf, as well as iterators (methods to help one move through, or iterate through, a collection such as an array): every, filter, forEach, map, and some. JavaScript 1.7, which is part of the Firefox 2.0 release, continues working with arrays, and includes additional iterators and generators for initializing them. It also expands scoping rules to include block-level scoping. Right now, there is function-level (local) and global scoping, and that's it. At issue with these changes, though, is that they are browser-specific. At a minimum, they have no ECMA backing and again, push us off into a potential cross-browser dichotomyjust at a time when we're beginning to expect consistent behavior among the major browsers. Most of JavaScript 1.6 is covered by ECMA-262 revision 3, but there's no parallel ECMA specification for JavaScript 1.7. More, there's no guarantee that Microsoft will concur with the steps that the Mozilla organization is taking with the language enhancements. However, unlike the issues with different interpretations of the DOM, which was the primary cause of cross-browser difficulties in past JS lives, we're now faced with a growing separation in the basic programming language itself. I include a discussion of the future of JavaScript in this particular chapter because many of the proposed changes for JavaScript 2.0 (also known as ECMAScript Edition 4, or ECMA4) have to do with converting JavaScript to a true class-based language. This includes the ability to provide packaging and versioning, as well as true public and private keywords, and static typing through the use of const and final. A second interest with JavaScript 2.0 is to improve its ability to communicate with other programming languages for multilanguage application development. This means types for object interfaces, as well as machine-level data types such as int. The creator of the original JavaScript, Brendan Eich, formerly of Netscape and now a part of the Mozilla corporation, gave a presentation at XTech in May 2006 about JavaScript 2.0 and the future of the Web. The presentation is at http://developer.mozilla.org/presentations/xtech2006/javascript/. Unfortunately, there's no audio of the presentation, nor any document fleshing out the bullets. But going through the slides, you can draw several inferences about the whys and wherefores of this rather significant move in JavaScripting. 11.7.1. Change Just EnoughThe original JavaScript 2.0 proposal was intimidating due to the extent the language would have to change. According to Scott McCoy's article on JS 2.0 (at http://www.blisted.org/wiki/papers/opinions/JavaScript2.0), we don't need to change the language much. McCoy provided a sound argument as to why classes aren't needed, and the current prototype-based system was very effective. What's needed instead is a better extension mechanism. However, Eich's presentation lists some of the arguments for just minimal JavaScript changes and details why he feels these won't work in the long run. One of these reasons involves closures for data hiding, which I wrote about in an earlier chapter. As I noted then, closures can add to the memory burden, increasing it almost three times according to Eich. Another argument for minimal changes to JavaScript is that we're finally at a point where browsers interoperate. Now is not the time to rock the boat. To this, Eich responds that browsers don't interoperate at the frontiers, which we must assume means at-the-edge cases (most likely Ajax-based). He also stresses that using namespaces for extensions requires cooperation. As for the current system of type checking, Eich argues that specific type checking is tedious, and frameworks must be shared and distributed. Ultimately, Eich states that minimal changes don't scale. 11.7.2. Scaling and the Next 10 YearsThere is a fork in the road for JavaScript usage. One path leads to the typical JS use we've seen for the last several years: form validation, setting and getting cookies, providing an interactive web page for the user, etc. We've added many more bells and whistles, but the underlying concept is that we're working with web pages. Another path is one that sees the browser and the Internet as the new desktop of the future. Rather than view the document in which we work just as a web page, it's a whole new environment that requires a great deal more interactivity (storage, interfacing with a server, and so on) than we've had in the past. When Eich talks about scaling, I'm assuming he means the latter and not the former. At Eich's roadmap weblog (http://weblogs.mozillazine.org/roadmap/), he begins to discuss some of the proposed changes, though most of the discussion is based on programming-language semantics, rather than what JS will look like for you and me in the end. In one comment, Eich talks about the scaling issue:
We'll look at some of these libraries in the last two chapters, but the larger ones are focused on emulating desktop applications within browsers. Does the tail (in this case, Ajax and the desktop style of applications) then wag the dog (the entire community of web developers)? Eich seems confident that this is so, and believes JavaScript 2.0 will roll out in general-browser use by 2010. When pondering the fact that Microsoft is just now coming out with IE 7, and it doesn't implement all of the DOM Level 2 functionality, which has been a released spec for years, I'm not so sanguine that we'll all be developing in JS 2.0 in four years. However, stranger things have been known to happen.
|
EAN: 2147483647
Pages: 151