So, remind me, what’s the rationale for always using the optional ; when you’re writing Javascript? The only reasons I can think of, off the top of my head are, “Because you’ll break minifiers without it” and “Because Douglas Crockford doesn’t like it”. Well, broken minifiers that can’t parse the language correctly can kiss my fat hairy arse and argument from authority cuts little ice here.

Gareth Rushgrove pointed me at an article, which suggested that it’s because Javascript will insert a semicolon after the return in:

return
{ key: "value" }

But that’s not exactly surprising, and falls squarely into the “Don’t do that then” category of bugs, or putting it another way, the Dominus Doctrine (“You can’t just make shit up and expect the computer to know what you mean, retardo!”) applies.

Ruby also has an optional semicolon, but good style is avoid using them and we seem to survive. In fact, the Ruby parser is rather less capable than Javascript’s:

jQuery('.class')
  .addClass('whatever')
  .html('New inner HTML')

is legal Javascript, but, in Ruby you have to write:

jQuery('.class') \
  .addClass('whatever') \
  .html('New inner HTML')

because if you don’t the compiler throws its toys out of the pram and, for bonus points, the resulting parse error implies that the parser knows what you meant but decided to throw the error anyway. Ho hum.

Is there something I’ve missed? Or should I make a preemptive stand against incompetent minifiers and start writing my Javascript without semicolons?

Updates

In the comments, “James” offers a succinct piece of code using Prototype that demonstrates the problem rather neatly. In the absence of semicolons, code like:

var foo = 3
, bar = 2 + foo

[foo, bar].each(function (i) { console.log(i) })

gets parsed as

var foo = 3
, bar = 2 + foo[foo, bar].each(...)

Which isn’t exactly what you want. If I were feeling churlish, I might argue that such problems are one reason why the jQueryish way:

var foo = 3
, bar = 2 + foo
$.each([foo, bar], function () {...})

is a better way of iterating over things, but I’m not entirely sure that it is. Looks like I’ll keep taking the semicolons.

5 historic comments »

By Mario Wed, 29 Oct 2008 12:08:11 GMT

I remember a time when one of the two main webbrowsers didn’t cope well if you left semi-colons out. It was Netscape, and it’s been a while since that was a main webbrowser, so I wonder whether this is just collectively remembered, but nobody dares to mention it because it would imply that Internet Explorer was doing something right all along.

By James Wed, 29 Oct 2008 20:07:00 GMT

<script src="http://prototypejs.org/assets/2008/9/29/prototype-1.6.0.3.js" type="text/javascript" charset="utf-8"></script>
<script type="text/javascript">
    var foo = 3
    var bar = 2 + foo
    [foo, bar].each(function(i) { console.log(i) })
</script>

By bitherder Thu, 30 Oct 2008 04:45:31 GMT

I’ve run into problems in the past where I’ve gotten some JS code working in FF, but doesn’t work with IE when semi’s are left out.

Also, for splitting Ruby statements with long call sequences in them, you can do the following:

jQuery('.class').
  addClass('whatever').
  html('New inner HTML')

But, as you point out, you can’t do it with the period (.) at the beginning of statement segments, because Ruby will only figure out that the line needs to be continued if there is an “operator” at the end of the line.

By Piers Cawley Thu, 30 Oct 2008 05:38:30 GMT

@bitherder: But the trailing dot style is gruesome, as I have ranted before (I was arguing for a compulsory semicolon in Ruby at the time – I am nothing if not various in my opinions).

@James: Ah… yes. That’d be a nasty surprise and no mistake. I knew there had to be a better reason than making minifiers happy.

By Dr. Green Sun, 30 Nov 2008 13:52:55 GMT

Interesting argument. I must admit that I use the ; to finish lines and have never thought about not using it. As someone who uses minifies to reduce load time, I guess I’ll be sticking with it.