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.
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.
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.
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.
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.
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 */
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:
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.Besides, downloading a zip file is still faster than downloading the uncompressed file, so either everybody's doing HTTP compression wrong or it's not so hot to start with.
Not having semi-colons risks a lot of code breakage. Doug Crockford's JSMin has an aggressive mode which always strips line breaks and another which doesn't to avoid breakage when semicolons don't exist.
Personally I would just say that if you don't use semi-colons you should think hard about why you code at all. I'm not the anal-retentive type but sloppy code isn't awesome. I would put this in the same category as naming variables $whatever or $x. If you've never picked up someones second hand project you may not appreciate why a pleasant coding style matters.