

"Prototype.js and Mootools did not break the web" - hindermith
http://javascriptweblog.wordpress.com/2011/12/05/extending-javascript-natives/

======
bcrescimanno
Part of the difficulty with the dogma surrounding the issue of whether or not
it's ok to extend built-in objects comes from extrapolating a set of
guidelines and rules for library / framework developers to everyone else.
There's real value in libraries not extending built-in objects simply because
they can't make any real guarantees about their execution environment and
shouldn't force their customizations on all code in that environment.

I think part of it comes from the most vocal (and probably most respected) JS
developers tend to be library developers and their guidelines for themselves
and each other tend to get misconstrued as general guidelines for JS
development.

When you're developing in a known execution environment, I don't see any
particular issue with extending natives.

------
grayrest
If you WEREN'T a prototype user (MochiKit here), you had to deal with their
Object.prototype extensions. All frameworks at the time had specific checks to
handle the prototype.js extensions because it was the most popular framework
and (like jQuery today) people would just add it to your pages. Unlike jQuery,
it caused things to blow up in not-immediately-apparent ways.

------
swannodette
One of the best features of ClojureScript - the freedom to extend natives
fearlessly. The ClojureScript compiler automatically namespaces all symbols
preventing the kinds of excruciating conflicts you would encounter otherwise -
whether from browser evolution or other libraries.

------
trebor
I stopped using MooTools almost 7 years ago. My rationale was this: if I can't
trust what the _this_ variable is in an event, because of the framework, the
framework isn't worth using.

Mootools completely confused me with the constant alteration of what _this_
was referring to depending on event or context. But in jQuery usage of _this_
was (and still is) very straightforward, so I switched.

It's no question of extending objects or of prototypes, but it's just about as
confusing, if not worse, when an object/prototype is extended without the
programmer's knowledge.

------
rgbrgb
The trend I see is that the "extra-native" features that these DSL style
frameworks were adding are now being taken care of by compile-to-js languages
(CoffeeScript, ClojureScript). The question is whether this is advantageous.
Certainly it removes a big dependency on the client side but this is at the
expense of an extra mental leap during development. I think we'll start seeing
big advantages when the debuggers work properly
([http://www.meetup.com/Coffee-Script-New-
York/events/41391392...](http://www.meetup.com/Coffee-Script-New-
York/events/41391392/)).

~~~
swannodette
I had a conversation with jashkenas about this - I don't think source-mapping
alone will ever be enough. For the debugging experience to be ideal you'll
want things like locals inspection as well being able to evaluate expressions
during the debugging session. Perhaps tools that into WebKit's remote
debugging protocol can get us closer,
[http://trac.webkit.org/browser/trunk/Source/WebCore/inspecto...](http://trac.webkit.org/browser/trunk/Source/WebCore/inspector/Inspector.json#L1765)

------
posabsolute
I know your article is not really related to your title but i'm sorry when
your implementation stop working on new browsers your kind of "breaking the
web".

That is not to say that you can't do a good native augmentation, but they
certainly did not at first.

