If it's in a shared library, it is probably nicer to avoid. For instance, if you override a function on a native prototype, you might be overwriting some future function that browsers will implement. I've seen this done with Array.map for instance.
Sorry, but blanket statements like that are complete B.S. It all depends on context; it makes me dubious of the rest of this article if they can get away with statements like this.
It's really not that controversial.
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.
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.
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.
Also, my guide isn't even need the controversity of some of the statements that Crockford has made ;) In the end it's all advice, I'm not forcing you to write code this way.
In fact, I like it when people question the stuff I write, the worst thing that can happen is that people pick one book/guide whatever and just follow it 100% without ever thinking on their own.