
Brendan Eich: The infernal semicolon - raganwald
http://brendaneich.com/2012/04/the-infernal-semicolon/
======
cletus
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...](http://google-
styleguide.googlecode.com/svn/trunk/javascriptguide.xml#Semicolons)

~~~
nhebb
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/>

~~~
brown9-2
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.

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

------
raganwald
The key point:

    
    
      "ASI [“Automatic Semicolon Insertion”] is an error correction
      procedure. If you start to code as if it were a universal
      significant-newline rule, you will get into trouble."—Brendan Eich

~~~
enneff
That doesn't sound right to me. Making s language's syntax more liberal is not
a sane way to correct errors. If anything, JavaScript's ASI is an error
_creation_ mechanism.

~~~
raganwald
"Here is your new apartment. You must use a key to enter it. If you forget
your key, you can buzz the superintendent during business hours, and if the
super is home, (s)he will open the door for you.”

If you try to take your key with you at all times, the super will save your
bacon once in a blue moon when you forget your key. On the other hand, if you
think of the door as only needing a key when you wish to have it opened on
nights and week-ends, you are on your way to trouble.

~~~
enneff
This is not a good analogy. More like the superintendant will let you into a
different apartment, or let you into your apartment and then punch you in the
face. You just don't know.

But you don't need analogies to understand why ASI is a bad idea. ASI means
that when you leave out a semi-colon you get unexpected behavior instead of a
syntax error. Failure is always better than the unknown. At least then there's
a chance the bug will be found and fixed.

~~~
ricardobeat
> This is not a good analogy

Proceeds to offer an even worse analogy. Good one :)

~~~
enneff
I then went on to say that the analogy is unnecessary and offered an
interpretation unaided by analogies. Did you think I was not aware of this?

------
ronaldj
Just because you can doesn't mean you should. A majority of the JS code out
has semicolons. Key individuals on the committee responsible for furthering
the development of the language recommend always using it. Not including
semicolons has shown to result in code errors. It can also introduce build
errors when your code is minified. It can also create mental overhead when
other developers try to read your code. I just don't get it. Why fight it?
Then again, I'm coming from a C/Java background and they just seem so natural
to me.

~~~
skymt
I suspect it is a matter of background, as you imply. Twitter has its roots in
Rails, and I believe they also use Scala heavily. Both Ruby and Scala use
newline as a statement terminator. GitHub is another Rails shop that avoids
semicolons in JS. Zepto.js recently removed the semicolons from its code base,
and its author was a core Rails developer.

------
ender7
Is it me, or did the author tack on a new topic regarding the use of && and
||?

The fact that they return the controlling operand is quite useful. Consider a
situation where you want to check the property of an object, but don't know if
that object is null:

    
    
      var foo = obj && obj.bar;
    

I find this much more readable than:

    
    
      var foo = null;
      if (obj) {
        foo = obj.bar;
      }
    

You can accomplish the same thing with a ternary operator, but it's longer
and, to my eyes, less scannable:

    
    
      var foo = obj ? obj.bar : null;
    

Also useful when setting optional parameters:

    
    
      function myFunc(foo, bar) {
        foo = foo || {};
        bar = bar || 'default_value';
      }
    

(take care however: the empty string evaluates to false, as does [] and 0)

~~~
jayferd
I can't speak for Brendan, but I generally think && / || are great for
_assignment_ , but otherwise it's code-smell.

    
    
        var foo = obj && obj.bar; // great
        !isActive && $parent.toggleClass('open'); // smelly
        if (!isActive) $parent.toggleClass('open'); // better

~~~
astrec

      if (!isActive) {
          $parent.toggleClass('open');
      } // best
    

Damian Conway of Perl fame wrote an excellent style guide for C in the
early/mid 90s which I'm pretty sure explained why (I can't find my copy):

Programmer A:

    
    
      if (!isActive) $parent.toggleClass('open');
    

Programmer B:

    
    
      if (!isActive) 
          $parent.toggleClass('open');
          doSomethingElse();
    

Oh dear.

