JavaScript Practices Make Perfect

I'm back with another short blog about JavaScript. I was really surprised and pleased to see the amount of positive feedback that my last blog post generated. The idea of JavaScript scoping is one of those things that many of us think of as best practices.

But at the end of the day, everyone has a different skill set, and a different background. I recently was talking to a colleague, someone who I do have a great deal of respect for as a developer and a friend. We had to go in for a technical interview, to talk to a potential resource. And during the interview, I asked a bunch of JavaScript questions. After the interview was over, he and I talked offline. And got into a bit of a debate. His point was that JavaScript is "the duct tape of the internet", and "it's the quick and dirty way of doing things when there is no other option."

Now, do I disagree with him on this point. Absolutely, but at the end of the day, my point is that there are a lot of people out there who believe this. If you had asked me 5 years ago, I would have totally agreed with that statement. But then JavaScript was a language plagued by cross browser portability issues, and general problems.

But that was then, and this is now. Since then, thanks to frameworks like Knockout.js, Angular.js, jQuery, Jasmine, etc., JavaScript is no longer the "red-headed step child" of web languages. And instead is a fully formed language that can provide a lot of functionality and even be the primary focus of business logic (in the care of Angular).

Here are some practices, I definitely recommend for JavaScript:

• Scoping the logic: See my previous post, where I discuss the idea of how to scope JavaScript code and why that scoping is appropriate and necessary to maintain modular code that is self contained with minimal coupling and chance of error.
• External Files only, no others need apply: With very limited exception, you should always be writing your JavaScript code in external JavaScript files. This is a point that many people will likely disagree with me, as they will say that if you are using scoped JavaScript, what does it matter. Additionally, you probably are thinking. Kevin, if we use external files, we can't leverage Razor syntax in our JavaScript files. In my experience, this is a bad practice, and a bad habit to get into. The problem is that by using Razor syntax in your code, you are creating a tight coupling between your view, and the model and your JavaScript code. This flies directly in the face of general best practices, as your code is not directly dependent on the elements in the view. I will talk about ways to get around this in my next post. It also creates code that is not testable, and in this day and age, there is no excuse for that.
• NO HARD CODED URLS: Honestly, if this were server side code, this would be a no brainer. But for some reason, many a developer I know feels the need to hard code URLs when they write jQuery AJAX calls. I don't know why everyone seems to think this is an excuse, but JavaScript should never be an excuse for bad practices. Now, I know this falls into the same category as people who say you should be writing your JavaScript embedded, and using Razor syntax. Again, I argue here that you are creating a tight coupling, which is a mistake. If you are going to utilize "@Url.Action", I would argue a better practice would be to put that value into a hidden field and have your "scoped" JavaScript object grab the hidden field to populate the URL. What you'll find is that you now have JavaScript code that can be dropped onto other forms and be in an external file. That's all for now, I just wanted to take a quick talk about JavaScript. I'm going to do more articles in a series, and the next topic is going to be about separating the JavaScript logic from your URL.