Taking AJAX literally makes lousy Web apps

As little as possible should be the rule for JavaScript, which must play a supporting role to CSS and HTML

Taking AJAX literally, using JavaScript and XML to create a Web site or application, is not a best practice. Far from it. Developers coming to the Web from C-like languages stumble into the AJAX trap, and the result is bloated JavaScript payloads, page load delays for every page refresh, browser and client platform incompatibility, and user frustration. If putting too fine a point on it is what's required to put my point across, so be it: Web site developers should consider JavaScript to be their last resort, and where it is used, it cannot be used the way it typically is today.

The fact that you can write a Web page in a text editor makes some people believe that it's easy. Free JavaScript libraries and templates for wicked cool stuff like DHTML menus, browser type forking, forums, and AJAX animation make Web site and Web app authors think that no matter how big it is, if a page loads from their desk, all's well. In the majority case, no debugging, code coverage, testing, profiling, and other validation steps are applied to JavaScript. In all other languages, these things are not holstered until a page won't load. They're essentials that you use throughout a project.

[ JavaScript, Perl, PHP, Python, Ruby, and other dynamic languages are remaking the Web and bringing programming to the masses. Where should developers place their bets? See Dynamic programming futures. ]

I realize that such tools are hard to come by. A commercial tool, like those from Adobe and Microsoft, affords JavaScript developers facilities for traditional debugging, but at the cost of injecting unpredictably large amounts of client-side code into the project that only the specific tool can understand. Altering the page by hand can make the tool useless for further work on the page. And a commercial tool can't always follow you from one project, host, or employer to another.

Free JavaScript development environments do exist. One of them is even commercially validated, and unexpectedly, it's a browser. Apple's Safari and the open source WebKit browser are operationally identical not only as Mac and Windows browsers, but both have freshly acquired and uncommonly good JavaScript debugging and code profiling facilities (see my Safari 4 preview). These browsers also share a stellar accelerated JavaScript interpreter that makes the edit/run/debug cycle go faster. They are also the only browsers that deliver on CSS4 and HTML5 standards (with some elements that are proposed to the W3C standards body). Sites that are visually rich may start sprouting "best viewed with Safari" banners until other browsers catch up. The banner would also let users know that your site is optimized for iPhone.

You’re still waiting for me to explain what I meant when I referred to JavaScript as a last resort. I hinted at it in the preceding paragraph. Not the part on JavaScript debugging, but my reference to CSS and HTML. These do a lot more than paint screens. They are a browser's client-side framework. Everything they do is handled as native code. In other words, they're fast. CSS3 and HTML5 are too inconsistently implemented (if at all) across browsers to design to unless you're specifically targeting Safari, iPhone, or other WebKit-based browsers. For the time being, it's best to learn HTML4 and CSS2. And learn them you must. Being a JavaScript god is nowhere near as useful for Web sites and apps as knowing HTML4 and CSS2 inside out. If you want to be a Web app god -- a far more prized and employable deity -- follow this simple program.

First, put your JavaScript reference away. What you already know of it is sufficient for now. Learn HTML4. Second, after you’ve put locked up your JavaScript manual, set aside your HTML4 manual as well. Consume, live, and memorize CSS2. Anything that can be accomplished similarly in JavaScript, HTML, or CSS must be done in CSS. HTML is derived from a static layout language. CSS is all about dynamic and adaptive. As you learn it, you’ll marvel at the amount of JavaScript and HTML it replaces.

If you intend to alter your content dynamically, which, if you get it right, allows you to reduce expensive and visually jarring page reloads and refreshes, you'll find that giving CSS first preference makes dynamic changes infinitely easier to make. If you make preferential use of CSS, it will allow you to prune away a lot of JavaScript browser sensing and code forking. Once you master it, CSS will let you create just one page that adapts itself to screen resolution and responds correctly to users' font size adjustments and browsers' zoom feature.

I love the uniquely expressive and flexible JavaScript. I adore its accelerated form in Safari 4 beta and WebKit. XML is the right way, a human readable and readily alterable way, to represent small quantities of data. As a coder, AJAX makes me a happy camper because it describes the way I've always used these technologies. But no Web site or app should use JavaScript as the means to all ends. If you must have an acronym that describes Web site and app authoring best practice, AJAX should be ACHJAX.

Copyright © 2009 IDG Communications, Inc.

How to choose a low-code development platform