|
|
|
|
|
by amadeus
5585 days ago
|
|
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. |
|
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.