[IshKebab]

The problem is that the rules for remembering where they are needed are hard to remember and error-prone.

[BrendanEich]

See http://inimino.org/~inimino/blog/javascript_semicolons, hope it helps. The minimal semicolon style has only a few rules and many people find it easier to use and remember. I've used it but my C hacker habits go against it. It's a fine style.

/be

[aikah]

Wow neat,yeah, js devs are going to call anyone out that doesnt use semicolons.

Question : If you ever wanted 1 breaking change in the language, and somehow it would be possible (I know it wouldn't) what feature would you change ? Again just 1 feature.

[BrendanEich]

I would undo the implicit conversion madness around == and !=.

[cozuya]

Is that really a big concern today where == is heavily frowned on by just about everyone due to the above and its slowness?

[BrendanEich]

== is not slow when types of operands (in typeof sense) match -- then it's equivalent to ===.

You'll find a lot of == out there, or would if only Google code search were still up.

Hey, I got to answer with the one thing I'd change. There are more than a few, and I had to pick. Losing the equivalence relation I had in the first ten days (apart from NaN != NaN of course) was my pick.

[xtrumanx]

I treat the issue like the issue of remembering the operator precedence rules or just using some extra parenthesis.

Although I feel remembering where semicolons are needed is simple I still use them anyway for personal preference.

[insin]

I haven't used semicolons in JavaScript in places they're not necessary for years now - the only rule that's mattered in practice [1] is lines starting with [ or (.

[1] This is a white lie - there is one additional vital ASI rule, but you already know it - don't put a linebreak after a return statement.

[serve_yay]

Sure, but in practical terms I feel like this never comes up. I just never have to deal with it and I write JS all day.

[esolyt]

Not harder than inserting a semicolon after every single line.