~~~
jayferd
Yep, that's why I always demand that if you're not going to use curlies, you
make it a one-liner.

    
    
        // okay
        if (!isActive) $parent.toggleClass('open');
    
        // not okay
        if (!isActive)
          $parent.toggleClass('open');
    

That way you know when you change it to two lines, you have to add curlies.

------
drawkbox
The eternal fires of high level bike shedding: semi-colons, whitespace and
curly braces, no programming discussion or language can escape all three.

Be liberal in what you accept and conservative in what you send (i.e. just use
semi-colons) and your systems will work and play well with others being
interoperable.

~~~
VMG
well JavaScript was liberal in accepting statements separated by newlines and
look what happened

~~~
drawkbox
True, but that is a language, products and implementations sometimes need to
be more this way since they are the front lines/interface/api. Even falling
back on broken standards or less clean implementations (url over version
header on restful apis for one example) to work in some cases where absolutely
needed but make it harder to do so.

Shipped software should try to work or be usable in the shipped format, get
funky behind the product layer if you want.

Here the minified javascript that everyone uses, should just work with the
current infrastructure. If it doesn't, provide the tool that fixes the
problems for people to ship with.

------
overshard
This whole argument is silly (the semicolon in JS argument, not this post
itself). JavaScript was built for semicolon use, use them. If you don't want
to use semicolons then at least make sure you aren't breaking major libraries
that are in mass use. If it does break something many people use then work
with the creator to fix it. If he refuses to fix it then ignore everyone using
these libraries, provide a weird workaround, or just use a semicolon!
Personally I've created a branch off of bootstrap and another library (can't
remember off top of my head) that adds in semicolons as to not break JSMin
which is critical to my deployments of websites.

~~~
tomjen3
Jsmin is broken if it can't handle missing semicolons.

Googles closure tools actually do parse the Javascript and can properly minify
them better.

------
benblodgett
I can't believe that I woke up this morning and more semicolon arguments are
at the top of hackernews..

~~~
nikcub
You haven't been around for long enough or just aren'y cynical enough, I went
to bed knowing that there would be at least 5 more posts about it in the
morning

~~~
ceol
If it's anything like the "Email is dead" one, we've got some more coming. We
need at least two arguing for Crockford (one with a liberal amount of
"hipster" name-calling), someone arguing for @fat, and @fat eventually
explaining himself (because it would be a cold day at Oracle before Doug
Crockford said anything other than "you suck").

~~~
drivebyacct2
If I see people errantly slinging around "hipster" for any reason, let alone
to pettily attack people who prefer a certain style, well, I'm going to be
even more annoyed than seeing more god damned "email is(n't) (the best
thing/going to screw your mother)" posts.

------
thezilch
For what it's worth, both libraries in question realigned their egos, despite
trolling from the likes of madrobby.

