The examples being put forth in defense of requiring semicolons are really weak. // 1. MyClass.prototype.myMethod = function() { return 42; } // No

The examples being put forth in defense of requiring semicolons are really weak. // 1. MyClass.prototype.myMethod = function() { return 42; } // No semicolon here. (function() { // Some initialization code wrapped in a function to create a scope for locals. })(); There are at least two potential solutions here: 1) put a semicolon after every function declaration, and 2) put a semicolon before every self-executing function. Both work fine. Either way, you have to remember to put a semicolon somewhere, right? No difference in cognitive load. And if you say that #1 is easier to remember because it's more C-like, you've just blown your cover. You don't actually write C at your day job, do you? Because otherwise you'd realize that C does not require semicolons after functions. [normalVersion, ffVersion][isIE](); Same thing. Just put a semicolon before lines that start with arrays like this. Also this code is crap. -1 == resultOfOperation() || die(); OK hold up, who really writes this stuff? Is this what code looks like at Google? Forget semicolons for a second and let's work on basic code readability. Explain the line aloud. "If resultOfOperation returns negative one, then die." Now write it. if (resultOfOperation() == -1) die(); Sweet, now people can read our code without juggling operator precedence rules in their head. Minor side effect: the semicolon issue goes away. return { foo: bar } Really? Why oh why would you write such a thing and expect it to return the object?