Nine Javascript Gotchas | Hacker News Reader

Nine Javascript Gotchas

fitzblog.com

15 pointskirubakaran18 comments

Those are good, some of which are caught by using jslint, and indispensable tool for anyone not already using it.

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.

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.

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?

The reason that code works is because in IE you're not actually doing anything. All elements with IDs are already in the global scope.

var bob = $('bob'); is a useless statement in IE.

The issue comes when you do something more like this.

now bob doesn't equal "hello world". Your global has been clobbered.

---

Similarly, it's surprising how many people fall into this trap:

Well that's all great and everything, but you've just clobbered the submit() function on the form.

before:

form.submit = function()

now:

form.submit = Your dumb input element.

This explanation makes sense, but I can't reproduce the behavior.

in IE ... all elements with IDs are already in the global scope

This I can confirm. If the page contains this:

  <div id="bob">Hi</div>

then the following evaluates to true in IE:

  bob == $("bob")

...without defining the variable. I didn't know that - thanks!

The issue comes when you do something more like this.

  <script> var bob = "hello world"; </script> <div id="bob">Hi</div>

now bob doesn't equal "hello world". Your global has been clobbered.

One might expect this, given the above, but I tried it in both IE6 and IE7 and the global keeps the value it had before.

OK It's been a while. It may only happen when you start modifying the dom, or using innerHTML.

End of the day though it's a bad idea and at some point you'll clobber variables you didn't want to.

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"

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.

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.

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.

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

I'm afraid I don't follow. Creating a variable that references a DOM element (whose ID equals the variable name) is not a "workaround", it's the thing that's supposed to produce an error in IE. I'm not seeing that error. What do I need to change in what I described above in order to produce it?

See my post above for an example of an error that arises from this.

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.

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.

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.

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.

Reply on news.ycombinator.com