Working with Dynamic Interpreted Languages
A number of techniques make it easier to enjoy success with your dynamic-language projects.
Testing at all levels, and "Test-Driven Development," are probably familiar. But adding some extra juice to a testing model will really pay off:
1.  Code coverage analysis - knowing exactly how much of your program and which parts of it are being exercised by your test suite - is critical. Testing without coverage analysis can give you a false sense of security, or cause you to eat up time fixing the wrong bugs.
2.  Expand your test coverage using aggressive testing mechanisms that take advantage of dynamic runtime features. For example, Kevin Clark's Heckle library1 for Ruby will automatically mutate your Ruby code in critical ways, in order to make sure that if the code is altered, your tests take notice and fail. If the code changes (e.g., a branch condition is reversed, with > becoming <=) and your tests still pass, then something's wrong.

Although it may sound like an exercise in red tape, write a style guide for your team's code. Discuss things like variable and method names, and rules for language features to embrace or to avoid. Without a compiler to help catch mistakes, it's really easy to assign a value to one variable and try to read it from another - maybe in a different module of code - and automatic type conversions only make this trickier. The style guide can help you prevent similar names. Then use a configurable lint-type tool (such as Douglas Crockford's JSLint2 for JavaScript) to check your code against your style guide. Make this step part of your testing scheme.

For some rules, consider writing your own testing tools. Suppose you want to find all symbol pairs in your code that differ by only one or two characters, suspecting you might find some bugs this way. If your team is ramping up on a new language, building a script to produce this report is a fun and practical exercise in language reflection.

In conjunction with testing, leverage your SCM (software configuration management, or source control) system to help keep dependencies together. Bring all of your scripts inside the SCM system, even if that was not common practice before. Tag or annotate versions of files that have been tested to work together. If your enterprise SCM system is unwieldy, consider bringing in a lighter-weight source control system, like Subversion3, for your day-to-day builds, while still committing code to the company's official repository regularly.

Another addition to your toolset is the axiom that just because a language supports a particular construct doesn't mean it's a good idea to use that construct. A modest number of programming constructs can be the source of serious problems, and the easiest way to rein in the trouble is to resist the temptation to use those constructs in the first place. At the top of the list is the eval statement4, which takes string data and passes it to the interpreter to run as code. At the least, it's worth auditing your code and making sure you know each and every place eval is called and why (remember, each eval call can potentially hide arbitrarily many other eval calls, depending on what is passed to it).

Some valuable dynamic programming patterns can be used, but separated out from the core runtime app by design so that they're easier to analyze and test before the application is run. Examples include scripts to generate a set of types, such as proxies for accessing remote resources (databases or Web services). Sacrificing full dynamism by running a "generate" script ahead of time, which builds a concrete proxy5 that can later be used at runtime, is a reasonable compromise.

Working with Legacy Infrastructure and Databases
In a pure AJAX scenario, a dedicated server-side proxy is a practical solution to both network issues (access to various network resources, unusual protocols, etc.) and data access. Although, as mentioned earlier, running an additional proxy app can itself involve some enterprise red tape, it opens up a world of solutions as an extra tier in the architecture.

One of the advantages of a proxy app is that it can leverage existing code and platform knowledge in your company. If, for example, the "old" Website used Java to access a particular data store, then it is straightforward to create a Java Web service that accomplishes the same access and offers those records as XML or JSON for the new AJAX application.

Alternate Approaches: Side-Stepping AJAX Challenges
In addition to writing JavaScript to build AJAX clients, there are a variety of other approaches to producing AJAX and AJAX-like rich Internet applications (RIAs). Some of these alternatives are noteworthy for enterprise developers because they can obviate the need to write script applications directly. In some cases they can make it easy to take advantage of a company's existing codebase and comfort using a particular platform (not to mention those critical support contracts).

The alternate approaches break down into two groups:
1.  Building browser-native JavaScript applications without actually writing the JavaScript
2.  Building applications that run in browser plug-ins (Flash, Java, etc.) rather than the browser's JavaScript engine

Compiled or Generated JavaScript: Building AJAX Clients Without Coding JavaScript
Outside of writing your own script or using JavaScript libraries, there are a variety of other ways to end up with JavaScript apps. These other approaches fall into two groups of their own:
1.  Systems that let you code in another imperative language and then transform that to JavaScript
2.  Systems that let you declaratively mark up the AJAX effects you'd like, and then generate script to do it

The Google Web Toolkit (GWT) is the most influential library in the former group6. GWT allows you to leverage your company's existing investment in Java development by building both your browser client and your Web services using standard Java. When you need to pass data between tiers, you do so using plain old Java objects (POJOs). At build time, GWT compiles the client-side Java application into optimized JavaScript, and handles marshaling data between the server and the client.

A .NET-based alternative to GWT is Nikhil Kothari's Script#7. Similar to GWT, Script# translates C# code to JavaScript. Unlike GWT, though, Script# attempts to create human-readable, human-editable JavaScript, rather than code optimized for speed and size. If your firm has a large investment in C# and .NET technology, Script# may be an effective way to leverage that investment to create browser applications. It's also worth noting that while Mr. Kothari is an architect at Microsoft, Script# is thus far a personal project and not part of a Microsoft offering.