Ajaxian

If it were April Fool’s Day, the Net’s only official holiday, and you wanted to design a ‘Novelty Protocol’ to slip by the Internet Engineering Task Force as a joke, it might look something like the Web:

HTTP and HTML are the Whoopee Cushion and Joy Buzzer of Internet protocols, only comprehensible as elaborate practical jokes. For anyone who has tried to accomplish anything serious on the Web, it’s pretty obvious that of the various implementations of a worldwide hypertext protocol, we have the worst one possible.

Except, of course, for all the others.

These various [non-web] protocols and services [Gopher, Interactive TV, AOL, etc.] shared two important characteristics: Each was pursuing a design that was internally cohesive, and each operated in a kind of hermetically sealed environment where it interacted not at all with its neighbors. These characteristics are really flip sides of the same coin — the strong internal cohesion of their design contributed directly to their lack of interoperability. CompuServe and AOL, two of the top online services, couldn’t even share resources with one another, much less somehow interoperate with interactive TV or CD-ROMs…In other words, every contender for becoming an “industry standard” for handling information was too strong and too well-designed to succeed outside its own narrow confines. So how did the Web manage to damage and, in some cases, destroy those contenders for the title of The Next Big Thing? Weakness, coupled with an ability to improve exponentially.

Evolvable systems — those that proceed not under the sole direction of one centralized design authority but by being adapted and extended in a thousand small ways in a thousand places at once — have three main characteristics that are germane to their eventual victories over strong, centrally designed protocols.

Because JavaScript is the language of the web browser, and because the web browser has become the dominant application delivery system, and because JavaScript isn't too bad, JavaScript has become the World's Most Popular Programming Language. Its popularity is growing. It is now being embedded in other applications and contexts. JavaScript has become important.

The art in language design is knowing what to leave out. The features of a good language work together harmoniously. A good language helps us to better understand a problem and to find the best expression of its solution.

A good language is composed of a limited set of features. But there is little agreement on which features are best. Programmers can argue endlessly about features and whether a set of features makes one language better than another. Features matter, but we just don't understand yet how they matter.

Language design has more to do with fashion than technology. It may seem strange that fashion is a major factor in the nerdliest of arts, but it is true. A language with radically different syntax, for example, has no hope of finding broad adoption, regardless of the brilliance of its design. This tends to constrain the rate at which languages evolve.

Just like fashion, a programming language is often a product of its time. The deep problem in language design is not technological, it is psychological. A programming language should equip us with structures that help us to reason more effectively.

The bling, one of the best global variables in JavaScript. A tool which has come to mean, as a function, a way to locate a node or set of nodes. And, as a namespace, a simple way to access often-used functionality. "This can't be done with Dojo," you insist. But you're wrong, it's really easy. The ideas behind this little symbol are quite simple and I'm going to show you how to create your own customized version of it.

Feature testing is not easy and there is no one right answer. From a practical stand point, the more strict your tests are the more likely your code runs only when it will run successfully.

There are some obvious wrong answers like navigator.UserAgent inference, unrelated execution inference and unrelated object inference. Check the library you are using. Does it use any of these techniques? I have seen many uses of these techniques in mainstream libraries even where there is a well known, better test available. The mainstream libraries cannot consider claiming to be state of the art until they remove these bad practices at the very least.

The above discussion focuses on tests against a single object to infer if that object or similar ones work. Sometimes it may be necessary to use multiple objects together to make an inference about one object. An example for scroll reporting. Even when using multiple host objects in a test the three isHost* functions will be useful.

Feature detection is not easy, but as professionals, we should use the best tests we can.

Build a robust widget for the general web is hard work and the example above has room for improvement. The level of feature testing could be increased at the cost of file size. For example, on comp.lang.javascript, David Mark suggested that the browser could run out of resources and a call to createElement could return null. He also admitted this may be overly paranoid. I think it is and by testing for the existance of document.createElement I've inferred that calls to it will work as expected.

I've tried the tabbed pane in all the browsers I have and it is either enabled an works or it is disabled and doesn't throw errors. I suspect there is a browser out there somewhere that will throw an error. That is just the nature of the cross-browser challenge. In a perverse masochistic way, I somewhat hope someone can find a browser in which this widget breaks. That is one way we can continue to improve.

Version targeting is not a bad idea. The choice of delivery mechanismsâ€â€meta element or server headerâ€â€is inspired. As an optional feature, this could prove to be a real lifesaver in some development environments. As a mandatory millstone however, it strikes a blow against progressive enhancement.

The proposed default behavior for version targeting in Internet Explorer solves the problem of “breaking the web†in much the same way that decapitation solves the problem of headaches. In its current state, version targeting is a cure that will kill the patient. Version targeting could have been an opportunity for Microsoft to demonstrate innovation. Instead, the proposed default behavior demonstrates a fundamental misunderstanding of the World Wide Web, a place that according to its creator, Sir Tim Berners-Lee, will always be “a little bit broken.â€Â

