[adelle]

Welcome to the real world, where "the next programmer to work on this might be dumber than you" is considered a valid justification for cargo-cult programming.

A good minifier should replace line-breaks with semicolons as appropriate using all the same inferencing rules as JavaScript itself. Until one of those comes along it seems like using semicolons is necessary to make the best use of the tools that do exist.

[timknauf]

Welcome to the real world, where "the next programmer to work on this might be dumber than you" is considered a valid justification for cargo-cult programming.

Yes, I am a little surprised that some of the responses have assumed that because I'm questioning the usefulness of a syntactic element, I'm not interested in code quality or consistency. Quite the reverse: I'm very interested in producing code that is as clean as possible. What I've been trying to discover is whether the semicolon is a vestigial element that can now be left behind.

But the concensus seems to be that there is still a present need for semicolons, at least when it comes to interpreted JavaScript (though I'm still not convinced that the same holds for always-compiled variants like ActionScript). And like you say, current tools expect - quite reasonably - a certain coding style, even if they should use the full set of inferencing rules.

[inimino]

I've written JavaScript sans semicolons for years and have not encountered incorrect parsing by any browser. I find this style cleaner and easier on the eyes.

I haven't done any testing regarding parsing speed, but I would be shocked if anyone can demonstrate a measurable speed difference in a realistic testing scenario.

[timknauf]

I've written JavaScript sans semicolons for years and have not encountered incorrect parsing by any browser.

Yes, neither have I - but then I'm doing fairly simple stuff. I do test across a fairly broad range of browsers, though.

I find this style cleaner and easier on the eyes.

I'm glad I've found at least one kindred spirit in this regard! I was beginning to think I was the only one.

I haven't done any testing regarding parsing speed, but I would be shocked if anyone can demonstrate a measurable speed difference in a realistic testing scenario.

Perhaps with very, very large and complex code if the JavaScript engine uses an old-style interpreter? But surely the problem will continue to diminish away to nothing as more JavaScript engines implement efficient compilation.

[inimino]

I'm glad I've found at least one kindred spirit in this regard! I was beginning to think I was the only one.

People with a background in non-brace-and-semicolon languages are more likely to feel the same way. Others (e.g. recent graduates learning only Java) may be less comfortable with the lack of semicolons, and may regard it as "sloppy," perhaps from a lack of familiarity, or because they've never thought about it or haven't read the specs and are simply regurgitating what they've heard.

On a related note, in CSS the semicolon is a separator, not a terminator, so to pick on some CSS from an arbitrary Web page:

    body  { font-family:Verdana; font-size:10pt; color:#828282; } /* unnecessary semicolon */
    body  { font-family:Verdana; font-size:10pt; color:#828282 } /* equivalent but shorter */

Also on the topic of cargo-cult coding cruft, you'll often see pseudo-XHTML with self-closing tags that include a space, e.g. "<br />", invariably served as text/html, where it is equivalent to "<br>" with the addition of two extraneous characters and one syntax error. People still actively recommend this practice, despite the fact that even when served as HTML, the extra space has not been necessary since the days of Netscape Navigator 3 or 4.

Perhaps with very, very large and complex code if the JavaScript engine uses an old-style interpreter?

JavaScript is only parsed once, even in ancient browsers, and no matter how much code there is, the time required to download it, not to mention executing it, will typically be orders of magnitude greater than the time spent parsing it. I had never heard the performance reason before as a justification for this practice, but I consider it a total red herring until someone provides hard numbers that suggest otherwise.

Ultimately this is a question of style and personal preference, but if you happen to prefer the cleaner style as I do, I see no technical reasons why you should not use it.

Finally, never forget Wadler's Law:

http://www.haskell.org/haskellwiki/Wadlers_Law

[timknauf]

Thanks for the detailed reply.

People with a background in non-brace-and-semicolon languages are more likely to feel the same way.

Yes, and most of them are off happily working with their Pythons, Rubys, Haskells and the like, staying well away from this sort of discussion. :^) I've been writing a lot of ActionScript lately (making games which target Flash), so I've been thinking about ECMAScript-style syntax a lot more than I have in the past.

Also on the topic of cargo-cult coding cruft...

I see "cargo-cult coding cruft" most often in languages which are parsed by a client (e.g. CSS, XHTML, JavaScript). I suspect that this is due to fear that some client, somewhere will choke on the actually-correct code. And whaddaya know - sometimes that client actually exists. It's called Internet Explorer 6. ;^)

Finally, never forget Wadler's Law

Yeah, I'm reminded of an old Python joke:

  Question: Why is Python such a productive language?
  Answer: You won't have to spend any time arguing about brace style.