
Nine Javascript Gotchas - kirubakaran
http://www.fitzblog.com/bid/2127/Nine-Javascript-Gotchas
======
marrone
Those are good, some of which are caught by using jslint, and indispensable
tool for anyone not already using it.

------
gruseom
_Never name a variable the same as an HTML ID [...] This will work fine in
Firefox but cause and [sic] object undefined error in InternetExplorer_

No it won't. I do this all the time; it works fine in IE 6 and 7.

~~~
veeneck
I've run into this behavior/bug many times, so it is definitely a valid point.
As far as I recall, it always happens, but if you're saying you don't run into
the error then it may only be with objects. For example, create an object
named bob, and an HTML element with an Id of bob. Then try to access the
objects properties. IE6 will reference one or the other.

Untested, but it may also have to do with globally defined variables.

~~~
gruseom
We must be talking about slightly different things. Here's what I do, which
works fine in IE6 and 7:

    
    
      <div id="bob">...</div>
      <script>var bob = $('bob');</script>
    

Seems almost identical to the code in the post (mine says "var" and his
doesn't, mine uses $ to get element by id, his uses a 'get' function that
presumably does the same thing). It does not produce an 'object undefined'
error (or any error that I've seen).

By "it works fine" I mean that the variable bob references the appropriate DOM
element and behaves as expected.

What should I change in the above to reproduce this error?

~~~
eusman
the problem arises when you try to directly access the element with id="bob"
e.g. bob.innerHTML this will work on explorer

and is called global namespace polluting. and it could get things mixed up.
So, a good practise is not to name DOM elements with javascript variables.

The reason you never ran into the problem is because that locally you create a
variable with a reference to the DOM element, so you are practising a
"workaround"

~~~
aston
Actually, I'd argue that relying on magical global variables mapping to page
elements is bad practice in the first place.

If you want an element by ID, that's what document.getElementByID is for (or $
if you're using a JS framework). If you want a form element by its name (why
not it's id?), you should go out to get that specifically.

~~~
gruseom
My JS is compiled from higher-level source; at the source level there is no
duplication and it's simpler to use a variable. Moroever, using getElementById
is 60% slower than a global variable in FF and more than 10x slower in IE. For
the app I'm building, this matters a lot.

~~~
aston
Of course it's faster to use a precomputed reference than to find an element
in the DOM. I can't see the "overhead" of manually storing a reference to a
DOM element in a variable ever mattering in any application. Grab it once and
you're done.

~~~
eusman
the only sure thing is that the whole javascript perfomance/memory
footprint/cross-browser/degrade challenge can drive someone crazy!

------
nirmal
The error with the array just seems like poor practice. If you only want to
deal with the contents of an array then you should use the [] with an integer
index.

~~~
axod
I agree. You should _NOT_ use 'for in' on an array. Secondly, if you use 'for
in' on an object, the first line inside your loop will most usually be:

if (e.hasOwnProperty(key))

This gets rid of anything defined on the prototype etc and would have solved
the issue in the article. However, using for...in on an Array isn't good
practice anyway.

~~~
paul
You should NOT use any library that messes with Object.prototype or
Array.prototype, then this won't be a problem and the for loops will work just
fine.

~~~
axod
Not particularly, if you're extending your own objects, you could still get
properties in a for...in that you weren't expecting, so hasOwnProperty is
always a good idea.

Regardless though, using for...in on an Array is bad practice and not a good
idea. Just like having sparse Arrays in js is a bad idea.

