I don't see why a person with a C# background would have any of these (2) "bad habbits". On the contrary, someone with some C# experience would do his best to avoid global variables, and one of the first things he would search for would probably be how to do namespacing with javascript. The new keyword may be an issue at the beginning but as soon as you do some JSON, you automatically get the correct way of declaring arrays and objects.
I came here to say the same thing : C# makes it intentionally very difficult to create a global variable, and the first example is just a case of sloppy coding, whatever the language. You cannot develop a habit of creating global (or undeclared) variables if you're coming from a C# background.
Similarly, the global namespacing - a C# developer is going to look for ways to declare namespace.definition style, and is not going to spontaneously come up with namespace_definition, as this is an unseen pattern in C# examples and general practice.
Perhaps it would be a good primer for a VB6 -> Javascript developer, but I don't imagine there are too many of those around.
"VB6 -> Javascript developer, but I don't imagine there are too many of those around."
Why not? Some of us are (were) stuck maintaining bad VB6 apps and asp webpages with vbscript that we had to migrate to javascript as Firefox doesn't support vbscript.
I no longer do this, but it paid above average for my country and I was starting out as a developer. And yes, my code probably did suck (heck, it probably still does).
I don't quite agree with everything the author said. For example, the new keyword can make the code a lot more readable if you use it to call your own constructors (that is, functions that assume that "this" is referencing a newly created object).
Also, if you're dealing with DOM, you might want to avoid anonymous functions and closures as IE tends to not do proper garbage collection within closures and leak an awful lot of memory that doesn't get freed even after you visited another page. (This is an oversimplification, Google "IE DOM memory leaks" for a better description of the issue.) This is not JavaScript's fault, but still it is an important thing to consider as your users will hate you if your site is crashing their browser even if it's not your fault.
Also, if you're dealing with DOM, you might want to avoid anonymous functions and closures as IE tends to not do proper garbage collection within closures and leak an awful lot of memory that doesn't get freed even after you visited another page.
To the best of my knowledge this was fixed in IE 7. Therefore I consider having such leaks on the general internet to be an underhanded service. Anything that leaves IE 6 usable but less pleasant encourages people to migrate to something better. ;-)
" However, as some web developers have pointed out, those changes don’t solve the problem entirely. IE still leaves behind anything not attached to the tree when we tear down the markup. In addition, sites that users keep open for extended periods of time, such as Web-based mail, can still cause IE’s memory usage to continually grow if the site doesn’t take care to avoid the leak patterns."
The outcome of those two is the same. Likewise the outcomes of
var a = new Array(3, 4);
and
var a = [3, 4];
are the same.
However,
var a = new Array(3);
is not the same as
var a = [3];
The former creates an array with 3 empty elements, the latter an array with a single element initialised to 3. So the constructor syntax is dangerous to use with just one argument. Plus, the literal is just easier to type and spot visually.
There is a slight performance penalty for using named constructors: the runtime needs to look up the "Array" entry in the scope; nothing (except common sense) stops you from redefining it or shadowing it with a local variable. The literal syntax can be resolved at parse/compile time.
Fun JS array fact: the implicit arguments argument in each function looks like an array but its prototype is actually not Array. None of the Array methods work on it, although the special length property behaves as you'd expect.
new is a keyword and has various other gotchas. The most egregious is probably is the silent but deadly failure when you forget it altogether:
function MyURL(loc) {
this.location = loc;
}
// benign:
var url1 = new MyURL("http://news.ycombinator.com");
// redirects the user to Hacker News:
var url2 = MyURL("http://news.ycombinator.com");
Calling a free function binds the global object (window in the browser) to the implicit this parameter; assigning a URL to window.location is clearly quite an obvious bug, most cases of forgetting new when calling a constructor are much more subtle. Luckily, you can defend against it in the constructor's code:
function MyURL(loc) {
if (this === (function(){return this;})())
{
// might want to log this during development, too...
return new MyURL(loc);
}
this.location = loc;
}
I strongly recommend reading what Douglas Crockford has written on the topic of JavaScript, or watching his excellent videos. (this from someone who detests video as a medium of conveying this sort of info)
pmjordon has a great reply, but I'd like to add that I'm a little surprised by your mention of jQuery... jQuery is just a framework built on top of JavaScript; it's not like it's a different language or even a language extension. It's just a standard piece of JavaScript code, an object which you can use.
I am unfamiliar with the details of JavaScript's semantics, so I won't be able to tell at a glance what is part of the language and what is part of a library.
I found the C# link in the article to be tenuous at best. JavaScript doesn't have namespaces or classes, so yes, obviously you'll need to do without them. Global variables are discouraged in C# - in contrast, uh, avoid global variables in JavaScript? Likewise, I wouldn't call creating objects using a constructor a "best practice" if that's the only way to do it in the language. Besides, there is a time and place for using new, even in JavaScript, mainly for creating functionality-heavy objects with a prototype. (as opposed to data containers)
Overall the tips and explanations are quite direct and succinct, unlike so many other poorly written tutorials. Its connection with C# is absolutely missing though.
