5 things they told you not to use in JavaScript

Or, don’t trust what “wise” elders tell you.

1. “Don’t rely on automatic semicolon insertion”

Whether you like it or not, whitespace is significant in JavaScript. A linebreak indicates, in most cases, the end of a statement; a semicolon is automatically inserted for you. In order to be able to write properly working code, you need to be aware of the rules of Automatic Semicolon Insertion, regardless if you choose to add semicolons at the end of lines or not.

2. “Never use the with statement”

Short of making runtimes easier to implement, there’s no compelling reason not to use with. Here’s Mozilla’s definition: “(with) extends the scope chain for a statement.”—that’s all there is to it. If a program becomes hard to read or understand by using “with”, you should consider alternatives, but it’s not the with statement’s fault. You can just as easily write perfectly clear JavaScript code that’s easier to understand because you’re using “with”.

Consider the following code:

function testSomething(test){
  test.assert(1==1);
  test.assert(2<;3);
  test.assert('x' == 'y');
};

// vs.

function testSomething(test){ with(test) {
  assert(1==1)
  assert(2<;3)
  assert('x' == 'y')
}}

One of the things that with allows here is to not repeat yourself unnecessarily, which, in my book, is an advantage.

3. “arguments.callee? What, are you crazy? It doesn’t work with strict mode.”

Actually, it’s really convenient to be able to reference the currently called function this way, for example if you want to do a recursive call (as an alternative you can give your function a name). Here’s something fun you can do with it:

alert((function(){return"alert(("+arguments.callee.toString().replace(/s/g,"")+")());";})());

Strict mode is great if you really know what you’re doing, but if you do so, you don’t need to use strict mode (I call it “straight-jacket mode”, personally).

4. “Oh no, but __proto__ is proprietary!!!1!”

Sure, but what does “proprietary” mean anyway? __proto__ is all major JavaScript implementations, except for Internet Explorer. It enables swapping out the prototype of an object without having to copy over each and every property from one object to another.

You’re probably using “proprietary” DOM stuff every day, if you do any kind of browser JavaScript development.

If you’re not targetting runtimes that don’t support it—by all means use it. If you have to support these runtimes later, just change your code to adapt to that. It often boggles the mind how much time is spend on avoiding potential future issues while JavaScript is a dynamic scripting language that is changed and updated as easily as saving a file. Fix problems when you actually have them. Use the time you’ve freed up by not prematurely optimizing and spend it with your family or have a holiday on the beach.

5. “But it will not longer be supported in <;fabled future version of JavaScript>;”

So what? Some committee somewhere is making up future standards, which are subject to change. Code for what works now, not for what may or not may be 10 years hence. For day-to-day programming, there’s no point in restricting yourself in what you can do and how you can do it based on things that might not happen after all.

My recommendation: learn the language, and use it to your liking; and don’t rely or blindly accept what any “wise elders” tell you. Try to do something new and crazy every day. You might not end up using the crazy, but it’s the best way to master JavaScript. Develop your own style that you are comfortable with. Experiment.

Update: Kit Cambridge adds some technical details, explanations and pros and cons.