[wvenable]

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.

[amadeus]

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 code much cleaner.

So again, I am not saying don't extend, and I am not saying extend, I am simply saying, that I agree that one should err on the side of caution and asses the situation for which they are coding for and make a decision regarding those circumstances. Simply saying a best practice is to 'never' do it to me is quite short sighted and is not properly educating new developers on how to write good Javascript.

For the record, I have often extended natives within my applications, and have never once had a conflict.

[wvenable]

> 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 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.

[amadeus]

You're actually further proving my point. I said that if you are writing an external library, it's a good practice NOT to extend prototypes since the context the plugin will be used in is entirely unknown.

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.