Use semicolons. Always. It's looks cleaner, and you won't come up against stupid errors like

  return
  {
     foo: 7
  }

From the article -

  When you're done trying to wrap your brain around
  why would anyone in their right mind want to write
  a return statement on a new line

Well, if they love having { on newlines, then it's pretty obvious:

  function foo()
  {
      return
      {
          bar: 8
      }
  }

From the article -

  That's 24 bytes right there. Stamp semicolons
  everywhere and run it through a minifier:

  var a=1;var b=2;var c=3;

Yeah um, hate to break it to you, but a minifier (and any experienced coder) would write it as "var a=1,b=2,c=3;"

  // after minification
  if(condition){stuff()}

Wrong again. Use a better minifier. Closure advanced mode for example will remove the {}, inline functions if it makes sense and hundreds of other things.

  Easy solution: when a line starts with parenthesis,
  prepend a semicolon to it.

  ;(d + e).print()

Ugly horrible hacky advice.

I remember when I first saw C code (coming from BASIC) and thought similar thoughts - eugh what are all those useless semicolons they don't do anything what's the point of them etc.

One important point is that it allows you to rearrange the whitespace in your code, without changing the execution meaning of your code. Which is pretty useful in making your code beautiful and readable and avoiding bugs.

    return
    {
        foo: 7
    };

Do we really want to heed advice when it's comes with obviously wrong advice like "Only people can detect and solve software bugs, not tools."

Static bug analysis is definitely not the be all and end all of software quality but definitely has a place. We automatically run FindBugs (along with unit test etc) on our code base every time new code is pushed by a developer and it definitely helps pick up quirky little errors much more cheaply than code reviews.

I use semicolons, and a linter to let me know when I miss them, because IE pukes all over itself if I don't. Same with trailing commas, IE HATES those.

Article ignores reality.

text on there made my eyes hurt.

the basic message seems to be "don't do what everyone else is doing just because everyone else does it".

Which is great in your bedroom, but in a team with lots of eyes on your code the most efficient way is to use the same style, with that style being one that is easy to read and that avoids potential misunderstandings and bugs.

I can't imagine any situation in the sphere of development this article is about in which worrying about a couple of hundred bytes is more important than having a set of code that someone other than yourself could happily sit in front of.

  I write semicolon-less code and,
  in my experience, there isn't a 
  JavaScript interpreter that can't 
  handle it.

Come visit me at work and I'll show you a few JS implementations on various set-top-boxes that will freak out if you don't use semicolons.

The minifier he uses seems rather bad, wonder which one it was? Ie instead of var a = 1;var b=1; it could be var a=1,b=1; Also in case of the single line if, the minifier could actually remove the brackets.

His comments about minification are silly. It's entirely dependent on the minifier. Google Closure on my system converts:

if(condition) stuff()

To:

condition&&stuff()

So no, it doesn't add curly brackets and increase the size of the expression. And Google closure converts:

var a=1

var b=2

var c=3

To:

var a=1,b=2,c=3

Not what he said all minifiers do.

Umm, please let me restate jameskilton's position below (http://news.ycombinator.com/item?id=1460474):

Use semicolons or your shit wont work in IE... That's why semicolons in javascript AREN'T optional.

What's wrong in using semicolons?

Simple question: Which code does preserve your lifetime? Highly optimized, less readable but really short code, or highly readable, good structured, better maintainable code? As for me, I really enjoy sharing my code with my colleagues. Maybe there are others who don't, but they always will have to work alone in the basement where light never reaches theirs pale faces (think of 'The IT Crowd', for example).

Hm, if we look a little more generalized at what that says, its like:

"If theres a language/library feature with a few quirks, use it anyway, if the border cases aren't that usual."

Thats really bad advice. The main disadvantage is that no one will, if you combine a lot of such decisions, have all this border and special cases in mind, all the time.

FWIW If you're using JavaScript in PhotoShop the following produces an error because there's no semicolon after the second statement:

  for(i=10;i--) { /* do stuff */ }

So maybe that's an example of a JS implementation where it differs on optional semicolons.

If you're so desperate about semicolons, maybe you should just use CoffeeScript instead?

Gotta make a plug here for CoffeeScript, in which semicolons really are optional. CoffeeScript code compiles to neat, legible JavaScript (with semicolons).

http://coffeescript.org

I fail to see the problem with minification. The minificator can insert semicolons by itself because the algorithm for that is known and present in every JS engine. Besides, it just looks cleaner without them. Less for errors too.

The way this semicolon-free syntax is implemented should be reason enough not to rely on it: if the interpreter/compiler encounters an error, it steps back, inserts a semicolon and tries again.

I bet this guy thinks using tabs in source code is a bright idea too.

wow, quite the rant about... um... semicolons. yeah, ok, I only skimmed. much more interesting things out there.