He wrote a blog post about this a while ago, I don't really get his reasoning but I guess he's happy with his decisions:
> Each is perfectly valid. Each behaves the same. It’s just a matter of preference and finding the style that makes most sense to you.
Part of being a good steward to a successful project is realizing that writing code for yourself is a Bad Idea™. If thousands of people are using your code, then write your code for maximum clarity, not your personal preference of how to get clever within the spec.
Code is harder to read than to write. To borrow a line from Jacob Kaplan-Moss, if I write the cleverest code that I am able to, then by definition I won't be able to understand it later.
This semicolon approach isn't invalid, but it is clearly a source of confusion, and it requires that users comprehend the choice and the tradeoffs. This seems like a poor choice for a framework whose audience is largely people who don't grok this stuff and are bolting it on wholesale.
<3 bootstrap, just my $0.02.
Principle of least astonishment (POLA) was also a core design decision behind ruby. http://en.wikipedia.org/wiki/Ruby_(programming_language)#Phi...
In this blog posting Jacob writes:
The majority of lines however don’t end with semicolons because they simply aren’t necessary and I prefer the minimalist aesthetic. For me, \n character is enough and the semicolon character is redundant.
He then points to the izs blog posting about it:
http://blog.izs.me/post/2353458699/an-open-letter-to-javascr...
Jacob calls it more 'minimalist' however it does require you to know (and think about) the rules of when Javascript accepts a newline as a line terminator and when it doesn't. In terms of cognitive minimalism 'semis-everywhere' wins. @izs even acknowledges that part of the advantage is forcing the developer to learn:
To the extent that there is an objectively “better” choice, it appears to me that the minimal-semicolon/comma-first style is slightly superior, both because it is fundamentally more scannable and because it encourages programmers to better understand the language they use.
and later:
If you don’t understand how statements in JavaScript are terminated, then you just don’t know JavaScript very well, and shouldn’t write JavaScript programs professionally without supervision, and you definitely should not tell anyone else how to write their JavaScript programs.
He excludes the possibility that you might understand the rules and still prefer to put them everywhere. So all people who disagree with his choice (which he admitted was only slightly better) tend to get categorized as people who don't understand JavaScript very well and we get a new holy war. The fact that all of the JS noobs are lumped on one side of the argument means it's not cool and we can dismiss a well reasoned opinion as ignorance.
All this being said, I personally don't care strongly one way or the other.
Imagine if a coder wrote a big huffy blog post declaring that he was only going to use single-character variables everywhere because it was more "minimalist" than using descriptive variables. He'd be hanged.
Obviously what "fat" is deciding to do with semicolons is less annoying than the strawman I just made up, but I don't think it's entirely dissimilar. The Javascript spec doesn't say that you must use descriptive variables, and using single character variables is certainly valid. However, it's an established convention that we just don't do that, because people find it irritating.
Basically this just comes down to "plays well with others".
http://bonsaiden.github.com/JavaScript-Garden/#core.semicolo...
var foo = function() {
} // parse error, semicolon expected
test()
var foo = function() {
}; // no error, parser continues
test()JavaScript interpreters insert semicolons. If you abuse this, you'll end up with unpredictable results like his function example.
You might not know that the return statement is a restricted production, but you do know when you shouldn't immediately follow it with a linebreak.
Similarly, if you see a line beginning with ( or [ which isn't a continuation of the statement on the previous line, stick a semicolon in front of it, or in the case of a wrapped function() {}, use one of the other means of telling the parser it's a function expression. There are other restricted productions, but you just solved every non return-followed-by-linebreak ASI issue I've ever seen in the wild.
I'd bet with confidence that 90% of programmers out there don't know if a semicolon is needed after a function declaration. They just put it in there blindly, then some day they find a bug because they "forgot" a semi-colon somewhere.
Indenting isn't necessary either. Less necessary even than semicolons. We do it for a reason. Maintainability, understandability.
The less ambiguity the better.
The only advantage you get is you can see a thread like this and say I DON'T USE SEMICOLONS CUZ I BE SO SMART I GET JS SO GOOD. But you're not coding to work with other people. It helps no one else, it's esoteric and unnecessary.
One should be self-expressive, but I don't think syntax is an opportunity to be so. Regardless of whether it works a certain way, there's very likely an objectively right way for it to be done.
Sure it is. Textual expression is a function of both form (syntax) and content (characters). Not only that, but TMTOWTDI enforces overlap between the right way to do something and the coding preferences of the implementor.