Web app coders: Clean up your act!

When writing JavaScript front ends, is your workflow all over the place? Do you cling to repetitive actions instead of automating? Then this advice is for you

Page 2 of 2

Automated testing

JavaScript is a dynamically and loosely typed interpreted language, which contributes to its flexibility. The downside of that flexibility is that you don't find bugs in your code until you run it.

Enter testing. I'm not a testing "evangelist" (I often find such preaching close-minded and dangerous), but the merits of testing are widely known, and I strongly recommend testing JavaScript code. The degree to which you test is up to you, but at the very least set up testing in your workflow.

Remember that you can scale testing up or down as needed throughout the project, but if you haven't accounted for it in the workflow, it won't happen even if you want it to. Write your tests in one of the popular frameworks: Jasmine (my choice), Mocha, or QUnit. These tests have to execute in a JavaScript environment, so use a test runner like Karma to automate the process for you. (In fact, execute your tests in multiple JavaScript environments, because not all of your users are running Chrome Canary.) Karma can be easily configured to launch your tests in all the browsers you expect to support, so you won't run into production surprises with that one version of Opera.

Know any JavaScript developers who aren't testing? Encourage them to start doing it and support them. It will change the way they write code for the better. They'll start writing code so it can be tested, which means it will consist of decoupled and discrete units of code. If their JavaScript looks like a giant run-on sentence and is tortuous to maintain, this may be just what the doctor ordered.


You're not writing clear, easily understandable code for you -- you're doing it for the person who comes in after you leave and has to pick up where you left off. The same goes for documentation, so be considerate. Remember, there's a selfish benefit, too, when working on longer projects and your memory of what you did early on fails you.

It's too easy to get into "the zone" and think of documentation as a speed bump, but I assure you that documenting as you code is far from impeding your success. Yes, it will slow you down and make you think about what you're doing. That's a good thing. Use a documentation generator to pull out and format your comments into something human-readable. If you don't know of one to use for JavaScript, take a look at JSDoc or Docco. I'm partial to Docco because of the presentation of the documentation (source and docs side by side), but decide for yourself.

Minification, obfuscation, and concatenation

Now that your code is linted, tested, and documentation has been generated, it's time to optimize your app for the end-user. Minification and obfuscation will reduce your overall payload size, while concatenation will decrease the number of HTTP requests needed. The two together boost user experience by improving load times, which is critical for user retention on the Web.

Minification removes all unnecessary characters from your code, such as comments and extra white space. Next, obfuscation renames your identifiers to the bare minimum. I know you think prepareTextForPosting is a nice, descriptive function name, but sQ will do just fine for the interpreter. This can shave off quite a few bytes depending on the length of your identifiers.

Next is concatenation. This takes your 48 separate JavaScript files (because you've been doing unit-testable, modular development, right?) that have been freshly minified and obfuscated and puts them all into a single file. For minification and obfuscation, use UglifyJS with the mangle property set to true. Since I'm using Grunt already, I'm using the concatenation plug-in built by the Grunt team.

Now stop reading this article and go assess your own front-end stack. Check out some of the links included and start playing with the technologies that are new to you. Lay down a strong foundation for your projects, so they can support you throughout the entire development cycle. Remember, it's less about the individual items you implement and more about attentiveness to your workflow. Even if you just set up Grunt and start linting your code, you'll be in much better shape than before -- and it will be much easier to adopt other optimizations.

This article, "Web app coders: Clean up your act!," was originally published at InfoWorld.com. Keep up on the latest developments in application development, and read more of Andrew Oliver's Strategic Developer blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.

| 1 2 Page 2