
Crockford on Bootstrap's semicolon omission: “insanely stupid code” - sferik
https://github.com/twitter/bootstrap/issues/3057
======
gfodor
There's something horribly wrong with everything about this. Why is such a
smart person as Crockford wasting his time arguing about semicolons in 2012?
Why is this at the top of the most popular hacker website? Why are people
writing detailed opinions about semicolons in this thread (with surely more to
come?)

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.

~~~
barrkel
Jacob ("fat") comes off looking far worse than Crockford, to my eyes (and that
Kit character seems to be 7 years old). It's the arrogance and stupidity of
youth facing the crotchety crankiness of experience. Crockford has earned the
right to have a strong opinion here IMO.

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.

~~~
chad_walters
I have never written a line of JS in my life, which hopefully qualifies me as
an unbiased outsider, but I don't agree that that Crockford's position here on
JSMin is 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>](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.

~~~
btilly
Here is what you're missing.

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.

~~~
mattbriggs
Crockford is releasing a tool which is compatible with his opinions, not with
JavaScript. All browsers execute that code fine, present and past, and at
least for the next decade or so.

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

~~~
pronik
It's about JSMin, not JSLint. Crockford has actually several products ;-) And
JSMin is IMHO not really opinionated.

------
Lazare
Jacob is an idiot for writing code with a ridiculous fragile syntax that takes
_more effort to write_ in a vain effort to obtain "coolness" via winning a
pointless language war that nobody on earth cares about.

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.

~~~
Deestan
> a pointless language war that nobody on earth cares about.

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.

------
dhconnelly
I'm new to JavaScript, but from what I can tell, the no-semicolons style

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

And further, the use of constructs like

    
    
        !somethingHappened && otherwiseDo(x)
    

instead of

    
    
        if (!somethingHappened) {
            otherwiseDo(x)
        }
    

is bad practice in any language.

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

~~~
arethuza
Actually constructs like:

    
    
        somethingHappened or otherwiseDo(x)
    

used to be idiomatic perl (and might well still be for all I know).

Edit: Just for amusement it would probably be:

    
    
        somethingHappened not { x otherwiseDo } if
    

in PostScript

~~~
knowtheory
And would allow for constructions like

    
    
      open FILE, "filename.txt" or die
    

Which is nice enough to read (and can be seen in actual examples around the
web: <http://www.perlfect.com/articles/perlfile.shtml> )

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.

------
chrisguitarguy
Frankly this is less about semicolons and more about two people who both have
strong opinions and feel that they need to act in a certain 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 ?"
    

Flamewar avoided (probably) and more stuff getting done.

~~~
jimmyjazz14
I agree. The real problem here is the complete lack of courtesy from either
party. Software developers seem to have problems with this, maybe because we
spend so much time commanding machines to do things with brief statements
without the even the least bit of a please or thank you.

------
rocktronica
Learning the minutiae of a language is important, sure, but I can't fathom why
you'd willingly introduce unnecessary fragility or overthink into your
codebase.

Ideally, your goal as a hacker is to make cool shit. Your goal is not syntax.

~~~
ajacksified
This is precisely correct. "Don't do _x_ , except in one or two cases where
you have to, and then you can hack around it using _y_ instead of _x_ " -
rather than "use _x_ by default."

Simplicity should win; but alas, being one of the cool kids is more important.

------
celticjames
I think older programmers will side with Crockford and for good reason.

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.

------
jrockway
Ah, I'm so glad that Github allows animations in pull request comments. They
really increase the level of discourse!

~~~
thealphanerd
popcorn.gif

------
leif
I am not experienced with javascript, so I don't understand this argument. Can
someone please confirm the following, or explain what's going on?

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.

~~~
mattbriggs
[http://blog.izs.me/post/2353458699/an-open-letter-to-
javascr...](http://blog.izs.me/post/2353458699/an-open-letter-to-javascript-
leaders-regarding)

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.

~~~
leif
Yes, tool writers need to understand this behavior and handle it.

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);
    

_you could do this:_

    
    
        foo()
        ;[1,2,3].forEach(bar)
    

_The advantage is that the prefixes are easier to notice, once you are
accustomed to never seeing lines starting with ( or [ without semis._

So now the argument is "don't worry, you get used to writing stupid looking
code"? This is getting depressing.

~~~
mattbriggs
starting a line with a semicolon means "start a new expression", if it is done
where it is meaningful. By putting it at the start of the line, it is easier
to associate it with the statement that makes the character important, and
calls out that you are paying attention to one of the biggest gotchas in the
language

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.

~~~
leif
No. Semicolons are statement separators. Every other language that uses them
as such puts them at the end of every expression, but it's fine if you want to
put a semicolon at the beginning of every expression instead, except that that
will confuse people coming from other languages.

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.

~~~
mattbriggs
My argument is that ending every line with // is just noise, () is just noise,
and ; is just noise, except for the one in 1000loc time that it isn't. And
filling your code with noise not only makes your code harder to read and
longer to type (if even by a little bit), but it trains you to ignore semi-
colons, especially since you do not have a compiler complaining when you miss
them. And when semi-colons fade into the background, it is MUCH harder to
catch the one case where they are important.

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.

~~~
leif
Ending every line with // is noise because it means nothing to the compiler or
to the human. If I could write comments without prefixing them with //, I
would (but the compiler won't let me). () and ; are not noise because they
simplify the rules of the language. They make it so someone reading your code
needs to remember fewer esoteric rules to understand it. That is a big win.
Saving a single character of typing per line, for your fingers and your disk,
is a miniscule win. I hope you're writing code that's more interesting than a
typing contest (but if you aren't, maybe you care about the semicolons). The
disk and the network don't care about one more semicolon per expression. They
know about compression, they will deal with it. If your compiler doesn't
complain when you miss them, you need a better compiler. Maybe a linter, or
google's closure. Or maybe there's a market for a decent javascript compiler.
I don't understand what you mean by "when semi-colons fade into the
background, it is MUCH harder to catch the one case where they are important".
If you use them everywhere and you miss one, it's easy to spot. If you have to
examine each line with a set of rules in order to figure out if you actually
needed one there, that's a more expensive task.

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)
    

How does this resolve? Does it help you if I write this?

    
    
        if ((a && b) || (c && (d | e)) || (f && g))
    

It sure as hell does. Now, these are semantically identical. But when you read
the second one, you don't need to know that bitwise OR binds tighter than
logical AND, and logical AND binds tighter than logical OR. These are details
you _should not need to remember_ when you read my code. Are parentheses just
line noise here? I think not. I think they are quite meaningful. Not to the
compiler, but to the human consumers of my code. It's costs the reader a lot
more to read the first one than the second. The first one is mentally
_expensive_. (In fact, modern C compilers will warn you about not having these
parens here because they know that adding them is a good idea. If you turn on
warnings.)

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.

------
dantillberg
I wonder if the "insanely stupid" comment isn't about the omission of the
semicolon but about the omission of "if". Since when is a good old-fashioned
if-statement out of style?

------
ricardobeat
It _is_ a bug on JSMin. Minifying should _never_ alter code behaviour.

~~~
abraham
The minification isn't breaking the code. The authors had an incorrect
expectation of how JSMin would minify the code. By the very act of minifying
code where new lines matter your are always potentially changing the behavior.

~~~
mistercow
The minification _is_ breaking the code. If a minifier takes valid JS in and
produces JS that behaves differently from the input, then that minifier is
broken, full stop. It doesn't matter how anyone personally feels about ASI;
what matters is that ASI is a part of JS, so if you're making a tool that
processes JS, you need to respect its rules.

------
wpietri
Update: Bootstrap fixed their code as Crockford prefers. From _fat_ 's comment
circa 11 am PDT:

 _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...](https://github.com/twitter/bootstrap/blob/2.0.3-wip/js/bootstrap-
dropdown.js#L63)

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

------
rbanffy
I happen to agree with Crockford on the omission of semicolons. I also have a
strong opinion on clever code: you should always optimize for readability over
aesthetics.

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.

------
ronaldj
That code is bad for more reasons than the semicolon omission.

------
greghinch
While this "argument" has prompted several lol's on my part, JS really needs
some equivalent of PEP8

And if you don't use semicolons you are an asshole.

~~~
simonw
Douglas Crockford's JSlint is pretty much that.

------
Sephr
> _! is not intended to be a statement separator. ; is._

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.

~~~
jpeterson
The line break will not help if ! becomes an infix operator.

~~~
jurre
But as of now it's not.

~~~
erichocean
! is already being discussed to be turned into an infix operator in a future
version of JavaScript.

~~~
Sivart13
Future versions of JavaScript might also replace the 'function' keyword with a
picture of a chicken, but I'm still going to keep typing the word 'function'
for now.

~~~
tghw
That's not under active discussion. ! as an infix is.

------
alecperkins
“…Explicit is better than implicit… Readability counts… In the face of
ambiguity, refuse the temptation to guess. There should be one—and preferably
only one—obvious way to do it…” — The Zen of Python

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.

------
stiff
It is hard for me to understand how one could make so many things in a
programming language completely arbitrary - I mean it is natural for a
language designer to have some vision of how the language will be used by
other people, how will the common structure of the programs look like, but
JavaScript looks like such a vision never existed, there are often several
ways of doing the most basic things (writing vs. omitting semicolons mentioned
here, writing vs. omitting "var", but above all else 1000 of ways of doing OO,
all with it's own problems) and no easy ways at all of doing other very basic
things (modules/namespacing). As a result you can find 10 or 20 programs
written in JavaScript where each looks like it was written in a quite
different language. Maybe it was an attempt to make an "easy" language for
non-programmers (I doubt even this goal was in the end achieved), but as a
primary language for programming client-side applications it is a utter
disappointment. Not that I necessarily blame the JavaScript creator, I am sure
there were plenty of corporate pressures involved and other factors of
corporate/economic nature.

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.

------
kellysutton
Crockford wrote JavaScript: The Good Parts. He did not write JavaScript: The
Cool Parts.

------
magicalist
if there's anything worse than crockford being a jerk, it's the self-
aggrandizing asi crowd. Let's not give either any attention.

~~~
joshu
(what is an asi crowd?)

~~~
ben0x539
Gonna guess "asi" means "automatic semicolon insertion".

~~~
skore
In German slang, "Asi" is shorthand for "Asocial person". Guess it works on
many levels?

------
sferik
For a good explanation of why it's a good idea to always use semicolons in
your JavaScript, take a look at: [http://lucumr.pocoo.org/2011/2/6/automatic-
semicolon-inserti...](http://lucumr.pocoo.org/2011/2/6/automatic-semicolon-
insertion/)

~~~
ricardobeat
The examples he gives are exactly the situations where you _should_ use semi-
colons, as understood by those who skip them. Take a look at
[http://blog.izs.me/post/2353458699/an-open-letter-to-
javascr...](http://blog.izs.me/post/2353458699/an-open-letter-to-javascript-
leaders-regarding)

------
meric
Example when a semicolon is _required_ in non-minimized javascript.

    
    
        alert(1) // add semi-colon here to make this code work
        (function(){alert(2)})()

~~~
insin
There are other options here too but, given the OP, people seem to get irate
when you use the features the language specification guarantees :'/

    
    
      alert(1)
      void function(){alert(2)}()

~~~
meric
Nice, didn't know void can be prepended to a function definition.

------
rasur
Excellent - another internet cock-fight, with both sides managing to act like
total cocks..

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

~~~
TazeTSchnitzel
Crockford won't "fix" minify, because it's much easier to make JSMin work for
a safe subset of JS than it is to make it work for all of JS.

------
jcoffey
What is insanely stupid is abusing the logical bitwise && operator rather than
signifying their intent using a plain old if statement like the language
intended.

------
joshontheweb
I'm sure this thread is going to be a good, old fashioned flame war. Let the
games begin.

~~~
Jimmie
My favourite part is half-time, when the flame-war overseer yells "Change
Places!" and everyone has to argue for the other side.

------
brown9-2
For those that agree with leaving semi-colons out of JavaScript that they
write for projects, can you explain what the benefit of doing so actually is?

Seems like people are valuing aesthetics over producing code that works for
100% of the users/situations.

~~~
ceol
You will never produce code that works for 100% of users and situations.

~~~
slantyyz
Also: You can write clean bug-free code, but there will still be at least one
person on the planet who think your code sucks.

------
Yarnage
I agree with Crockford.

------
_rknLA
Why is this discussion about semi-colon insertion and not about the use of
short-circuiting as a replacement for specific 'if' statements and general
inconsistency in the project?

[https://github.com/twitter/bootstrap/blob/master/js/bootstra...](https://github.com/twitter/bootstrap/blob/master/js/bootstrap-
carousel.js#L91)

[https://github.com/twitter/bootstrap/blob/master/js/bootstra...](https://github.com/twitter/bootstrap/blob/master/js/bootstrap-
modal.js#L61)

(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...](https://github.com/twitter/bootstrap/blob/master/js/bootstrap-
alert.js#L52)

------
gorm
The use of semicolon as best practice was sorted out years ago in the js
community. Crockford has all his rights to tell these guys to sharpen up
because that "fat" character is obviously a python smuch with no knowledge of
JS history or respect for elders.

------
smhinsey
Funny, I was just checking out Derby and noticed that their examples follow
this style.

~~~
felipe_csl
Why the hell people are refusing to use semicolons? I don't get it

~~~
Groxx
I've seen a few reasons. The main ones I encounter are: raising the skill
requirement to contribute (you have to know JS better than average to never
use a semicolon, and do so correctly), aesthetic (fewer characters looks
better), and minimalism (don't use what you don't need).

~~~
rpearl
> raising the skill level to contribute

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.

~~~
ricardobeat
Sure the "raising the skill level" bit is just trolling. Omitting semi-colons
_is_ about removing ambiguity, and making it easier to spot inconsistencies.
As a bonus, code looks cleaner.

In this case, the minifier is breaking the code, regardless.

~~~
fusiongyro
Can you parse this expression without parentheses?

    
    
        a && b && c || d || e + f > g && h
    

The parser sure can. Do you have all the operator precedences memorized, or do
you use superfluous parentheses because you're not always sure?

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.

~~~
rtomayko
Do you use parenthesis to denote order of operations in all cases, even when
extremely obvious? If not, should we assume your position is absurdly immature
hipster posturing that serves no engineering purpose?

~~~
jhuni
I use Lisp, so the answer to your question is yes. I do use parenthesis in all
cases.

------
IsaacSchlueter
My comment from the thread, buried under many pages of meme gifs:

>>>

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

>>>

------
slantyyz
Am I missing something? Aren't Bootstrap and JSMin open source? Instead of
focusing on coding philosophies, someone can simply fork JSMin's source and
make the appropriate patch, or make a fork of Bootstrap that has JSMin
friendly code.

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

------
tbranyen
I think the stupidity here is entirely isolated to using JSMin.

~~~
tbranyen
Allow me to explain further, as I've been down-voted a few times.

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.

------
biojazzard
If I remember well, bootstrap is using cat & uglyfy, not JSmin. Every jQuery
plugging in BS starts with a semicolon. The Battle of the blind egos.

------
alexchamberlain
Should JSMin being enforcing the spec or good practice?

My vote: Good practice

Upvote replies to vote. Please don't down vote the replies so we get a clear
picture.

~~~
mike_esspe
It's obviously should be the spec + warnings for good practice.

------
jhuni
I am so glad that I am a Lisper. I haven't dealt with issues of text file size
or syntactic standards for at least a year.

------
seandon
I don't get it, @fat never said anything negative/positive towards Crockford.
Why is this even a thread??

------
noonespecial
"Be liberal in what you accept, and conservative in what you send."
<http://en.wikipedia.org/wiki/Robustness_principle>

Its like the golden rule for software. It generally stops nonsense like this
cold.

~~~
MichaelGG
No, it just makes things worse. If people are going to follow the spec, they
should follow it and reject bad input. Otherwise, you get a mess of code that
tries to guess at what to do. This leads to inconsistencies, possibly security
bugs.

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?

------
peregrine
Real question is... why not just use UglifyJS or any one of the other js
minifiers? So what Crockford is opinionated about JS, we all know this. Don't
use his products if you don't like his opinions.

------
pbreit
The obvious thing to do is:

1) JSmin should be modified to handle Bootstrap-style semi-colon-ing

2) Bootstrap should adopt the more commonly understood semi-colon-ing

------
grover3333
Jacob/Fat was trying to minimize the code before it was run through minimizer
and is surprised at the results?

Sounds like another emotional issue.

------
biafra
If there is a tool to insert semicolons in all the right places, you could use
that before using jsmin. Would that help?

~~~
Jach
The problem from my reading of it is that "all the right places" changes
meaning depending on which specification of JS you're talking about. But yes
it would work if you run into the problem and the semicolon-inserter targets
the right spec.

------
dubcanada
How many times must this bush be beaten. I've read people complaining about no
semicolons in javascript for ages.

Get over it...

------
goronbjorn
It's called forking.

------
bkorte
Oooh, developer drama.

------
bbayer
you don't have to use linebreaks either but people use it. There are lots of
good practices making code easy to use, read and maintain. So just put f..
semicolon.

------
joshontheweb
yes, yes, yes.

------
ellie42
That's really stupid. There's no plausible reason that the end of that method
shouldn't have a semi-colon. I honestly wouldn't advise anyone use Twitter
Bootstrap. You should always use semicolons in Javascript even if you're
hippie. Hippies use coffeescript.

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...](http://google-
styleguide.googlecode.com/svn/trunk/javascriptguide.xml#Semicolons) [2]
<https://github.com/styleguide/javascript>

------
drivebyacct2
Crockford's stance is annoying purely because it's pedantic and because there
are _many_ libraries that embrace this style. We use django_compressor and
found bugs from the compressor that uses Jsmin. So I have to use something
else to compress them before hand.

Are there compressors that use the syntax tree rather than transforming the
source?

~~~
YuriNiyazov
Is there any particular reason why you refuse to put in the semicolons in
Javascript?

~~~
jpeterson
There's a whole hipster movement going on right now around the idea of
omitting semicolons from JavaScript code. I believe CoffeeScript is the
culprit.

Personally, I agree with Crockford -- it's dumb.

~~~
bratsche
Kind of funny that you say this, since CoffeeScript inserts semicolons.

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.

~~~
Osiris
On my team we've decided to use semi-colons in JavaScript for this exact
reason: It would actually take more effort to stop using them as our other
major language is PHP. More effort for no benefit is pointless.

------
dreamdu5t
I don't care what Crockford thinks. He's irrelevant and his opinions are often
confused with expertise.

------
shpoonj
What a child... Has anyone read the GitHub style guide? 'Do your best to never
use a semicolon. This means avoiding them at line breaks and avoiding multi-
statement lines.'

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!

~~~
FlemishBeeCycle
Why do you believe the github style guide to be the authoritative source for
JavaScript style? There is no benefit for avoiding use of semicolons other
than not writing semicolons, whereas there are several detriments for their
omission.

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

