I think it's more of an issue of who is doing the extending. If it's your own code in a non shared library, then it's up to you.
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.
This is the case with extensions/inheritence in all the OO languages. You are supposed to verify that your extended library works, once you upgrade the base library.
Well that's why the statement is controversial. This person flat out says, NEVER extend native prototypes except for 1 single case.
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.
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.
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.
> 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.
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.
The statement comes from experience, extended stuff is bad just bad for you. jQuery and others are dropping the use of hasOwnProperty. So if you extend stuff and include one of these libs, they will break. The devs just don't care anymore. Also, there are people who are even more against it that really say NEVER EVER extend them, not even for the sake of backwards compatability.
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.
Again, it's not 'bad for you'. You don't NOT use a hammer because it doesn't work well with screws. It works great on nails, so again, context is everything. Supplying best practices that include the words 'always' or 'never', often fall quite short and don't serve people well.
A bit controversial, don't you think?