562APPENDIX A

The Ajax craftsperson’s toolkit

Ajax is a very easy technology to work with. The toolset required to get the job done is minimal, and it is possible to develop complex Ajax applications using nothing more than a web browser, a text editor, and access to a web server— either on your development machine or through your ISP or hosting provider. Nonetheless, tools are important to programmers, and toolsets are becoming increasingly sophisticated.

As yet, there are no dedicated Ajax IDEs, although these will probably appear in time. Several development tools do, however, offer support for some parts of the Ajax development process. In this appendix, we present an overview of the types of tools available and how they can help you to work smarter and faster.

A.1 Working smarter with the right toolset

The right development tools can be invaluable in speeding up repetitive or difficult processes, and they can have an enormous impact on a developer’s productivity. The wrong tools can be distracting, gimmicky, and constraining, forcing a project into a particular process or way of doing things that doesn’t really fit. Different tools suit different people and will suit them better or worse on different kinds of projects. It’s arguably a key part of a developer’s job to devote time and effort to finding the right toolset. Abraham Lincoln put it nicely:

Give me six hours to chop down a tree and I will spend the first four sharpening the axe.

If sufficient attention is invested in doing so, the returns can be considerable. Finding the balance between perfecting your tools and actually using them is important, too, particularly in a fragmented situation such as the current Ajax tools offerings, as you’ll see in the following section.

A.1.1 Acquiring tools that fit

Many tools can be acquired relatively easily, in the form of free downloads, open source projects, or commercial products. There are no mature tools dedicated to Ajax yet, but several are available that are designed for developing web applications, and many of these support JavaScript, HTML, and CSS.

Ajax uses the same technologies as classical web applications but in quite different ways, as we outlined in chapter 1. Instead of being built out of lots of little pages presented in sequence, an Ajax application will tend to have only a few pages—and often only one—that undergo a variety of programmatic transitions as the user works with them and that talk to the server asynchronously in the

Working smarter with the right toolset	563

background. Further, because of the much greater volume of JavaScript being generated, the Ajax programmer is more likely to be developing with JavaScript frameworks (see appendix C for a round-up of frameworks, and chapter 3 for a discussion of a few of the more popular ones).

These differences raise two concerns, then. First, the tool may make assumptions about page-based workflows that are at odds with the Ajax approach. Second, support for JavaScript may be based on the use of a particular set of functions or coding practices that don’t play well with third-party frameworks that the user is employing.

The differences, then, are mainly in the high-level structure of an application rather than in the details. The concerns raised here are more likely to apply to complex tools, such as IDEs, than to simpler tools, such as JavaScript-aware text editors.

It’s important to bear these considerations in mind when evaluating tools for an Ajax project. We’ll raise them again later when we look at the different classes of tools on the market.

Finally, it’s worth noting that many tools these days provide extensible feature sets, in the form of plug-ins. Complex tools such as general-purpose IDEs and web browsers are used by different types of users in different ways. Plug-ins allow users to customize a base application with the specific features that they need, avoiding bloat in the base feature set, and empower them to extend the functionality of an app in ways that the original development team hadn’t anticipated. Two notable cases of plug-in–based applications are the Eclipse IDE, which, although it is mainly a Java developer’s tool, supports a range of Ajax functionality through plug-ins, and the Firefox browser, which has an active plug-in (a.k.a. extensions) community and several useful extensions targeted at web developers.

Eclipse and Firefox both have very active plug-in communities, and the chances are that a plug-in already exists that does more or less what you want. There is also a strong tradition in computing, and in web development, of building your own tools, to which the plug-in approach also caters. Let’s have a look at that tradition now.

A.1.2 Building your own tools

As an alternative to buying or downloading a ready-made tool, you can always write your own tool. This may sound daunting and unrealistic, given that the discussion has focused so far on IDEs and large-scale tools. We certainly wouldn’t suggest that you begin an Ajax project by writing its own IDE!

564APPENDIX A

The Ajax craftsperson’s toolkit

There’s a strong tradition in UNIX culture of developing small tools that do a single job. These kinds of tools are easily developed in a short time and are simple enough to be maintained easily, too. The stopwatch classes that we developed for profiling JavaScript code in chapter 7 are an example of this kind of tool, as is the output console that we’ll demonstrate in section A.3.4.

Tools written in JavaScript and other Ajax technologies have the advantage of being portable across any browser. However, the capabilities available within the browser are severely limited, owing to the JavaScript security model that we discussed in chapter 6. Sometimes it makes more sense to write a tool as a standalone program, whether in .NET, Java, or any other programming language. The HTTP debuggers that we describe in section A.3.3 are a case in point here.

A middle way between writing tools within the browser and writing a standalone tool is to develop a plug-in. Many of the larger web development tools support the development of plug-ins these days, and some have made it quite easy to develop plug-ins, too. Two notable examples are the Firefox web browser and the Eclipse IDE, as discussed in the previous section. Eclipse even offers a set of plug-ins, bundled with the core download, that make it easy to write plugins. Nonetheless, plug-in development is somewhat more advanced than developing in-browser tools and probably only justifiable within the time budget of a larger project.

A variety of tools can be useful in Ajax development. These are rather scattered at present, and actively maintaining them is an ongoing task. Let’s say a few words about that before moving on to look at some specific tools.

A.1.3 Maintaining your toolkit

As noted, Ajax tools are currently rather fragmented, a rather different situation for the Java or .NET programmer used to sitting in front of the comfortable bulk of Eclipse, NetBeans, or Visual Studio.

Developers owe it to themselves to keep their toolkit up to date. Without the central focus of a de facto standard IDE, this task is somewhat more problematic and will generally rely on word of mouth, mailing lists, portal sites, blogs, and the other distributed communications media of the Internet.

The most fundamental tool for any developer is the editor into which he types his code. Let’s take a look at them next.