41–50 of 51 posts
One gotcha I've noticed a lot is when people forget to check for Console object. Or they might do this (doesn't work): if(!console) instead of if(!window.console) or if( typeof console === 'undefined' )
Earlier quoted context omitted.
With JavaScript, it's still extremely good practice -- you don't know what code you might break by extending the native prototypes. You may make it hard to integrate your code with libraries or other code. It's really not that controversial.
Actually, that's still the point though. If you are building a library to be used in a variety of contexts, with no prior knowledge of the environment, it's probably not a good idea to extend native prototypes. If however, you are building a site or web app (like the majority of Javascript developers, I would assume), then the benefits of extending prototypes within your app can provide great advantages and keep your…
The assumption here is that you're never going to use any 3rd party code. Sure, a lot of libraries are forgiving of extended natives, but certainly not all JavaScript code is (especially code written before the hasOwnProperty method existed).
> For the record, I have often extended natives within my applications, and have never once had a conflict.
I have as well, it seems like a much more common practice in the past than now. I did, however, have conflicts with code (a date popup script, for example) that also extended natives. Now neither my own code, nor later versions of that exact script, extend natives anymore. I don't think the advantages are really all that great to warrant messing with them.
Earlier quoted context omitted.
Actually, that's still the point though. If you are building a library to be used in a variety of contexts, with no prior knowledge of the environment, it's probably not a good idea to extend native prototypes. If however, you are building a site or web app (like the majority of Javascript developers, I would assume), then the benefits of extending prototypes within your app can provide great advantages and keep your…
> then the benefits of extending prototypes within your app can provide great advantages and keep your code much cleaner. The assumption here is that you're never going to use any 3rd party code. Sure, a lot of libraries are forgiving of extended natives, but certainly not all JavaScript code is (especially code written before the hasOwnProperty method existed). > For the record, I have often extended natives within…
The argument that you are giving for internal application development is akin to saying, well shit, someone could set your global namespace to null, so now what? Stop namespacing?
The better solution is don't use a crappy plugin. I prefer to write clean, maintainable, easy to read code with great abstractions, which would mean I refuse to use a shitty library and would opt instead to rewrite it myself or find a new one that does it right.
Again, I really don't see this as an issue, because extending native prototypes is one of Javascript's more powerful utilities.
Everyday you learn something new Number.prototype.times=function(fn){ for(i=0;i
Everyday you learn something new Number.prototype.times=function(fn){ for(i=0;i
Under “The evil eval”, it concludes that you should never use eval simply because it sometimes executes in global scope. That does not seem like an obvious conclusion to me. Yes, it’s a mistake to use it on user input, but that is easily avoided. I think the site should give an example of a situation where you think you need eval, the problems eval necessarily brings in that case, and how to write that without eval. Otherwise, I don’t trust that the site writer has actually explored why people use eval or what eval might be able to provide that nothing else can.
Also, under “Automatic semicolon insertion”, the site does not mention the alternative to using semicolons everywhere, which is not using semicolons but remembering to put a semicolon before each line starting with parentheses. That is a valid alternate practice, and the site ignores the possibility without even discussing its problems.
The fact that each of those two sections contain grammar mistakes (comma splices) also signals a lack of attention to detail.
Excellent write-up! I've learned most of these things the hard way :/ I'm filing this away to recommend to any developers who are setting out to use Javascript extensively for the first time. One quibble: In the "common pitfalls" section regarding the "this" object, they say that locally-defined functions within other functions never have any practical use. I might disagree: with a little coaxing, you can convince lo…
Be careful of that. There is a trap right there. Your example is using the "new" keyword and not executing the function. So what happened? 1. If you use the "new" keyword, and don't execute the function. "x = new foo()". X becomes an "object". "foo()" is behaving like a class . You got to define the properties and methods of this class with the "this" keyword. Once you create your object with the "new" keyword, these…
function Podcast() {
if(false === (this instanceof Podcast)) {
return new Podcast();
}
// other code
}It's like JS is trying to rival C++ for having the most cases where sensible looking syntax will do something completely batshit insane.
I don't care if it's the lingua franca of the net, I hate it. And I code in JS all the time.