Web app coders: Clean up your act!

As developers, we recognize when something can be automated or optimized. It begins with a nagging feeling, then develops into mild discomfort, and if left unremedied, grows into frustration and anger.

That’s why I’m surprised at the lack of workflow optimization I see in most front-end application development projects. Time and time again I see boilerplate activities carried out manually over and over. So many of these brain-dead pursuits can be automated easily, saving countless hours and adding quality.

Of all the reasons for avoiding this — such as “I don’t have time” or “It’s just a small project, I don’t need anything like that” — the lament “I don’t know where to start” is the one I sympathize with the most. Shiny new JavaScript frameworks are crawling out of the hive at an alarming rate, and it’s a full-time job just to keep up with them.

As humans, we’ve evolved a mechanism for dealing with this kind of overwhelming noise: Tune it out and go about our business. I understand the feeling, but I also know there’s signal buried in the noise. It’s worth getting to, and I’m here to help. Want to get some of that buttery goodness called efficiency in your front-end workflow? Read on.

It all starts with a build

Whether it’s a weekend hack or a multiyear enterprise UI effort, every project deserves to be built. Using a build tool will organize your workflow and save you loads of time down the road. There’s minimal setup cost, so this should be a no-brainer. I spend most of my time writing 100 percent JavaScript projects, so I use Grunt.

Grunt has tons of plug-ins that will let you do just about anything you want, but simply set up what you need and move on. Sure, you can set up Grunt to ensure you’re on the right branch, include all the Git contributors in the header comments, and create a pretty email describing the build — but why turn this into a yak-shaving extravaganza? If you don’t know where to start, then consider the following essentials.

Static code analysis

This is an excellent first step to save you hours of debugging time. A linter will sift through your code looking for syntax errors and common mistakes. Your IDE or text editor should be configured to do this so that you can get feedback as mistakes happen, but include it in the build anyway. In addition to looking at syntax, you can use linting tools to enforce code guidelines. This is particularly helpful to establish consistency when working with a team, but it’s also a good way to keep yourself honest when working alone. Check out JSHint for an idea of how it looks and works. Linters, however, don’t tell you if your program is working the way you want it to. For that, you need to write tests.

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.

Documentation

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.