Version targeting is a mind-bender. It shakes our browser-agnostic faith. Its default behavior, although beneficial to skilled and unskilled developers alike, runs counter to our expectations, and seems wrong. And it presents at least one Sphinxian riddle: namely, how can IE8 pass Acid 2 if IE8 behaves as IE7 by default? You can spend weeks on that one and not come up with a logical answer. Call me Lewis Carroll, but I’m okay with it.

And actually, Mozilla has offered opt-in version targeting, first when Firefox 1.5 introduced support for JavaScript 1.6, and later, when Firefox 2.0 did the same for JavaScript 1.7. In both cases, you had to explicitly opt in. The comparison is Mozilla’s favor, for they targeted scripting language versions, not browser versions. But although Mozilla did it more cleanly, both browser makers offered targeting, and for the same reason: to protect developers from unintended behavior as their browsers’ scripting support improved.

Non-standardistas have been writing JScript for years. While the CSS changes in IE7 may have “broken†a site’s layout, IE8’s JavaScript improvements could easily render a site useless. Real DOM support is a game changer. Enabled by default, it would bring many sites to their knees. That would break the web, and not in quotes. Providing IE8’s greater compliance on an opt-in basis is the only way to get everyone over the scripting hump.

But while the opt-in protects old-fashioned coders from a major change in the scripting environment, it also offers unique benefits to even the most die-hard standardista.

The other side of the coin is the mentality of viewing a Web application as a program, as opposed to a page. In this scenario, the application is utterly dependent on the active functionality made possible by JavaScript, which means it's okay to forego users who lack JavaScript support. Google has embraced this philosophy in several marquee products, two of which are extremely popular: Gmail and Google Maps. Both applications make extensive use of Ajax (JavaScript), and neither apologizes to users who can't run them due to a lack of JavaScript. If this article had been written just a few short years ago, I might have used an e-mail application as the ridiculous example of when not to use JavaScript, instead of Halo. But Gmail has pushed through that barrier.

Even if JavaScript-powered, web-based e-mail ultimately takes hold, surely there are other stand-alone applications that will just never make sense in Web form. Two such applications that come to mind are video and photo editing. Similar to games, these are such media-intensive applications that they just can't make sense in JavaScript, right? Yet Adobe has already released Premiere Express for online video editing and is putting the finishing touches on Photoshop Express for Web-based photo editing. What's interesting about these applications is that they aren't technically built in JavaScript; they're built in ActionScript, a close cousin of JavaScript used in Adobe's Flex development environment. But the ActionScript in these applications is compiled, so the net effect is more akin to a native application. Adobe may be foreshadowing the future of Web scripting to some degree, at least in terms of building more feature-rich applications. And in doing so, they're forcing us to rethink just what is possible with scripting languages.

Obviously, we would like to see browser vendors take a serious look into the following issues and put them on their roadmap:

Read the study to get the details on each item. It includes the results such as the DOM operation performance information:

In this chapter, we took the languages of CSS and JavaScript well beyond the tasks for which they were intended?the presentation and basic behavior of HTML documents -- and used them to create an interactive 3D maze.

First, we looked at the basic principles by which triangles can be displayed using only CSS. We then extended that concept to render a perspective view, creating the illusion of three dimensions. Next, we established a convention for specifying floor plan data, and for dynamically translating that data into a perspective view. By adding listeners for user events, we successfully created an interactive maze that can be completely customized and extended. To top things off, we added some usability aids, such as a top-down map, and accessibility aids including keyboard navigation and captions.

While I haven't delved into the details of every method that comprises the game script (there are plenty of comments, so I'll leave that for you to pursue in your own time), I hope this chapter has convinced you to look at JavaScript in a new light. The possibilities really are only limited by your imagination!

JavaScript input assistance, when built separately from back-end validation, is not ideal. At worst, the two piece of functionality work differently, and what's valid on the client side isn't valid at the server. At best they work fine -- initially. But with validation logic in multiple locations, there's an increasing likelihood that only one will get updated when changes are required, at which point we get inconsistent results.

Finally, back-end validation is required. JavaScript assistance is nice.

The use of a central object to manage both the validation and input assistance tasks creates a consistent end user experience even with JavaScript disabled.

Don't forget: the code for the PHP-Validate and a sample form is available for download.

It's interesting that the current simple version of JavaScript already has the features (i.e. closures) that people want to keep out of Java otherwise it will become too complex, and that Java already has some of the features (i.e. classical inheritance) that people want to keep out of JavaScript, otherwise it will become to complex.

With JavaScript, people see a neat, compact language and fear it turning into Java. The good news is that it won't fully turn into Java because JavaScript already has closures and no one thinks they should be taken out ;-) The danger of the "features over complexity" argument, is that it can be applied indiscriminately, creating a monster, and the fear is that JavaScript will become a monster.

I'm gradually coming round to the opinion that many of the changes proposed to JavaScript actually reduce complexity. There are nearly as many frameworks that add classical inheritance to JavaScript as there are Ajax frameworks. Having one solution that we can all agree on can't be a bad thing even if you prefer prototypal inheritance.