Ask HN: Why use semicolons to terminate statements in modern JavaScript or ActionScript?

I guess it partly depends on how you view the relationship between programming languages like Javascript and the typographical conventions of natural languages like English.

I tend to think of a series of statements in a programming language as more akin to a to-do list of imperatives than a paragraph from a recipe book. If you are writing a to-do list, you don't need to mark the end of the instruction; the end of the line functions for this purpose. Something like this would be sufficient for understanding:

  break eggs into pan
  fry the eggs
  remove the eggs from pan
  eat the eggs

  Break the eggs in the pan; now fry the eggs; next remove the eggs from the pan; now eat the eggs.

As for convention: yes, I have indeed had some funny looks when asking this question in real life (no slaps yet, though). If you're working in a team, you obviously need to conform to one coding style; I'm coming from a mostly sole-coder perspective. But why does the convention persist? (Is that a strange question to ask?) Is it simply the weight of tradition, or are there other benefits?

Only if the minifier is broken. Some of them are (I don't want to name names since it's been a while since I checked). The relevant advice would be "don't use broken minifiers," not "don't use automatic semicolon insertion."

"2. Convention -- If you wrote js code with no semicolons and then showed it to other JS programmers, you'll get a funny look, a slap in the face, or a free copy of "Javascript for Dummies", depending on the context."

The correct response to which is to politely refer them to ECMA-262 section 7.9 and go on your way.

I'm all for adopting the semicolon convention myself, even in sole-programmer projects, if there are reasons for using it; that's basically why I asked the question in the first place. (And of course I adopt it if contributing to a project which already uses it - no need to rock the boat.) Things like minification are exactly what I'm interested in, although I was under the impression that HTTP compression does a better job than Javascript minifiers at solving the size problem. Obfuscation is, of course, another matter entirely.

Is this correct? I would imagine that JavaScript implementations typically compile it into intermediate code, wihch is then interpreted. If so, then it shouldn't make any difference whether you add the semicolon or not.

Why would you write a return statement like that in the first place? (Not intended as flamebait - I am genuinely curious to know.) If it is a simple typo that separates the 'return' from the '[1,2,3]', then isn't the negligent typist just as likely to leave off the all-important semicolon? Or is there a genuine reason you might want to put the [1,2,3] on a line by itself?

   win = Window.new()
      .setTitle("A new window")
      .setForeground(Red)
      .setBackground(White)
      .setMenuBar(fileMenu, viewMenu, helpMenu);

   win = Window.new()\
      .setTitle("A new window")\
      .setForeground(Red)\
      .setBackground(White)\
      .setMenuBar(fileMenu, viewMenu, helpMenu);

But since they are optional now, using them throughout our code won't help us for the example above: it would still wrongly return undefined because of the implied statement end. So it could be argued that semicolons provide a false sense of security in this new, semicolon-optional world. :^)

  function getIndex() {
    return 0  
  } 
  function f1() {
    alert("foo") 
  } 
  function f2() {
    alert("bar") 
  } 

  var intIndex = getIndex() 
  [f1, f2][intIndex]()

The problem is, the javascript rules for continuing lines are that whenever the next character is any of [({+-, the line is assumed to continue. This is generally correct but not always. For comparison, the analogous Python rule is that a line continues either with an explicit \ or when one of [({ has not yet been closed with its pair. The Python rule doesn't lead to any ambiguous cases that I am aware of, because unclosed parentheses would just be invalid syntax.