Scripting languages combine attractive possibilities with challenges. On one hand, Perl, JavaScript, PHP, Python, and the AJAX application model are approachable enterprise development tools. They contain high-level verbs to lower the learning curve and have readily interpreted execution that puts code to work quickly and makes debugging easy. Costs are low, since script-driven browser-based applications are cheap to deploy and the breathtaking speed of AJAX applications lowers task performance time. However, several opposing arguments have been raised. One is the lack of historical development tools. What documentation does exist is often uninformed and outdated; this is especially true for JavaScript. Scripting permits users to shape generic applications for swiftly handling routine tasks consistently and intelligently, offering an intuitive approach and near-instant gratification for interpreted languages, yet this ease often leads to resource-intensive errors and the ever-seductive possibility to use scripting in roles for which it was not intended. Simple safety mechanisms such as strong data typing would help correct this issue, but that's like putting a padlock on the cookie jar. Scripting usually lacks modularity; platform inconsistency can make large-scale efforts as complicated as a ball of snarled yarn. Scripting tests a development manager's mettle: putting a clear barrier between what a scripts will do and what requires more structured tools solves all the problems cited above. There, in the development court, the ball rests.