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

InfoWorld|Oct 3, 2013

I know it seems I'm always taking a break, drinking scotch, and letting someone else take the spotlight. Well, here we go again; it just so happens I'm on vacation this week. So sit back and enjoy this highly useful article from my colleague Jonathan Freeman, developer, advocate, and designated guru for everything front end. -- Andrew C. Oliver

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.