- "ASI is broken but I like it"
Honestly I'm shocked at the defense of this practice (of ASI "abusage"). It speaks loudly to Jacob's (fat@githib) ranking of ego-stroking and showboating over creating readable code, particularly for a library "Designed for everyone, everywhere" .
Just because you can doesn't mean you should. FFS, just get over yourselves and your hipster bullshit and use semi-colons.
If he wrote Bootstrap by himself, he's free to call every single user an idiot if he wishes, but when it's being released as a Twitter product, one would think Twitter would demand some modicum of respect to be shown. Can you imagine a Googler acting this way on the Chromium or Android projects? Yeah, there are decisions made on those where people aren't happy, but the comments aren't laden with zingers either.
My observation of open-source community dynamics tells me that being hostile is an effective way to lead a large community. I've noticed that contributors act more carefully around someone who is mean to people in general and that these people attract wide followings at conferences. (There are certainly exceptions, though, like Larry Wall.)
Can you imagine a Googler acting this way on the Chromium or Android projects?
I think fat is a jackass, but if he wasn't, I never would have heard about this project, which now has multiple front page articles on multiple tech sites. I imagine this is good for Twitter.
No, those are the exceptions. Being opinionated and ready to say no, however, is necessary.
I'm not surprised. A bit disappointed, but not surprised.
Have a look at the original OAuth specification sometime. Note how they misuse the word "key" to mean "identifier". I can't imagine that anyone writing a crypto specification wouldn't know that this would be confusing; I think it's more likely that the person just didn't care. Also, there's the fact that the whole thing could have been written as just a way of getting Basic authentication credentials, rather than making up a whole new authentication scheme.
And then there's the hashbang thing...
Thank you. I agree both of these show a casual disregard for "how the real world works", where not everyone is a "rock star", some are lowest common denominators using the web as best they can (and good for them for even trying!), and some just need to get things done.
Every extra exception you require in a user's mind makes your work and the web in general just that little bit less accessible.
That it is being done for "style" in an arena of notoriously unsophisticated users, really feels like a giant middle finger.
Kudos to Google for their style guide freeing up this particular "exceptions" pigeonhole from a JS programmer's mind, so she can use the synapse to get something done instead.
// Using JS in the real world since Netscape 2.0.
Google's examples show the hash bang after the query. Twitter put the query after the hash bang.
"Do your best to never use a semicolon. This means avoiding them at line breaks and avoiding multi-statement lines. For more info, read Mislav's blog post ."
FWIW, I agree with the Google style guide. Maybe I'm interpreting it wrong, but ASI struck me as a fail-safe to protect coders that forgot the occasional semicolon and was later mis-identified as a feature. Having Brendan Eich weigh in on this is akin to having Thomas Jefferson pop his head into the Ninth Circuit and clarify an issue over Constitutional intent. If it were me, I'd listen to Thomas Jefferson.
My advice on JSLint: don’t use it. Why would
you use it? If you believed that it helps you
have less bugs in your code, here’s a newsflash;
only people can detect and solve software bugs,
not tools. So instead of tools, get more people
to look at your code.
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  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.
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.
Would you admit that at least for me its a YMMV type of thing?
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.
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.
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.
On the topic of interaction with other developers, this:
> I don't understand why people get so upset about how I write programs
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
> 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.
Personally I don't see the point in omitting something that leads to known problems instead of including it and encountering zero problems.
What really surprises me is that such a large number of people are quick to attack someone for writing legal code simply because they disagree with the style used. It feels awfully close to attacking someone for using a different bracing style from your preferred bracing style.
Whenever I've been asked this, I've pointed people at the JSF-AV coding standards or MISRA.
> What really surprises me is that such a large number of people are quick to attack someone for writing legal code simply because they disagree with the style used.
The important part of the lifecycle of a piece of code isn't the writing of it. It's the maintaining and rewriting that matters. If one coding style makes it easier to introduce errors than an alternative, that's a bad thing. It's not an aesthetic concern. Semicolon-less JS is demonstrably less robust.
Devil's advocate here: could one argue that taking advantage of ASI everywhere can make it safer, because it forces you to be fully aware of ASI?
Suppose you always put in semicolons. You can STILL get bitten by ASI. The classic example is
Someone who strives to take advantage of ASI everywhere they can is going to remember that ASI is going to apply on that return, and they will code the above so as to take it into account.
I really don't want to deal with this kind of stuff:
(Just like I don't want to deal with those massive ==/!= tables.)
That might even be useful.
Reading this "debate" makes me thankful for the Python Community and their stance on "readable code" above all else.
Thus people are inferring this fat fellow is doing it only out of illogical, ego-based personal preference, because nothing else makes sense.
I’m not saying they are right — I couldn’t possibly know — but given the facts, it’s a reasonable assumption.
I hope you're not just being snarky.
Our code needs to be maintainable for inexperienced developers. I don't want to make it easier for them to make mistakes and I don't want them to ponder rare (though valid) syntax. I feel this is a valid reason to maintain this rule.
// This we can all understand