
Effective JavaScript Reviewed - raganwald
https://github.com/raganwald/homoiconic/blob/master/2013/01/effective-javascript.md
======
MatthewPhillips
I'd like to recommend Component[1] which makes issues like this disappear.

[1]<https://github.com/component/component>

~~~
stagas
Exactly, the issue mentioned shouldn't be why there's a semicolon before the
function wrap, but why are you wrapping your code like that in the first
place.

~~~
raganwald
Are you asking why I was wrapping the code given the tools I was using at the
time, or why I was using those tools at the time?

One can just as easily say, "If you were using CoffeeScript this nonsense
could have been avoided" :-)

~~~
bengillies
I think more that the bug is in the code that's doing the wrapping, and
therefore the fix should also be in the code doing the wrapping, and not in
the code being wrapped.

~~~
OriginalSyn
The problem is if you're using 3rd party libs, especially if the 3rd party
code is coming from developers with the philosophy that ASI is a good thing
and intentionally leave out the semi-colons from their code. Adding the semi-
colon to the code you control is safe and doesn't hurt anything.

~~~
bengillies
If you're using a library that stitches together multiple JavaScript files -
all of which work when included via separate script tags - and the resultant
file doesn't work (due to the issue mentioned in TFA at least), then that's a
bug in the library that stitches multiple JavaScript files together, and
should be fixed there.

Adding a semicolon to the start of your IIFE doesn't really hurt, but it's a
workaround more than a solution.

~~~
tracker1
I came across this issue when stitching some files together for min/merge... I
simply had the merge process insert a semicolon after each file, for
effectively the same reason.. multiple semicolons aren't going to hurt
anything... The reason for wrapping your script in an anonymous function is
similar, not polluting the global namespace, or at least not relying on
certain globals.

These are conventions, not because you have to, but because you avoid other
issues further down. You _COULD_ simply write all your scripts inline.. and if
you are judicious it is probably a bit better performing. That doesn't mean
you _want_ to... JavaScript in practice is much more about convention to
prevent/limit obstacles than a "one right way" philosophy.

Hell, look at CommonJS vs AMD and the various solutions there alone... not
even including all the one-off processes that have been used over the years.

------
richardofyork
Buy the eBook at the link below with a 45% off coupon code (and you get it in
3 formats: .mobi, .pdf, and .epub — UNBELIEVABLE. (I have never gotten more
than one format of the eBook anywhere).
[http://www.informit.com/store/effective-
javascript-68-specif...](http://www.informit.com/store/effective-
javascript-68-specific-ways-to-harness-the-9780321812186)

Here is the 45% off discount code: IUGD45 (45%)

~~~
telemachos
Many tech publishers now sell their ebooks as bundles: one price for multiple
formats (usually the big three, sometimes even more). O'Reilly,
PragPublishing, NoStarch, Informit spring to mind. (Not saying that it isn't a
good thing, but I'm surprised you think it's rare.)

~~~
richardofyork
Thanks for the info, telemachos. I have always bought my eBooks from Amazon
and, on some rare occasions, from iBooks iPad app. So I am happy to know there
are better deals outside of Amazon.

In most cases, however, the eBooks (Kindle) are cheaper on Amazon, but I am
willing to pay a few dollars more to get the eBooks in all 3 formats (.pdf.
.epub, and .pdf). I personally prefer to use iBooks (.epub works fine), when I
am on my iPad, and the .pdf—when I am on my laptop.

------
lhorie
No offense but the idiom you talked about sounds like "clever code" (in the
bad way). One shouldn't have to be guessing what a sequence of semicolons and
parentheses are for. There are perfectly self-explanatory language constructs
to deal w/ post-file-concatenation code integrity (e.g. "new function" is just
one character longer, and if you really want to be explicit and/or pedantic,
there's "void function() {}()", which is not that much longer.

~~~
schmrz
Correct me if I'm wrong but I believe that the straightforward option is that
the tools that perform concatenation handle this as well. Are there any
downsides to this approach?

~~~
lhorie
Technically speaking no, but socially speaking yes. You wouldn't want your
code base made entirely out of code golfing that works through miraculous
twists and bends. By the same logic, you should prefer even small aspects of
your code to be clear to a junior developer (or even yourself a year from
now), rather than overly clever and packed with several layers of obscure
knowledge in a single character.

~~~
schmrz
I completely agree, that's why I'm saying that it shouldn't be in the
codebase. It should be handled by external tools that are performing the
concatenation.

Of course that begs the question if this is necessary at all since I
personally haven't seen it used but I haven't read the source of many
JavaScript projects either.

~~~
lhorie
I'm of the opinion that the behavior of code shouldn't be changing depending
on what tool you pass it through. If down the road your homebrew concatenation
script gets replaced by, say, a minification tool that does concats, but no
ASI defensive code, then your code might break.

Besides, you don't necessarily want all files to be automatedly wrapped in a
function. jQuery for example would break.

