Prototyping JavaScript native types, discouraged?

Question

Is it a bad idea to prototype additional features in JavaScript's native types like Array, String, Number, etc?

I think it would be great to have functionality like myArr.pop(), etc., but what if someday that becomes part of the ECMAScript x -- and differs from my implementation, so, it potentially breaks the entire software?

Answer 1

Prototype is a library that extensively extends native Javascript types and DOM classes, and shows extremely well the good, the bad and the ugly of extending Javascript native types.

The Good: You get natural-looking Javascript code.

The Bad: You forget that you are actually using Prototype - spawning confusion when you switch to a project that does not use Prototype. (Why can't I... oh, right, that was a Prototype capability.)

The Ugly: If there is a conflict for method definitions (two methods that differ in either contracts or signatures) because of conflicting libraries, the browser or the specification, you may have to modify client code to maintain compatibility. Which makes one more compatibility consideration to make in a world already plagued with them.

For the sake of compatibility and keeping my own ideas clear, I personally refrain from extending native or DOM javascript types, and prefer less intrusive libraries to Prototype.

However, if you feel at ease with these drawbacks, don't let me stop you.