Every enterprise IT constituency craves the attractive user experience and low life-cycle costs that can flow from the use of scripting languages—notably JavaScript, Perl, Python and PHP—and script-based application models such as AJAX. Those benefits are multiplied by growing connectivity, and the synergy of client-side scripts manipulating server-side data, to make scripting a candidate for a lengthening list of tasks.

It's necessary, though, for practitioners to recognize and confront scripting's challenges. The use of scripting on the Web—JavaScript, specifically—"suffers from outdated, uninformed, and inaccessible development methods which preclude it, and therefore Web development in general, from attaining its full potential," asserted "The JavaScript Manifesto" released last month by The Web Standards Project.

Scripting's worst faults for enterprise development flow directly from its strengths as an end-user tool. Scripting lets a user tailor generic applications to handle routine tasks quickly, conveniently, consistently and intelligently, with minimal time between recognizing and meeting a need—and with relatively little concern for general-case rigor or long-run maintainability.

Scripting languages are intuitive, with loosely typed variables and other flexible data structures that relieve users of the nuisance of variable declarations and the like. Scripting provides the immediate gratification of interpreted languages, able to execute statements as soon as they're written—or even generate and execute statements from within a running script, without compilation or linking.

That direct interpretation also makes for relatively straightforward debugging, with tools such as the JavaScript debugger, code-named Venkman, whose 0.9 release is part of the current Mozilla distribution .

"You can be fairly sure that a script is doing what you wanted," IBM Rational Software Product Manager Ed Gondek told eWEEK Labs.

These traits make scripting productive on the upside, albeit error-prone and resource-intensive on the downside. However, a script that's written by its own user to meet a short-lived need can tolerate those drawbacks. The risk level rises when developers, who are also users, let the appeal of scripting draw it into roles beyond what it was designed to handle.

Developers benefit from the support of scriptable platforms that let them prototype applications quickly, in a way that scripting proponents often compare to sketching with a pencil instead of drawing with a pen. Developers also enjoy the freedom that scripting tools provide to refine applications immediately in response to user feedback. Moreover, developers can radically reduce a project's cost by making maximum use of a platform's bundled tools or built-in facilities—in many cases a core competence of scripting tools.

These strengths of scripting languages are especially relevant to teams that want to bring the domain knowledge of business systems analysts closer to the implementation of business processes as Web services. When business analysts write code in a scripting language, said IBM's Gondek, "they're working at an abstract level, with a much-higher-level verb set, and they don't have to worry about the plumbing. Abstraction lets them spend more time in the cognitive part of the problem—they just get more done."

Development managers will also find that their training costs are reduced by the high leverage and approachability of scripting tools. "To learn these languages—Perl or Python or EGL [Enterprise Generation Language]—is relatively inexpensive; management doesn't have $50,000 to invest in retraining a 4GL [fourth-generation language] programmer in Java," said Gondek, who's based in Research Triangle Park, N.C.

To read why Peter Coffee thinks developer tools are never good enough, click here.

Scripting languages are traditionally used for integrating tools with well-structured text output that can readily be captured in a file or pipelined—with any needed transformations—from one application into the input of another. "Scripting is really good for systems administration and text processing," said Gondek. "There's a lot of lower-level types of manipulation—log files, data conversions—that you can do with scripting languages." Indeed, scripting tools such as REXX have been used in such roles at eWEEK Labs for a decade and a half.

More complex and risky is the use of scripting methods for adding interactivity to content and function presented through a Web browser—but this is the hottest growth area for scripting, often under the banner of AJAX (Asynchronous JavaScript and XML) but also in other forms. The eWEEK Excellence Awards entry and judging Web sites have long used scripting for such tasks.

The problem is that unlike relatively stable platforms such as Windows, Unix and Mac OS, "every new version of Internet Explorer presents new challenges and limitations; every new version of Mozilla and Firefox has changes," said Alexei White, product manager at eBusiness Applications Ltd., based in Vancouver, British Columbia. "With scripting, you can do simple things very easily; to do more complicated things takes more time to understand the browser internals more fully."

Even so, there are compelling reasons for enterprises to consider a script-enhanced, browser-based application model as the path of least resistance for a new project's design.

The sluggish performance of older Web applications, with their constant page updates, is dramatically improved in AJAX applications. Anyone who doubts this, the Labs would suggest, can simply compare an AJAX-based interactive site such as Google Maps against mapping sites such as MapQuest that use older page-refresh models.

Performance gains are not merely an end-user amenity. "AJAX is all about cost containment," White said. "Licensing is cheaper, deployment is cheaper, and, fundamentally, AJAX-based solutions work faster. You put a user on a task, and an AJAX-enabled scripted solution can save half of a user's time, in terms of page reloads and such. That adds up to a lot of cost savings."

Developers used to find that writing a Microsoft Corp. Visual Basic application, which can reach the 90 percent of the user base that runs Windows, made more sense than doubling development effort to produce applications for multiple platforms but only broadening one's user base by a few percentage points.

Today, the Labs finds that the incentives have tipped in the other direction: An AJAX application is accessible to essentially 100 percent of users with essentially zero cost of deployment or update distribution, and it offers a richness of user experience comparable to what most users expect from a traditional thick client.

Scripting as an application model brings along crucial caveats. Scripting languages are almost defined by their ease of using global variables and other progenitors of unmaintainable code.

"It's harder to build modular solutions" with scripting tools, warned eBusiness Applications' White, whose company's packaged components are aimed at improving that situation.

Development managers should therefore apply the power and flexibility of scripting where it has the greatest leverage—where it can provide an effective bridge between task domain knowledge and platform facilities, and where it can add interactivity to Web applications with minimum client-side footprint and bandwidth use.

The power of scripting can lead to its being used to do more things than it should. Yes, scripting is easy to learn—but when a script grows without a high-level plan into a massive and unmaintainable monster, its developers may relearn painful fundamentals of software engineering. Developers must draw the right line between what they'll do with scripts and what they'll do with less convenient but more structured tools.

Technology Editor Peter Coffee can be reached at peter_coffee@ziffdavis.com.

This article was originally published on eWEEK.com.