[2] has an inaccurate title. Semicolons are not optional, as is made clear by [2]'s final section that recommends putting ; before ( where ( starts a statement. Nothing optional in that case!
As I noted in my blog, it's not just (, either. ( is by far the likeliest source of trouble, but / + - [ all can serve as infix operators or prefix operators or (in the case of /) lexical delimiters.
Which is easier to remember, the rules in [2] plus the full "when you must use a semicolon because it is not optional" rule? Or the rules that people who know C, C++ and Java follow?
YMMV, but it's no slam dunk, and going "light" on semi-colons risks disastrous bugs. Going heavy tires out readers a bit with chicken-scratching but carries little risk of adding bugs (the worst case is if(C);T -- oops, and empty statement linting helps).
As usual with programming, there is no substitute for thinking and practicing, learning from the bottom up, and avoiding bad religion.
No, "optional" means you can skip it, period, full stop.
False advertising plus module patterns plus concatenation equals big enough trouble for people to be outraged about the false advertising. Better to tell the truth, from the title down.
If you are using your brain fully, perhaps you can avoid firing the footgun. Is this the best use of your brain? I am not so sure.
How about this, I never lead a line with an infix operator, ever, and every other language I use does not require semicolons. Why would it be a bad thing to just pay attention to lines leading with (? Because js is the exception, it actually takes more brain power for me to remember it on every line then when I am leading with (, especially without a compiler complaining at me.
Would you admit that at least for me its a YMMV type of thing?
Of course. I wrote "YMMV" and "I am not so sure" -- those explicitly expressed my doubts about the wisdom of absolutism on either "side" (there are several sides, actually).
NPM fans can use the NPM style well, I've seen it. Whether it scales to the masses remains to be demonstrated, but that may be true of any coherent style.
JS is used by many hackers who do not know all of its rules. It seems to work, mostly (an amazing feat, no?), but I have heard eyewitness testimony from people burned by statements starting with ( that ended up preceded by an unterminated statement, and the kingdom was lost for want of a ;.
Under maintenance, edits tend to make Murphy an optimist. I suspect the NPM crew selects for the best and gets the best. How that would hold up at scale with regression to the hacker mean is an open question in my mind.
As the founding member of the npm crew, I'd like to provide some history.
I started using this style originally because I -- not new to JavaScript, and adhering to the "semicolons everywhere" style -- was bitten twice in rapid succession; first by a leading [ causing a function to receive "undefined" as an argument (instead of two arrays), and then again by a leading ( resulting in a non-function being called. Both were unnecessarily difficult to debug, because my brain couldn't see the error. (Even when JSLint complained, I thought it was lying. ,] looks a lot like ], at first glance, and is valid JS. Maybe I'm a little dyslexic or something.)
So, I thought, "New rule: Commas first, prefix ( and [ with semicolons." Problem solved.
But ending a line with a semicolon seemed kind of silly when I was then prefixing with a semicolon the next line, even though I'd learned that it was absolutely necessary for any kind of "safety" (even as an expert, even as a semicolon user). So, I thought, if I'm doing this silly prefixing thing to make ASI safe, why not just let it be safe, and drop them everywhere?
So I did. And it's pretty nice.
I don't understand why people get so upset about how I write programs, especially those that they don't even use or contribute to. The first time a professional JavaScripter cursed me out at the top of his lungs in a bar, literally spitting in my face while he screamed at me, I realized that there was some essential human weirdness involved here, and it became much too interesting to drop. Every time I ask people to please not lie about JavaScript to newcomers, they accuse me of being dogmatic or a semicolon hater.
But I maintain the JavaScript in Node.js as well, which follows Google's (occasionally insane) C++-inspired semicolon-ridden JavaScript style, and I'm fine with that. It's kind of nice, too, in a different way. More dots. Vim's auto-indenter works a little better.
What's wrong with just not lying? I don't get it at all. People who already know C and Java are usually veteran enough to grok weird language warts. People from Python and Ruby have an easier time learning the exceptions than sticking to the rule, since their habits are usually to omit the ceremonial EOL punctuation. And newcomers don't have any preconceptions anyway; they're busy learning why we call "this" a string, and why this is always something different, and crazy shit like "a function is an object and you construct an instance of it with new which calls it on a this that inherits from its prototype". (I mean, seriously, read that sentence to a nonprogrammer, and ask them what it means. It's gibberish!)
But people react to it like I've insulted them personally, when I just ask that they not fill newcomers' heads with lies and fud. I still don't understand it.
I'm having trouble imagining your examples. The first one sounds like you did something like
fn([1,2,]
[3,4])
(but presumably longer) and a comma first would fix that (though so would believing jshint or using a debugger :), but a leading semicolon obviously couldn't be used there. I can't picture the second problem, though, at least not in a way that a trailing semicolon wouldn't have fixed.
On the topic of interaction with other developers, this:
> I don't understand why people get so upset about how I write programs
is unfortunate and is probably the biggest problem in this thread (and the previous one). At this point, I've accepted that some people like comma and semicolon first, and if that's the style of a project I'm contributing to, I'll say "this is really dumb" to myself and then write it in that style anyway. It's correct Javascript, and I think plenty of projects are stupidly designed, or inscrutably written, but at some point you suck it up or go elsewhere. It's just a style.
However, there are some red flags in your post that you should think about if you're interested in some dialogue. This is based just on this one post, and I don't think we've ever actually met, so I don't want to go too far here, but statements like
> I realized that there was some essential human weirdness involved here, and it became much too interesting to drop
> Every time I ask people to please not lie about JavaScript to newcomers
> What's wrong with just not lying? I don't get it at all.
> I just ask that they not fill newcomers' heads with lies and fud. I still don't understand it.
sound like pretty classic trolling for the response you're getting. I'm a firm believer in being precise when explaining topics (especially to newcomers), but there's a difference between trying to correct people that are saying incorrect things and trying to provoke a reaction out of them.
(To his credit, Crockford is actually good about saying "this is valid javascript, but it's a developer anti-pattern" and then explaining why he thinks so. I just disagree with about 25% of his anti-patterns and, of course, he's usually kind of a jerk about them)
As I noted in my blog, it's not just (, either. ( is by far the likeliest source of trouble, but / + - [ all can serve as infix operators or prefix operators or (in the case of /) lexical delimiters.
Which is easier to remember, the rules in [2] plus the full "when you must use a semicolon because it is not optional" rule? Or the rules that people who know C, C++ and Java follow?
YMMV, but it's no slam dunk, and going "light" on semi-colons risks disastrous bugs. Going heavy tires out readers a bit with chicken-scratching but carries little risk of adding bugs (the worst case is if(C);T -- oops, and empty statement linting helps).
As usual with programming, there is no substitute for thinking and practicing, learning from the bottom up, and avoiding bad religion.