The explosion of client-side JavaScript in Web 2.0 applications has taken many developers by surprise. I’ve often found that more senior members on web development teams shy away from JavaScript coding, preferring the known quantity (and perceived purity) of server-side development. After all, isn’t JavaScript that flaky, inconsequential language that we used to use to make pretty pull-down menus, but that can’t be relied on for any serious purpose? Since when did it become something that I can’t leave to my UI designer? Can’t I just Google for a script kiddy’s website any more? Do I really have to start taking JavaScript seriously? Well, yes. These days, it’s becoming inevitable that the majority of the team comes into contact with client-side JavaScript. But still some of us resist it, largely due to painful past experiences of long nights spent trying to get browser X to work the same as browser Y.

As a consequence, I consistently observe two patterns over the course of a project. First, the client-side effort doesn’t get the benefits of the skill and experience held by seasoned object-oriented developers. Instead the JavaScript code is left to newer, less experienced members of the team; the rigorous practices that the more senior members of the team usually insist on aren’t advocated for to the same degree on the client side. Second, because of the fear of JavaScript, opportunities to make the application slicker, more user-friendly and generally more modern are missed.

I don’t mean to downplay the difficulty of JavaScript coding. There’s no doubt about it: it’s eccentric, it’s not consistent between browsers, it’s slow where you don’t expect it, it does objects in a weird way, and the list goes on. But here’s where we can turn the situation on its head. What does our experience tell us about how to attack a difficult area in our code? It certainly doesn’t tell us to ignore it and hope it works out in the end. No, it tells us to shine a light on the painful area and apply our development practices even more strictly than usual: test-drive it, cover it with unit and functional tests, aggressively refactor it, separate concerns, extract the right objects, apply design patterns where they can help, and so on.

What I’ve seen work when it comes to JavaScript is to fight fire with fire. Rather than responding to the difficulties of JavaScript by shying away from it and rationalizing a lack of quality in our client-side code, we can choose to react by applying our practices more strictly, not less. We can ask ourselves how to better test their JavaScript, how to expose complexity more clearly, how to objectify concepts more naturally. We can break our JavaScript into layers, and apply typical MVC patterns as we might do in server-side Java or Ruby on Rails code. We can abstract our AJAX requests and responses in order to better simulate them in our tests. We can run our tests in a continuous build on all our target browser/platform combinations. Why not try to hold our JavaScript to the same standards as any other part of our code? It’s not always easy, and it certainly takes practice and strict discipline. I’ve found that the learning curve is steeper and longer than with other languages. But I’ve also found that there’s really no reason why we can’t be as rigorous with our client-side development as we are anywhere else in our codebase as. We end up with all the usual benefits: better stability, fewer bugs, more malleability.

Getting started

Amongst other topics, over the next few weeks I’ll be posting concrete ideas for ways to approach JavaScript development. Most of them will center around JsUnit, because in my experience it’s the introduction of unit tests and test-driving that drive the most dramatic improvements in not only the software but how we think about our work.

So, what does it look like when a team attacks JavaScript in this way? As someone who has been through his fair share of pain coding JavaScript, it’s thrilling to observe. I’ve seen teams at Pivotal Labs take a more disciplined and rigorous approach to JavaScript than I could have imagined even a couple of years ago. And the best part is that besides the benefits I already mentioned, there’s a huge payoff to all this added discipline: rather than being afraid of JavaScript development, we sometimes enjoy it and look forward to it. It’s simple, really: JavaScript is hard, so let’s throw everything we know at the problem. I’ve found that if we do, we can tame JavaScript to the point where our progress becomes as predictable as we expect in the rest of the codebase.