# Idea: Extending native DOM prototypes without collisions

DevFeed: [Idea: Extending native DOM prototypes without collisions](<https://devfeed.tech/articles/idea-extending-native-dom-prototypes-without-collisions-52085.md>)

Original publisher: [Read original article](<https://lea.verou.me/2015/04/idea-extending-native-dom-prototypes-without-collisions/>)

Author: Lea Verou

Published: 2015-04-20T00:00:00Z

Content type: opinion

Language: en

Sources: [Lea Verou's blog](<https://devfeed.tech/sources/lea-verou-s-blog.md>)

Topics: [Document Object Model (DOM)](<https://devfeed.tech/topics/dom.md>), [jQuery](<https://devfeed.tech/topics/jquery.md>), [Memory Leaks](<https://devfeed.tech/topics/memory-leaks.md>), [Library](<https://devfeed.tech/topics/library.md>)

Tags: [blog](<https://devfeed.tech/tags/blog.md>), [blog-post](<https://devfeed.tech/tags/blog-post.md>), [code](<https://devfeed.tech/tags/code.md>), [implement](<https://devfeed.tech/tags/implement.md>), [jquery](<https://devfeed.tech/tags/jquery.md>), [js](<https://devfeed.tech/tags/js.md>), [library](<https://devfeed.tech/tags/library.md>), [memory-leak](<https://devfeed.tech/tags/memory-leak.md>), [thoughts](<https://devfeed.tech/tags/thoughts.md>)

## AI overview

The article discusses extending native DOM prototypes while minimizing method-name collisions. It contrasts this approach with jQuery and wrapper objects, explains historical Internet Explorer memory-leak concerns, and presents a namespaced property pattern for library methods.

## Source excerpt

As I pointed out in yesterday's blog post, one of the reasons why I don't like using jQuery is its wrapper objects. For jQuery, this was a wise decision: Back in 2006 when it was first developed, IE releases had a pretty icky memory leak bug that could be easily triggered when one added properties to elements. Oh, and we also didn't have access to element prototypes on IE back then, so we had to add these properties manually on every element. Prototype.js attempted to go that route and the result was such a mess that they decided to change their decision in Prototype 2.0 and go with wrapper objects too. There were even long essays being written back then about how much of a monumentally bad idea it was to extend DOM elements. The first IE release that exposed element prototypes was IE8: We got access to Node.prototype, Element.prototype and a few more. Some were mutable, some were not. On IE9, we got the full bunch, including HTMLElement.prototype and its descendants, such as HTMLParagraphElement. The memory leak bugs were mitigated in IE8 and fixed in IE9. However, we still don't extend native DOM elements, and for good reason: collisions are still a very real risk. No library wants to add a bunch of methods on elements, it's just bad form. It's like being invited in someone's house and defecating all over the floor. But what if we could add methods to elements without the chance of collisions? (well, technically, by minimizing said chance). We could only add one property to Element.prototype, and then hang all our methods on that. E.g. if our library was called yolo and had two methods, foo() and bar(), calls to it would look like: var element = document.querySelector(".someclass"); element.yolo.foo(); element.yolo.bar(); // or you can even chain, if you return the element in each of them! element.yolo.foo().yolo.bar(); Sure, it's more awkward than wrapper objects, but the benefit of using native DOM elements is worth it if you ask me. Of course, YMMV. It's basica