Crockford on Bootstrap's semicolon omission: “insanely stupid code”
github.com
github.com
One would hope that at least over time the bike sheds being argued about would start to at least evolve into arguments about bike garages and eventually bike factories. But I guess the bike shed is forever a bike shed, as long as we're making bikes.
Whatever the next disruption is in software engineering, please dear God let it be immune-by-design to this type of distraction.
Your statement thereby makes no sense: this is precisely the kind of argument and conversation--a bug report from a user that itself can be construed as a question about what the purpose of the project is and what parts of the specification it will choose to support--that one would hope the primary maintainer of a project should be "wasting his time" involving himself with.
But any author of a language minification library will have to deal with corner cases. I see no easy way out. Would it be better for Crockford not to have started writing JSMin?
While your sentiment is positive, wouldn't this mean either designing things in a rigid, unambiguous manner (think C's semicolons) or changing human nature? Ambiguous choices plus human nature equals debates. An argument about semicolons does seem silly and your proposed outcome sounds nice, but how could we get there?
Edit: rm js rant
This unfortunate behavior is well described by Wadler's Law:
But it's not just bike-shedding. It's more pernicious than that. It's actually something that looks like bike-shedding to uninformed observers, but something that strongly affects cross-version compatibility. Javascript does automatic semicolon insertion by taking advantage of potentially ambiguous constructs that happen to be resolved in one way right now. But they may be actually ambiguous in the future - in the case where a unary prefix operator becomes a binary operator. Language extension usually works this way: a previously unambiguously wrong statement is made valid; but JS semicolon insertion often turns "wrong" statements into "correct" statements, so it leaves less "entropy" to be taken advantage of when increasing the power of the syntax. I think there's a strong case for JS to not insert semicolons here, and I agree with Crockford's position on not handling it in JSMin. It's the right thing to do.
Here is what I see:
@fat is not inserting "!" needlessly as a statement separator. The "!" is there for its proper purpose, as a "unary not" operation, which will short circuit the second operand of the "&&" when isActive is false.
Given that, @fat has left out a semicolon in a way that is perfectly legitimate based on this language specification, at least as described in the 5.1 version linked from here: http://inimino.org/~inimino/blog/javascript_semicolons).
Could @fat have written the code differently so that he would have been required to include the ";"? Perhaps -- but I don't see why that counterfactual has any particular bearing here.
Crockford's own page on JSMin <http://www.crockford.com/javascript/jsmin.html>; claims: "JSMin is a filter that omits or modifies some characters. This does not change the behavior of the program that it is minifying."
The fact is that @fat's code is legal code and JSMin is breaking it.
IMHO, Crockford is ignoring the technical matters at hand. @fat cannot be faulted for writing code that complies with the specification and for having a reasonable expectation that code minimizers will preserve the semantics of his legal code. Crockford (and others) may wish that the language specification did not include automatic semicolon insertion because it does hamper making changes in the language without breaking existing code -- but that does not make this piece of code "insanely stupid".
Yes, forward progress on the language would be better served if automatic semicolon insertion rules weren't in the specification. However, calling one particular piece of code that leverages those rules "insanely stupid" and refusing to acknowledge that JSMin is in fact breaking the semantics of the code is not productive. Refusing to fix this in JSMin does not somehow make the problem with the specification to go away.
Language lawyering is fine and dandy when you know exactly which compiler will be used and you know exactly how it works.
But on the web that isn't the case. You can write code, but you have no control over what browsers, past, present and future, it will get run on. And it is your responsibility to make that work. According to the spec, you may be right. But in practice you're the one who is wrong, because you're the one whose job it is to make your code work across browsers and future versions of the spec.
That said, it's hard to program to a spec that does not (officially) exist yet, and doubly so if there's not clear "opt-in/out" path for future versions. Since, as a developer, I can't control what the committee adds or removes from the spec, or what they might break, I can only do the best I can with the language as it is -- not breaking existing code in future versions of the language is the committee's job.
Crockford can be an arrogant ass about this stuff, that's why jshint exists, because not agreeing with Crockford does not mean bad JavaScript, no matter what he would have you believe
Arguing about future version of the spec is silly. For all we know the next Javascript spec turns it into a Lisp, and 100% of existing code is broken.
JSMin is breaking working, spec compliant, cross browser compatible code. How is that not broken?
No one won in this situation, but Crockford should know better by now.
Scrolled through, won't participate. I'd much rather build interesting application.
People tend to have pretty stiff sticks up their arses in such discussions.
Humor, even toilet humor, can remove fear and remind everyone that a debate over a semicolon is not necessarily a life/death situation.
It's like someone yelling and acting up when other people are talking about something important to them, just because that person is bored and doesn't care about the topic.
If you are bored, go somewhere else.
And the net result _every_ single time is that the bug gets locked so no one can post to it. Sometimes they unlock it again after the reddit idiots have left.
I subscribe to quite a few programming related subreddits and while the comments there are more informal (people can make a joke without getting downvoted, for instance) the level of the discussion you're referring to is not very representative of programming subreddits either.
The disturbing thing is the idiot arguing about implicit semicolons in a language with not good support for them, in a general use library.
The time is ripe for Dart!
edit: now that I said that, it makes a lot of sense.
The sad thing is that apparently some programmers take this stuff so seriously that they refuse to learn a language that wont let them use their pet brace style or whatever. I wonder how they collaborate with other programmers or if they would reject a job offer from a company that used the wrong coding style.
P.S.: Also Go's syntax manages to keep code semicolon-free while avoiding the pitfalls of JavaScript.
"Here is a feature. Don't ever use it. Here is a simple way to do this. This way is dumb, use a 2321 line library instead. There is nothing wrong with X, you just chose one of the 60 wrong ways of using it."
I don't want to think about this kind of stuff, I have enough to worry about as it is. JavaScript is all right as a language of the present, but I really don't want it to be "the future", like many people paint it to be.
Someone like Crockford with his 'years of experience' opening the debate by saying this kid's code is 'insanely stupid' is the real disappointment for me here.
Not to mention the memes and pictures being posted further down in the thread. I hope it's a matter of time before github comes up with a way to flag these.
1. I'm going to use three semicolons for every one Fat doesn't use, the arrogant twat! ;-)
2. Bike shed.
3. Some of these arguments actually kind of make sense... I Prefer the semicolonlessness of Python as well. But even though I know the ASI rules, I don't want to spend the mental effort to check every line for unwanted continuation.
4. And then someone linked to http://npmjs.org/doc/coding-style.html#Semicolons which is a style that has marginally more semicolons than Fat would (apparently) use, but I can use this pretty much without thinking.
I might give it a go. See how it feels. It's important to not stick to old conventions just because KIDS THESE DAYS.
If you never hear from me again, it's because I've drowned in an ocean of obscure bugs.
Crockford is an idiot for writing an JS minifier which explicitly promises to not break legal code but actually does, and then refusing to fix it because he's proud of his reputation for being an asshole.
And everyone commenting on this post is an idiot for thinking that any of this is worth the pixels it takes to argue about it. And yes, that includes me.
sigh This whole thing just makes my head hurt.
The comment section disagrees with you. He's just writing his damn code the way he wants to, which a large number of people seem to care about.
- is incompatible with existing tools
- is incompatible in places with upcoming versions of JavaScript
- is harder to refactor, since you might need to add additional tokens to the beginning of lines depending on the previous lines
- is confusing to new JavaScript programmers, since
+ it goes against the recommendations of many of the most popular books
+ it requires adding tokens to the _beginning_ of lines in places, making the entire enterprise more challenging to learn and of dubious utility
+ it discards one of the attractive qualities of JavaScript for programmers of other languages: familiar syntax
!somethingHappened && otherwiseDo(x)
if (!somethingHappened) {
otherwiseDo(x)
}
"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" - Brian Kernighan, "The Elements of Programming Style"
Although everyone has the right to maintain their projects with whichever style they prefer, given the above, I wonder why the chosen style was chosen.
somethingHappened or otherwiseDo(x)
Edit: Just for amusement it would probably be:
somethingHappened not { x otherwiseDo } if
open FILE, "filename.txt" or die
The semicolon wars frustrate me. We have an arbiter of what's correct/valid syntax and what isn't. It's the freaking lexer, heaping additional prescriptivism on top for something as trivial as semicolons is irritating. If your code has ambiguity problems, fix it by writing unambiguous code. Semicolons are not the only way.
It doesn't take a lot more effort to rephrase fat's response to be more cordial.
"Hi @englishextra, those two lines are valid JavaScript. We try not to use semicolons whey they aren't necessary. See (insert link to the wiki).
"JSMin doesn't perform well on bits of JS like this. Maybe you can discuss it with @douglascrockford ?"
Ideally, your goal as a hacker is to make cool shit. Your goal is not syntax.
Simplicity should win; but alas, being one of the cool kids is more important.
The bootstrap code makes assumptions about the future of the js spec and browser implementations that aren't safe. Young people don't remember the dark days of people writing js to leverage IE/Netscape specific bugs which then had to be turned into features because so much code existed in the wild that could be broken.
Crockford is a scarred veteran of the spec wars. I'm sure that when he sees young people trying to game spec/implementation ambiguities, he thinks, "Never again! Not on my watch!"
I think best practice is explicit, future-proofed code that doesn't tie the hands of spec authors or browser vendors. I know that Crockford's tool doesn't accept the current spec or browser behaviour, but his choice is informed by past experience and concern for the future. It's not just some random bug that he's too stupid or stubborn to fix.
Here is what I understand:
1. Javascript will add a phantom semicolon at the end of each line if it seems like you need it, for some definition of seems like. To me, it sounds like this is so that new HTML writers in '98 wouldn't see their pages blow up when they forgot a semicolon at the end of a script. It doesn't sound like professional programmers are expected to leave semicolons out on purpose (this is the opposite from python). The bootstrap authors took advantage of this because somehow screwing with the compiler is in vogue.
2. Crockford's tool broke when a semicolon was left out somewhere. I guess he didn't implement a proper js compiler that covers the entire language spec.
3. There's some business about unary and binary ! operators? Something about sticking a ! in front of your line lets you leave the semicolon off the end? This sounds utterly braindead to me. It's no fewer characters, and the thing you're typing is going really far away (at the beginning of a big block of code) from where it's actually meaningful to you (at the end). Also, it looks like it relies on some fairly convoluted unintended consequences of the spec, that may not be future-proof.
Here is my analysis, if the above understanding is true:
1. Bootstrap needs to fix their code. This business of the compiler sticking in semicolons where it thought you meant them is a crutch to prevent stupid errors from being fatal errors in the average case, but that doesn't mean they aren't errors. Be explicit.
2. Crockford should fix his tool soon, not complain about other people's code, and say "I'll fix it soon, but for now, here's a workaround: just put a semicolon in your code".
3. What the hell. Are people really doing this? Is the web one big obfuscated javascript competition? What happened to writing simple, explicit, readable, maintainable code? Are we really bickering over single characters and trying to play subtle tricks with language esoterica to save them like a bunch of 14-year old perl newbies? Man, I hope these morons aren't in charge of my bank account.
Overall, I'm with Crockford, but he doesn't need to be this much of a jerk about it.
Further analysis, now that I've read it with a decent (non-cell) data connection: allowing gifs in a public issue tracker is a terrible decision.
a = b
++c
a = b;
++c;
a = b++;
c;
I believe the issue with the bang (!) operator is that it's being considered as a binding de-reference of function objects. See here: https://mail.mozilla.org/pipermail/es-discuss/2010-July/0114...
Therefore, the problem with the code would be that an automatic semi-colon would not be inserted and the code, which is currently:
clearMenus()
!isActive && $parent.toggleClass('open')
clearMenus()!isActive && $parent.toggleClass('open');
clearMenus();
!isActive && $parent.toggleClass('open');
That is a pretty good rundown of the rules. The only problem with not having semicolons is cases like this, where someone is using a bad tool to minify your code. None of the tools that currently do the best job will break on that code.
But I still don't understand why the hell you would want to do this. These are a lot of rules to remember, and I don't think it makes sense to think about them for each statement I write. Nothing here says "here is what you gain with this technique", all I see is "it's perfectly valid so quit whining". This doesn't satisfy my curiosity.
Then we have this:
For example, instead of this:
foo();
[1,2,3].forEach(bar);
foo()
;[1,2,3].forEach(bar)
So now the argument is "don't worry, you get used to writing stupid looking code"? This is getting depressing.
putting a semicolon at the end of every line is basically just noise. You get used to it, and I find semi-colon bugs end up happening much more frequently. More then that, you are essentially just typing an arbitrary character 99.99999% of the time. When you need a semi colon is essentially a corner case, so the vast majority of code is just getting appended with a character which has no meaning.
Its like the javascript community decided to surround all expressions with parens, since it makes things more explicit, and there are a few cases (much more common then semi colons) where you need it in the language. Or if they decided to end all lines with //, just in case someone wanted to follow it with a comment. Those two examples make as much sense as advocating semicolons at the end of each line.
What's not fine is pretending like javascript has significant whitespace and then...oops! it doesn't work here so we need to add something in this one special case. That is guaranteed confusion. If your only argument is that most of the time it's unnecessary, all you're really trying to accomplish is compression (guess what, JSMin does that!) and you may as well write APL. "You get used to it" is meaningless. You get used to banging your head against a wall too, if you do it long enough. Doesn't mean it's a good idea. It's actually worse than that though, because other people need to get used to it too, so you're wasting their time as well.
Surrounding all expressions (not statements) with parens does make sense, in many languages (because there are cases where you need them, and it pays to be explicit up front). That is something good style guides often dictate (like surrounding all if/else blocks with braces, even if they're only one line). Starting a comment after every line doesn't seem like a good analogy, I have no idea where you're going with that.
Let me be clear, and I've now wasted a bunch of time reading up on this so it's not just opinion: ASI is a crutch added to the language in order to minimize the effect of silly errors. It is not a language feature. Python was designed to have significant newlines, and they resolved the ambiguous cases. Javascript was designed to have semicolons between statements when written correctly. Abusing ASI is error-prone and not future-proof (against programmers, apparently language spec changes are going to maintain current behavior). If you think its abuse is a good idea, you should be quarantined from the rest of the programming community. Or write your own language and design it around this.
If you were to write ruby, smalltalk, perl, google go, python, coffeescript or any of the other languages with asi, you find that people omit the semicolons in every situation unless for the few they need them, and never run into a problem. For some reason, that is not the case with js. Do all of those other languages "abuse" ASI? I work on a 500k loc ruby app, and I feel very confident in saying there has never been a single case of a bug from an ambiguous statement from asi (although there have been from the difference of && and 'and'), and there is only about 5 semi colons in the whole code base.
Now, js is different then those other languages in that it has a quirk where it treats whitespace and newlines the same for all types of brackets. Realistically (if you are writing for the browser), this only comes up in lines starting with an open parenthesis, since that is the one case where starting a new statement on a line with any kind of bracket makes sense. And even then, the one time you are likely to be doing that is for an immediately invoking function (function(){}()), which isn't exactly you do every few lines of code. So you have a choice on how to deal with this one, fairly uncommon case; either handle it in a special fashion when it occurs, or put a semi colon on every other line. I don't care which one you choose, all I ask is you afford me the same respect :)
My intent isn't to get into a silly language argument over this, but it seemed like you genuinely missed what I was trying to say. If you feel it would personally help you write better code, then more power to you. But I write a lot of semi-colonless code in various languages, and it has literally never caused a problem for me.
Ruby, python, and coffeescript were designed with significant newlines, and therefore designed around the corner cases. The only reason you'll need semicolons in those languages is to have two statements on the same line (coffeescript excepted, I'm not sure about it but my guess is that they did it right). These languages went to great lengths to reduce the cases where you need statement separators, and document this behavior widely and clearly. Perl requires semicolons, dunno where you got the idea it didn't. I don't know about smalltalk and go, I don't use them.
I probably did miss what you were trying to say.
In languages that weren't designed with significant newlines, everybody uses the statement separator at the end of a line, so it seems to me that moving them to the beginning of lines is just confusing. In any case, ASI is not significant newlines, it's a hack. I don't know what more to do than to just beat it into your head. It is not a feature you should rely on.
The important part of what I'm trying to express is that, in any language, the most important thing you need to do is to write explicit code. This means typing all the characters so that not only does the compiler (and tools) not get confused, but future human readers don't get confused either. Javascript intends for you to separate your statements with semicolons. If you start playing tricks with them, you are going to confuse people that try to understand (or, heavens, learn from) your code. You will get burned.
Consider this example (I'm a C guy):
if (a && b || c && d | e || f && g)
if ((a && b) || (c && (d | e)) || (f && g))
The same applies for ASI. If you rely on extra compiler tricks a human needs to remember, that's expensive. It is a lot better to have a simpler rule: just put a semicolon after every statement, and don't make anyone think about it again. Or put one before, I don't really care. Just do something consistent. Try to code to a simpler subset of the language, to make other programmers' lives easier.
I really don't mean this to be an attack against you or the javascript community. Well, I sort of do, because abusing ASI is stupid, but I actually mean this to be an educational experience. Let me help you mature as a programmer.
fwiw, this was patched in bootstrap way before i even encountered this issue - otherwise i wouldn't have closed it outright.
Sorry for the confusion everyone.
You can see the code here in 2.0.3: https://github.com/twitter/bootstrap/blob/2.0.3-wip/js/boots...
I still maintain this is a bug in jsmin, but as others have pointed out - mark and I do our best to make bootstrap flexible with other great tools out there (like jsmin). This includes adding semicolons where necessary or changing minor stylistic things.
But... Crockford could have said it in a much more tactful way that could elicit a more positive response, spare the world from this sad discussion, as well as channel the man-hours dedicated to this into more useful endeavors.
And if you don't use semicolons you are an asshole.
Which is why there is a line break there. He's far too stubborn to realize that JSMin is at fault for not being able to correctly parse JavaScript.
Ironically, the Zen of Python supports using semicolons in JavaScript. Also, both sides come off like children, but at least Crockford's opinion seems a little less selfish. It's like politics, with the difference being in their premises so they'll never agree.
Also, why can't I (or anyone else) resist commenting on this rather pointless debate? I am disappointed in my weakness.
I wish we could get some other programming language implemented in all the major browsers, then at least in the perspective of the next 10 years we could completely get rid of JavaScript, I am not sure if it possible to really improve the situation in a radical way just via incremental changes to the existing design.
alert(1) // add semi-colon here to make this code work
(function(){alert(2)})() alert(1)
void function(){alert(2)}()What would be better is for both sides to fix their code: Crockford to fix minify for the edge cases like this (result: better, more robust code equals a win), and the twitter boys to add a semicolon for these edge cases (result: better, more robust code equals a win).
But instead, as usual on the internet, it's just devolving into lots of "waah waah waah".
Seems like people are valuing aesthetics over producing code that works for 100% of the users/situations.
https://github.com/twitter/bootstrap/blob/master/js/bootstra...
https://github.com/twitter/bootstrap/blob/master/js/bootstra...
(Incidentally, would lines 54/56 of bootstrap-modal suffer from the same problem? Or does the fact that the last function call on line 54 is already in an && expression change things)
I'm kind of surprised that the bug wasn't fixed by changing the line to `isActive || $parent.toggleClass('open')` as is done here https://github.com/twitter/bootstrap/blob/master/js/bootstra...
That's insane. Good programmers need not know stupid tiny nits about Javascript (heck, I've worked on a Javascript JIT and I don't really know Javascript). That does not mean that they are not skilled.
> aesthetic
I don't understand how "you must carefully understand how the language parses to understand this line of code" is aesthetically pleasing when compared to unambiguity.
> minimalism
Here, it is needed, at least arguably (by douglascrawford). You could argue that the "optional semicolons" rule is ugly and not minimalistic, and thus the minimalistic approach would be to not use that rule.
In this case, the minifier is breaking the code, regardless.
a && b && c || d || e + f > g && h
It's true that the semicolon is not needed, and it's true that the minifier is breaking code. It may even be true that Crockford should fix it. But that doesn't change the fact that the omit-the-semicolons position is absurdly immature hipster posturing that serves no engineering purpose.
Great idea! I propose some additional strategies for pruning the contributor pool:
- All numbers in hexadecimal (every idiot knows decimal!)
- No strict equality tests (too easy to reason about & uses extra character!)
- Variable names must consist entirely of unicode ideographs (even my grandmother knows ASCII!)
That should keep the idiots at bay!
Besides, I'm not willing to acknowledge any reasons for using semi-colons as significant. And without any significant reasons for it, I may as well not use them. Besides, it makes the code prettier :).
1 + 2 * 3
1 + (2 * 3)
Similarly, using semicolons to end lines means I am saying loud and clear... this line of code ends HERE.
Obviousness is a good thing, no?
var value = x + fn
(y).burp()
If your code is in no-semi-colon style, there is no ambiguity, you can be 100% sure that this is a mistake: there always should be a semi-colon guarding that parenthesis, regardless of intent:
var value = x + fn
;(y).burp()
How many JS programmers know the difference between a function expression or declaration, and the semi-colon that should follow or not? You're dependent on a linter. Following the no-semi-colon rules makes your intentions clear in every case, without machine validation.
I think Ricardo's point is that this style (having a semi-colon only before parentheses at the beginning of the line) makes your intentions more explicit.
Sounds like a viable strategy - but you have to parse where every statement ends in your head. The situations where you don't end a line with a semi-colon are more numerous than the rules you need to write semi-colon-free code. Besides, if it's so simple, why not leave it to the interpreter?
I'd love to leave it to the interpreter, but the interpreter doesn't put a semicolon at the end of every statement for me, as I write them naturally. It puts a semicolon at the end of... most statements.
destPoint.x + offset.x * diameter
destPoint.x + (offset.x * diameter)
This whole thread is arguing about style, IMO. I'm just offering my explanation why this style makes more sense to me.
So I actually think that 1 + 2 * 3 is better than 1 + (2 * 3). I usually find reading a line with less stuff easier, so I prefer the shorter between two equivalent expression.
Besides, adding a semi-colon is more like surrounding the whole expression with parentheses rather than just grouping. And you would never write (1 + (2 * 3)). And yet that also says, loud and clear, the same thing!
I've used some languages with optional semi-colons--Python and Haskell, for example. I've never thought that missing them made the code less readable--it's always been the opposite. Going back to Java and having to use semi-colons everywhere becomes increasing annoying as I grow more acclimated to languages without.
In short, I see where you're coming from but don't really agree.
>>>
@douglascrockford If TC-39 makes ! an infix operator, which causes \n to not terminate the statement, then that will be a syntax change that is incompatible with current code in the wild, which would be an insanely stupid move on their part.
The fact of the matter is that JSMin isn't parsing JavaScript correctly. I thought the separation of concerns was that JSLint tells you about stupid code, and JSMin correctly parses JavaScript according to the ES standard and minifies it safely.
>>>
Regardless of our many diverse opinions, Crockford and Fat are entitled to maintain their own libraries in whatever fashion they desire. The fact that they made the libraries open source means "if you don't like my code or the way it works, here's my code, customize it and leave me alone".
My point is that its stupid to use a tool on code it was not written to support. If you want minification with valid JavaScript, use something like Uglify-js.
If you write code, however, that works with JSMin, then use that tool. Douglass Crockford can write his software to work any way he likes and support any code he likes. Don't like it? Use something else, and don't be stupid.
My vote: Good practice
Upvote replies to vote. Please don't down vote the replies so we get a clear picture.
Its like the golden rule for software. It generally stops nonsense like this cold.
Imagine if invalid HTML had been flat-out rejected by browsers since the beginning. Cross-browser compat would be, at least, somewhat easier due to less bad HTML surviving in the wild, since it simply would not have worked. In XML, for instance, I've never heard of the need to deal with invalidly formatted messages.
There's enough problems interpreting semantics, why do folks want to add syntax to the problem, too?
1) JSmin should be modified to handle Bootstrap-style semi-colon-ing
2) Bootstrap should adopt the more commonly understood semi-colon-ing
Sounds like another emotional issue.
Get over it...
And I think Google's style guide[1] is prevail over Github's style guide[2].
[1] http://google-styleguide.googlecode.com/svn/trunk/javascript... [2] https://github.com/styleguide/javascript
Are there compressors that use the syntax tree rather than transforming the source?
Personally, I agree with Crockford -- it's dumb.
The lack of semicolons is the one major thing in the Github style guide that I think is stupid. It seems silly to avoid using semicolons in Javascript because it actually takes a little bit more effort than just using them.
CoffeeScript removes semicolons from CoffeeScript, not JavaScript.
If they were never needed I'd understand, but sometimes they are. I don't see the point in forcing the developer to make a conscious decision on whether to include a semicolon.
Omitting semicolons also means that the correctness of a line of code is determined by the unrelated lines that follow.
They just disagree on whether a semicolon gets inserted here.
I used to prefer having semicolons in my javascript, then I started writing a bunch of Go. Now I wind up forgetting sometimes, though some part of me likes it, and so I continue using semicolons in my javascript.
That having been said, I think it's a matter of personal opinion (likely just what a given person is used to), and if it fits with the spec and the common usage, then you'd think a library that is expected to work with/on other libraries would try to be accommodating.
edit: To further clarify, Javascript's stance is silly, because you need to know how semicolon insertion works. It's extra knowledge you have to have. Thus, I think I agree with most here that it's easier to just use them. (Other languages have optional semicolons but they don't change the meaning of the syntax at all.)
edit2: This is GitHub, why is there not a fork already with this issue behind us?
Grow up Crockford. Do research before you post. Stop assuming because you supposedly once knew how to do something, you still do, and always will. Times change.
However, this is all very exciting. It gives Twitter, or whatever other start up, an opportunity to replace an outdated piece of software by a nut case!
> It gives Twitter, or whatever other start up, an opportunity to replace an outdated piece of software by a nut case!
I don't know where this ad-hominem is coming from, but Douglas Crockford is hardly a nutcase.
If people hate semi-colons with such a passion, why not simply use coffeescript and be done with it instead of depending on butterflies flapping their wings...