Why the Agility and Refactoring?

I’ve been asked more than once recently why we chose to emphasise refactoring and development practices so much in Ajax in Action. Surely these are general concepts applicable to any coding job, so why give them so much attention in a book on Ajax?

I’d say that, yes, they are key in any non-trivial software development project. Non-trivial is the key word here. Prior to Ajax, any javascript code tended to be trivial because:

1. it couldn’t communicate with the server, therefore it couldn’t do very much that was really useful, just make the UI a little nicer, richer or easier
2. the code doesn’t survive a browser page refresh. In a pre-Ajax app, page refreshes are very frequent, therefore the javascript code is not very long-lived.

Because of these factors, olden-days javascript code didn’t have to be very well-written, certainly not designed with an overall plan in mind.

Ajax changes the game because javascript can now participate in the important stuff, and may tend to hang around for a long time. Suddenly, good design practises matter a lot more.

I suppose that there’s a limit to how much code our brains can hold at once. If the system is simple enough that we can keep track of it all, then we don’t really need design much. Above a certain complexity, though, refactoring/design wrap up a lot of the details, leaving us with a system expressed in fewer, higher-level terms, allowing us to hold it in our head all at once.

I could have written a much smaller book that described how the XHR object worked, and left it at that. I think, though, that to do so would have only told half the story. Readers of the book need to be able to apply the techniques in real-world situations, where qualities like reliability, stability and ease-of-use matter. The importance of having design patterns hit me on the head some time back, in a lesson that I encapsulated into section 8.4.2’s examples. By unwittingly mixing our design patterns up, my colleagues and I had hit on a combination of event-processing and UI-rendering code that rapidly set our ‘Ajax’ app’s memory footprint soaring into the 100’s of MB. Giving the patterns names, figuring out which ones were in use where, and which combinations worked well with one another, ended up giving us a 100-fold reduction in footprint. Not bad for a day’s work, and the experience persuaded me to write an article about JavaScript too.

Comments are closed.