[https://github.com/twitter/bootstrap/commit/575f18aaf49abb02...](https://github.com/twitter/bootstrap/commit/575f18aaf49abb0289185f6409bee031947ccf69#L7R57)

[https://github.com/douglascrockford/JSMin/commit/5ca277ea452...](https://github.com/douglascrockford/JSMin/commit/5ca277ea452beae1c25db3bc0ef5c81309a3daf4#jsmin.c)

~~~
EvilTerran
So the fuse has burned out, but the fire's already burning. Ah well.

At least some good has come of this, even if it did come with the baggage of a
massive Internet Argument.

------
jyap
Guys, more background from 'Fat' on why he doesn't use semicolons written back
in October 31st 2011: <http://wordsbyf.at/2011/10/31/i-dont-write-javascript/>

Quotes: On the use of '&&' instead of an 'if' statement: "If you were really
having fun with it you could lose the if all together... Each is perfectly
valid. Each behaves the same. It’s just a matter of preference and finding the
style that makes most sense to you." JSLint is described as a "unnecessarily
strict linter". "The majority of lines however don’t end with semicolons
because they simply aren’t necessary and I prefer the minimalist aesthetic.
For me, \n character is enough and the semicolon character is redundant."

... IMHO: Don't be a JavaScript hipster. Add semi-colons.

------
sjwright
The purpose of the semicolon in javascript is to eliminate ambiguity. Choosing
not to avail yourself is like driving without a seatbelt -- of course it's
possible, but I always thought the job of a programmer was to be as
unambiguous as possible.

You're not the only person reading your code. Your code isn't just being
parsed by five wholly different javascript engines, it's also being parsed by
the brains of every programmer who chooses to read your code.

Expecting others to learn a few stupid rules and lame syntax hacks in order to
understand and match your style seems moronic. And defending the decision by
noting that "the spec permits it" is doubly so.

~~~
ern
When I program in C-syntax languages, I always surround loop and conditional
blocks with braces, even if they have a single line of code. Even though these
languages allow braces to be omitted, I consider it bad style, and error prone
(although I have never seen a real bug where a programmer made an error of
including multiple statements without braces). The languages do allow this
style, and however distasteful I _personally_ find it, I would expect
compilers to handle it properly.

I think the same should apply here, the minifier should handle the language as
specified, if it can't then it is has a bug.

------
orangecat
_I wish I had made newlines more significant in JS back in those ten days in
May, 1995._

I wish Brendan was not as skilled a hacker as he was. It's an amazing
achievement that he produced Javascript in such a short time. Unfortunately it
ended up having the sorts of flaws that are inevitable with such a timeframe,
yet it was "good enough" so that everyone decided it was easier to live with
the flaws than break compatibility and fix them. If the initial version of
Javscript had been worse, we might be using a much better version today.

~~~
moonboots
If javascript were any worse, it may have been sidelined entirely before it
had a chance to improve, and we would be using proprietary application stacks
like iOS even more heavily for client side development.

~~~
wickedchicken
> If javascript were any worse, it may have been sidelined entirely before it
> had a chance to improve

And we should keep using it in 2012, 17 years later?

~~~
BrendanEich
JS has improved a lot in 17 years. It's still incumbent, and with ES6 and
further Harmony work, it is still improving (much of ES6 are in V8 and
SpiderMonkey, or coming very soon).

Good luck displacing JS. I mean that sincerely, especially if you work in the
open. Dart had a rough start but even ignoring that, I don't think it will
succeed. We'll see.

~~~
gruseom
This looks like a good place to fulfill a promise I made to report back if my
hopes were dashed about Dart (<http://news.ycombinator.com/item?id=2989686>).
They were dashed pretty quickly. I've seen nothing compelling enough to prefer
Dart to a fixed-as-much-as-is-practical JS. Especially if such a JS becomes
more suitable as a compilation target (better numerics and so on).

------
edwinnathaniel
If a major framework breaks a major toolchain and they both disagree on a
fundamental principal, then they both don't promote pragmatism or "Get Things
Done".

~~~
Tichy
My takeaway is that it really is time to try coffeescript :-/

~~~
pbiggar
You will not regret it.

------
carsongross
Moar downvotes!

Can we reconsider using this thing as the assembler for the web? Can we come
up with a sane, cross-platform bytecode standard?

~~~
moonboots
Lars Bak, who leads chrome's v8 team and was tech lead for java's hotspot vm,
argues that javascript is a competitive 'bytecode' even compared to java or
CLI bytecode [1]. Among other things, Bak claims that javascript source is
more compact than traditional bytecode.

    
    
      [1] about 3/4 into this interview: http://channel9.msdn.com/Shows/Going+Deep/Expert-to-Expert-Erik-Meijer-and-Lars-Bak-Inside-V8-A-Javascript-Virtual-Machine

~~~
showell30
I'm personally in favor of leaving JS mostly alone, especially at the syntax
layer, and then let transcompiler solutions like CoffeeScript evolve to
relieve the syntax burden and add semantic improvements.

CoffeeScript is far from perfect--it has syntax quirks of its own--but it's
more pleasant for me to write in, being used to Python and Ruby. (And, yes, I
understand JavaScript too; I just don't like the syntax.)

Eventually transcompiler languages will evolve to take advantage of different
JS engine improvements. So far, this isn't a goal of CoffeeScript, but other
abstraction layers might already be doing that.

~~~
gruseom
_Eventually transcompiler languages will evolve to take advantage of different
JS engine improvements._

I wonder what opportunities there are here that haven't been exploited yet and
that don't require replacing JS with a new language. For example, could JS
implementors define a more-easily-optimizable subset of JS? Then transpilers
seeking performance could target just that subset.

~~~
showell30
It's an interesting idea. My assumption is that stronger JS engines already do
a good job of optimizing simply-written JS, whether the JS is hand written or
produced by a transcompiler.

Transcompilers that were target-specific could probably target server-side JS
at first. e.g. If you're just building a node.js app, there's no reason for
the polyfill language to make any concessions to IE, for example. So one
"optimization" is simply avoiding legacy cruft in the generated output. But I
could also see exploiting specific features of cutting-edge JS engines.

~~~
gruseom
One of the stated reasons for Dart is that the V8 team was hitting a wall with
making JS fast, beyond which a language with cleaner and more optimizable
semantics is needed. I wonder, though, whether the nature of that wall has
been clearly written up anywhere. I'd like to know if there are tricks in the
category of "This would be annoying to write by hand in JS, but would be easy
for a compiler targeting JS" that could be used to get around it.

 _Transcompilers that were target-specific could probably target server-side
JS_

I had an idea recently that (to me at least) is super exciting: someone should
make a good language that compiles (à la Coffeescript/Parenscript) to JS but
also to Lua. JS and Lua are close semantically, so it might not be so hard.
(If it did turn out hard, it probably wouldn't be worth doing.) That would be
a really interesting server-side alternative to both Dart (whose philosophy
appears to be "run our VM on the server and compile to JS for the client") and
Node.js.

------
chad_walters
It looks like the right thing might have happened here (at least in the
small).

Crockford is making a change in JSMin:
[https://github.com/douglascrockford/JSMin/commit/5ca277ea452...](https://github.com/douglascrockford/JSMin/commit/5ca277ea452beae1c25db3bc0ef5c81309a3daf4)

Jacob changed the code to be compatible with existing JSMin:
[https://github.com/twitter/bootstrap/issues/3057#issuecommen...](https://github.com/twitter/bootstrap/issues/3057#issuecomment-5140916)

There, now don't we all feel better?

------
wyuenho
In case anyone needs some context, sometime ago I posted about the problems
with leaving out semicolons had caused for users of the Bootstrap project.

<http://news.ycombinator.com/item?id=3584635>

[https://github.com/twitter/bootstrap/issues/search?utf8=✓...](https://github.com/twitter/bootstrap/issues/search?utf8=✓&q=semicolon)

------
pbreit
I suppose it's too late for Fat to do the right thing and insert the semi-
colon since he's ridiculed anyone making such a request?

~~~
prodigal_erik
> edit: The code had already been changed to an if when i suggested the jsmin
> issue be filed as a bug.

They worked around the bug some time before Crockford refused to fix it.

------
cabalamat
Languages should either (1) treat newline as a statement delimiter (as in
Python) or (2) not do so and instead treat some other character (e.g. ";") as
a statement delimiter (as in C etc).

JavaScript falls between two stools and that's bound to cause problems.

------
ricardobeat
What still surprises me the most is the amount of hostility in here.

I don't have enough fingers to count names called in both threads. Why is this
subject harboring so much emotion?

------
robwgibbons
Just use a fucking semicolon. Seriously, it's like people are embarrassed to
write JavaScript. If you ever work with other people this shit doesn't fly
very far.

------
gcb
if ; (x3B?) and \n (x0A) are the same size, why use ; in minified JS if \n has
more "features"

~~~
dave1010uk
Some reasons:

    
    
        \n can easily get turned into \r\n
        Whitespace is harder to see when debugging (especially with word wrap) 
        Convention

~~~
gcb
You're not supposed to touch your minified js after you generated it

~~~
dave1010uk
And most people won't. Using semicolons means things are less likely to break
when other people use your code.

