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.
How Good C# Habits can Encourage Bad JavaScript Habits
11–17 of 17 posts
Re: How Good C# Habits can Encourage Bad JavaScript Habits
#12Forgive me, but it's still not clear (in terms of the outcome) to me what the difference is between: var a = new Array(); and var a = []; Would someone shed some light on this?
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 visu…
arguments = Array.prototype.slice.call(arguments);Re: How Good C# Habits can Encourage Bad JavaScript Habits
#13I 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…
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.
Re: How Good C# Habits can Encourage Bad JavaScript Habits
#14Earlier quoted context omitted.
The former creates an array with 3 empty elements, the latter an array with a single element initialised to 3. Ugh. I can see that catching lots of people. Is new part of the language, or part of jQuery?
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.
Re: How Good C# Habits can Encourage Bad JavaScript Habits
#15I 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…
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. ;-)
Re: How Good C# Habits can Encourage Bad JavaScript Habits
#16I 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…
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 us…
It wasn't completely fixed in IE7, unfortunately:
" 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."
http://blogs.msdn.com/b/ie/archive/2007/11/29/tools-for-dete...
It's still a major pain in the back.
Re: How Good C# Habits can Encourage Bad JavaScript Habits
#17I 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…
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 no…
"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).