Javascript prototype example- changing protoype of standard JavaScript objects

Question

<!DOCTYPE html>
<html>
<body>

 <p id="demo"></p>

  <script>
  Date.prototype.name="not good";

 var d=new Date();

    document.getElementById("demo").innerHTML =d.name;

   </script>

   </body>
   </html>

Result-

not good

In the above example the name field is being added to the Data object using the prototype functionality.

What could be the drawbacks of doing this? Are the changes made here will reflect permanently?

According to w3scholls I got this note- Only modify your own prototypes. Never modify the prototypes of standard JavaScript objects.

But sometimes isn't it convenient?

it can be handy, but it slows down code and can cause conflicts with library code that wasn't written with the modification in mind. — dandavis, Jul 07 '15 at 03:01
While working with your own code, you may have a handle on what you're using where, but in large codebases overwriting the standard objects can be detrimental to other peoples' code. If you're wanting to expand/change the base javascript prototypes, it's a better idea to create a wrapper around them and alter the wrapper object's prototype — Jonathan Michalik, Jul 07 '15 at 03:07
@techfoobar: Date.prototype might be exempt (not sure), but modifying data protos will de-optimize V8, probably others. — dandavis, Jul 07 '15 at 03:08
possible duplicate of [Is it an anti-pattern to modify JavaScript's built-in prototypes?](http://stackoverflow.com/questions/1676383/is-it-an-anti-pattern-to-modify-javascripts-built-in-prototypes) — , Jul 07 '15 at 03:35
If you are going to modify a built-in prototype, use `Object.defineProperty` to avoid the new property being enumerable. — , Jul 07 '15 at 03:36
See also http://stackoverflow.com/questions/14034180/why-is-extending-native-objects-a-bad-practice. — , Jul 07 '15 at 03:37
Does it mean that if I make changes ot standard library using prototype it will be reflected forever? — RajSharma, Jul 07 '15 at 04:00
For as long as that page is loaded. It's a modification for the duration of that page being loaded only. It won't affect other pages that don't have the same script. Every page load starts with a new, fresh unmodified environment. — jfriend00, Jul 07 '15 at 04:51

jfriend00 · Accepted Answer · 2015-07-07T03:40:06.237

Except for polyfills which implement standard-defined behavior in older implementations, it is generally not considered a good practice to modify the implementation of built-in objects. These are some of the reasons:

A standard object is a public namespace. The standards may evolve over time and add new methods/properties which could conflict with the properties you add. Better to avoid that possibility and avoid code that could conflict with future browsers.
If multiple pieces of code being used in a project are all doing this (imagine a project that pulls in 15 third party libraries to do its job), then there is a chance for conflict among the modifications (since they aren't defined by any standards).
You may be modifying the behavior of a standard object in a way that could break some existing code. For example, adding an enumerable property or method to some objects can mess up existing code that iterates existing properties. If you were going to add something, make sure you add it with Object.defineProperty() so that it is not enumerable.
There's pretty much always another way to accomplish what you want to do that doesn't have these risks and works just as well. For example, jQuery chooses to create a container wrapper (it's own object) that contains references to DOM objects and is the container object for its own methods.

Javascript prototype example- changing protoype of standard JavaScript objects

1 Answers1