Hacker News Reader

Comment by mistercow | Hacker News Reader

This seems very likely not to be a programming style choice but some kind of optimization trick by a JS minifier/compiler. I don't think this has anything to do with the typical semicolon war.

View on HN

Well, we do know that the guy at Twitter that works on their bootstrap is anti-semicolon, so I would say its likely both.

And we know, as well, that this so-called-argument is an ad hominem attack and a red herring.

Its also his opinion and the result of decisions made by people who represent twitter.

It’s the result of a bug in Opera’s JavaScript interpreter, parsing a minified file. ☺

I doubt any remnant of a programmer's semicolon preference would make it through a compiler that performs this sort of optimization. The code is likely going to be transformed into an intermediate form (after applying ASI rules) and then that will be transformed into an optimized output.

There was a story here a while back about how the Twitter/Bootstrap developer was arguing with Douglas Crockford about whether or not he should have to insert semicolons. The cause of the argument was the fact that the minifier was changing the meaning of the code, IIRC, by preserving semicolon preference.

Right, but that was JSMin, which is more of a souped-up find and replace, whereas this comma-replacement strategy is what you'd expect from a much more sophisticated compiler which does static analysis and complex code transformations to squeeze out more than you can achieve by simply compacting white space and deleting comments. That level of modification would be crazy and fragile if you were modifying the original source code, so it's a fair bet that ASI is irrelevant by the time you're looking at the compiler output.

When I first had a look at the bootstrap source I was astonished. It seems to be a rather vain thing to do.

What does it gain you?

Purity. Read the issue tracker threads about it, he's militantly against semicolons, even when it's demonstrated to introduce problems with other software (like minifiers).

Update: Here's the thread I was thinking of https://github.com/twitter/bootstrap/issues/3057

Being anti-semicolon in JavaScript is kind of like being anti-parentheses in Lisp.

The automatic semicolon insertion is a "feature" to give some leeway to new/sloppy developers, not a real feature that good developers should use.

The comments on the blog post say it's because of Google Closure Compiler.

And Google has a long history (years!) of making Opera appear as bad as possible. One of the classical things were that they had more sites that declined to work at all but worked with no problem in Opera if you force Opera to report itself as "Firefox."

I bet Google intentionally wrote Closure Compiler to use commas, with the knowledge that Opera has a bug with too many commas, so as to intentionally cause Opera to mess up and look bad.

</sarcasm>

Let me guess, you never used Opera yourself? Otherwise, you wouldn't question the facts, you would have lived them: Google sites intentionally blocked Opera based only on the User agent.

The most recent intentional annoyance is less than two weeks old:

http://www.zdnet.com/google-annoys-opera-users-who-wont-swit...

"(...) it's a mark of pure arrogance from a company that isn't afraid to act like Microsoft (1998) when it needs to muscle out a competitor.

The Google roadblock for Opera is crude. If you change the User-Agent string for Opera so that it identifies itself as Google Chrome, the Blogger editing and management screens work perfectly."

But none of that is relevant because it just isn't very plausible that Google would intentionally exploit a bug this way in their compiler specifically as a way of attacking Opera. They used a valid optimization technique that does save some space, and does conform to the standard. Did they likely test it extensively in Opera? No. But to act like this is an intentional offensive move is conspiracy theory level nonsense.

Please reread this thread: it's documented that they make intentonal offensive moves. They do them openly, nothing hidden. It's sad that such acts are ignored: as the article says, they are as bad as Microsoft in the worst days of anticompetitive behaviour. Check who here tries to hide this by inventing the "conspiracy theories."

I'm not denying that Google has had an antagonistic and underhanded strategy against Opera. What I'm denying is that they intentionally designed their compiler to exploit some obscure corner case in Opera so that very large JS files fail as some master plan to break Twitter on Opera.

It's not that I think Google is above using dirty tactics. It's that I think Google is above using dumb tactics.

I mean, are you seriously suggesting that Google assigned someone to comb through known Opera bugs, looking for one that they could exploit in their compiler while masquerading the exploit as a legitimate optimization? And then they assigned someone to implement that optimization? All in the hopes that someday a 4.5MB JS file would come along and break a popular website under Opera? And ignoring the facts that a) Opera might have fixed the bug by that time, b) said popular website might permanently switch to a different compiler when that happened, and c) it would take the Opera team a small fraction of the time Google had spent on this to put out a patch?

I haven't seen anybody before you in this thread describing the very approach you write about. The answer to your "are you suggesting" is: no, it's you who are suggesting.

My point is, in the light of the all bullying tactics against Opera, the community should definitely have less tolerance to Google than it has. In five words: Monopolies bad, supporting Opera good.

Well that seems like some pretty severe backpedaling, since by bringing up past offensive tactics by Google, it was imminently apparent that you were implying this was another example of an offensive tactic.

But regardless of who is good and who is bad (and trust me, I have plenty of bad feelings toward Google myself), this was fundamentally Opera's mistake, not Google's. There is nothing in the ECMAScript standard that says that there is an upper limit on how long a statement can be, and that's the end of the matter.

It is certainly an another example of an anti-competitive tactic and the most probable scenario they achieved it was by ignoring Opera's existence on as many levels of their organization as possible, otherwise it just wouldn't happen -- if you know your "clever trick" doesn't work on one of the browsers, you wouldn't implement the "clever trick" as an universal solution. As such, it's not an accident, it's a consequence of their political decisions (something like "to all our teams: we don't like Opera, do pretend it doesn't exist, do force their users to switch" etc). It's bad enough, no need for more complex "conspiracies."

It's not a "roadblock for Opera", it's a nag bar that appears for every browser with low market share.

They don't say it doesn't work, they just say they don't support it, so that people won't assume that being broken on Opera means it's broken on every browser. And don't claim that "if they code to standard it'll work" because this very story proves that's not always true.

I do think Opera deserves being supported, and Google shouldn't be pushing Chrome like that. But calling it a "roadblock for Opera" is misleading.

Have you actually read the linked article?

"And you cannot make those nagging messages go away. Any visit to a page in the Blogger content-editing interface results in this nag screen, and although you can dismiss the message, it will keep coming back."

Reply on news.ycombinator.com