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.
back
1 comments
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" :-)
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.
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.
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.
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.
I wasn't asking you directly, the question was kind of rhetorical. The reason is that boilerplate code like that, should be abstracted away from the actual code that we write and I was kind of hoping to see that mentioned when I saw the jQuery boilerplate.
Very good point, thanks! That is one of the little joys of CoffeeScript, many of the "defensive" coding practices don't exist. Fortunately, the book isn't just about avoiding problems but also about positive, productive idioms and practices.
I think I picked this example in a bootless attempt to humblebrag by pointing out something I'd been cargo culting.