Hacker News new | comments | show | ask | jobs | submit login

Heh, I was waiting for this post. Coming in the next 24 hours:

- "Why I use minimal semi-colons in Javascript"

- "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" [1].

I'm confounded that such an attitude can survive in a large engineering organization like Twitter. Google's style guide [2] specifically prohibits this ("Always use semicolons.") and yes, this is the same standard we use internally for writing Javascript.

Just because you can doesn't mean you should. FFS, just get over yourselves and your hipster bullshit and use semi-colons.

[1]: http://twitter.github.com/bootstrap/

[2]: http://google-styleguide.googlecode.com/svn/trunk/javascript...




What surprises me is not that Fat is a bit of a jerk (note, I "get" it, but I don't respect it), but that Twitter lets him keep being a jerk and actively hostile while acting as a representative of the company.

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.

If Douglas Crockford comes down and tells me I'm doing JavaScript wrong, I would hope I'd show a bit more respect to someone who's most likely my better.


What surprises me is not that Fat is a bit of a jerk (note, I "get" it, but I don't respect it), but that Twitter lets him keep being a jerk and actively hostile while acting as a representative of the company.

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?

Being nice also works, but if you compare Chrome's reach to this Javascript framework's reach and use that to scale the number of contributors, you'd expect a lot more contributions to Chrome.

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.


> being hostile is an effective way to lead a large community. 

No, those are the exceptions. Being opinionated and ready to say no, however, is necessary.


Then there's the open source project "leaders" who're nice and smiley to people publicly, but snide and nasty through anonymous backchannels.


> I'm confounded that such an attitude can survive in a large engineering organization like Twitter.

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...


> 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.


Let's not forget... Twitter may have made the hashbang infamous, but it was originally championed by Google [1].

[1]: http://googlewebmastercentral.blogspot.com/2009/10/proposal-...


Page state and uniform resource location, I feel, are utterly different. Hash bang shouldn't be which user's tweets we're looking at, or which article on Gawker.

Google's examples show the hash bang after the query. Twitter put the query after the hash bang.


The GitHub style guide recommends the opposite:

"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 [2]."

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.

[1] https://github.com/styleguide/javascript

[2] http://mislav.uniqpath.com/2010/05/semicolons/


That blog post they cite includes this:

   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.
Unless I'm missing something, that easily qualifies as the dumbest thing I've read on the net in the last week--and I've been to /r/politics.


You're not missing anything. It's dumb. JSLint doesn't find all the bugs in my code, but it does find quite a few. There are several places where I deliberately ignore its recommendations, but all in all I take what it says seriously. I'm sure you do likewise.


[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.


That's the exception to the rule. As long as the exception really is exceptional, it's OK to state the rule in the title.


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)


I find it odd that they (Github) don't really bother to justify their stance on this. The guide just says "don't use them", not why they find it in their interest to do so. It'd be interesting to get a better understanding of why they think this.

Personally I don't see the point in omitting something that leads to known problems instead of including it and encountering zero problems.


Aren't the GitHub team members rather youthful, in general? Skilled, yes, and also opinionated and outspoken. Things might change as they get older and settle into a more balanced lifestyle.


FWIW the GitHub JavaScript style guide also recommends that you don't write JavaScript _at all_, unless you can't help it.


That is what surprised me a lot. That there would be so much defense of the practice. I work on C/C++ for a living in enterprise environment and there are style rules followed diligently. Every one knows that there can be lot of cool/hipster code written with C/C++ but no one does because of the maintenance concerns. Writing code is much easier than maintaining it.


What are the universally accepted style rules for C/C++? Every organization I have worked in has had to develop their own guidelines around style in C/C++.

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.


> What are the universally accepted style rules for C/C++?

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.


The feature in question is intended as an error correction for those cases where the programmer accidentally left out newline. A misguided feature maybe, but it's clearly being abused by intentionally leaving out every (or most) newlines.


> Honestly I'm shocked at the defense of this practice (of ASI "abusage")

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

   return
      {
        ...stuff...
      };
ASI is going to put a semicolon right after the return and break your code.

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.


There will be no issues if you follow JSLint's/Crockford's suggestions. Furthermore, it simplifies the language drastically.

I really don't want to deal with this kind of stuff:

https://github.com/twitter/bootstrap/issues/3057#issuecommen...

(Just like I don't want to deal with those massive ==/!= tables.)


I'm surprised no one has made a little command line tool that follows the rules and automatically inserts semicolons according to the ASI spec.

That might even be useful.


...or perhaps a simple "Zen of Javascript" would be in order.

Reading this "debate" makes me thankful for the Python Community and their stance on "readable code" above all else.


Now that you mention it, every language should have a "Zen" statement, or if you don't want to call it that, a short description of its philosophy. This in addition to the concise problem/solution statement that probably every piece of software should have.


Closure linter's fixjsstyle can do this

https://developers.google.com/closure/utilities/


I really don't understand how a particular usage of semicolons and logical operators is indicative of ego-stroking, showboating, and "hipster", as if the word hipster even means anything at all. If fat _said_ something to make you use those words then that would make sense, but as it is I'm very confused.


Simple. Look at the other comments, and it becomes apparent there are downsides to relying on / abusing ASI, and no advantages. (The only claimed advantage is that the lack of semicolons is visually appealing, but this is nullified by the fact the rules are sort of confusing and not apparent to all contributors.)

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.


FIY the main claim is that it's a more reliable way to write js: programmer mistakes/missing semi-colons are more easily noticed, and much less common, since the rules are simpler. It's there in every debate about this.


I’m sorry, but I don’t know what “FIY” means, what your point is, or how your comment is a reply to mine. Consider re-phrasing?


I misspelled FYI - "for your information". You said there are only downsides, and no advantages; I just told you what the claimed advantage is for "abusing" ASI.

I hope you're not just being snarky.


I wasn’t. Apologies if it seemed mean-spirited — I only wanted to understand your point. I’m probably being thick, but I still don’t quite follow. It seems like you’re saying that if you leave semicolons out (relying on ASI), this makes “mistakes/missing semicolons easier to spot”? That doesn’t make sense to me. :-/


I am currently writing the a style guide (for a small agency), and I have added semi-colons as preferred for JavaScript. And abusing the && operator like in the now infamous code snippet is definitely out.

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
  clearMenus();
  if(isActive) {
    $parent.toggleClass('open');
  }
Once a developer understands ASI and other details he is free to feel elated with his new-found knowledge, but I'd prefer if he choses to know rather than to apply these powers.




Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: