Table of Contents for
Maintainable JavaScript

Version ebook / Retour

Cover image for bash Cookbook, 2nd Edition Maintainable JavaScript by Nicholas C. Zakas Published by O'Reilly Media, Inc., 2012
  1. Cover
  2. Maintainable JavaScript
  3. Maintainable JavaScript
  4. Introduction
  5. Preface
  6. I. Style Guidelines
  7. 1. Basic Formatting
  8. 2. Comments
  9. 3. Statements and Expressions
  10. 4. Variables, Functions, and Operators
  11. II. Programming Practices
  12. 5. Loose Coupling of UI Layers
  13. 6. Avoid Globals
  14. 7. Event Handling
  15. 8. Avoid Null Comparisons
  16. 9. Separate Configuration Data from Code
  17. 10. Throw Your Own Errors
  18. 11. Don’t Modify Objects You Don’t Own
  19. 12. Browser Detection
  20. III. Automation
  21. 13. File and Directory Structure
  22. 14. Ant
  23. 15. Validation
  24. 16. Concatenation and Baking
  25. 17. Minification and Compression
  26. 18. Documentation
  27. 19. Automated Testing
  28. 20. Putting It Together
  29. A. JavaScript Style Guide
  30. B. JavaScript Tools
  31. Index
  32. About the Author
  33. Colophon
  34. Copyright

Part III. Automation

“I . . . am rarely happier than when spending an entire day programming my computer to perform automatically a task that would otherwise take me a good ten seconds to do by hand.” —Douglas Adams, Last Chance to See

Prior to the year 2000, it was quite common for web developers to simply put their JavaScript files onto a web server in the same form as they had in source control, comments and all. If there were 10 files in source control, then there were also 10 files on the server. This type of mirroring, in which what you had locally and what you had on the server were identical, allowed for rapid changes. Additionally, this led to the “view source” era, where many web developers learned from going to a site and then viewing the source of the page along with its JavaScript.

Of course, during that time the amount of JavaScript found on websites was still quite small compared to today’s standards. Whereas a hundred lines of JavaScript code written by a single developer used to be the norm, today’s modern web applications often have thousands of lines of JavaScript being modified by a dozen or more developers. Needless to say, the old way of doing things just doesn’t work any longer.

All large-scale (and many small-scale) web applications rely on automation for processing their JavaScript files. Automation is quite common with other parts of a web application stack, but until 2005, hadn’t been popularly used for JavaScript. Adding JavaScript into the overall web application automation system is an important step for maintainability, allowing you to have the same type of safeguards as other parts of the system.

Advantages and Disadvantages

The advantages of using an automated build system for your JavaScript are:

  • The code you have in source control doesn’t have to mirror what is put out into production, so you can set up source control any way you want without having to worry about whether it’s optimized for use on the server.

  • Static analysis can be performed automatically to find errors.

  • JavaScript can be processed in any number of ways before deployment, including concatenation of files and minification.

  • Testing is automated, so problems can easily be identified.

  • Automatic deployment into production servers is easy.

  • You can easily and quickly rerun common tasks.

Using such automation does come with some disadvantages as well:

  • Developers might need to run a local build while making changes in a development environment. Some developers have a lot of trouble adjusting to this step, having grown used to making changes and just refreshing the browser.

  • The code that is deployed to production doesn’t look like the code that is being edited, making bugs in production harder to track down.

  • Developers who are less technical may have trouble using the build system.

In my experience, the advantages of having automation in place far outweigh the disadvantages. Even those developers who hate the idea of needing to run a local build after making changes tend to come around once the advantages of the system have been realized.