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
Follow @infoworldTaking 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.
