Prototype's DOM extensions are colliding with a 3rd party JS library — what's my best bet?

Question

I just spent almost 2 hours debugging a third party JavaScript library only to find that an array which I pass to that library gets converted to a string somewhere down the pipe... I don't know why or how that happens, but as soon as I remove Prototype from my project, everything works fine again.

Could that be because of Prototype extending the DOM? What's my best option? I use Prototype's element iterators, DOM manipulation, bind() method, and string manipulators in my project, and I'd rather not lose them.

Is there a library which has all that, but which works fine with 3rd party JS libraries that are sensitive to DOM extensions?

Answer 1

Having worked with Prototype before in the past, there is no way to have it "play nice" (akin to jQuery's noConflict mode).

The very approach behind Prototype prevents this. Prototype's bread & butter comes from its Object.extend() method that gets called on objects as soon as you manipulate them with Prototype methods. Not to mention Prototype also has already modified core JavaScript objects before messing with yours.

On the other hand, jQuery is all self-contained in the jQuery object (which is, to my knowledge, all it adds to the JavaScript namespace when included).

Are there other libraries that have similar features? Sure, in fact, and I'm sure you're sick of hearing this by now, but you could probably do most of it with jQuery. However, you won't avoid the unavoidable: re-writing code. It won't be done the same way with any other framework, let alone give you the same results/beahvior.

Your choices are thus:

• Drop Prototype and re-write stuff that did use it to use something else
• Drop the third party library in favor of alternative or absence entirely
• Re-write prototype.js or thirdpartytool.js to play nicely (this, of course, is a terrible hack that will cause more headaches when you want to "upgrade" one or both tools in the future when a new release comes out)

Answer 2

I have had success with jQuery. If you call jQuery.noConflict(), it will work very well with other JS libraries.

Answer 3

A bit of my bitter experience.

I've just finished writing my own framework for XUL applications (I just need something like a component model without any of $ or prototype lib sweetness). It's very small, handy and straightforward. But... Only now, when everything is ready for using the framework, I found that it's absolutely dead in the XUL context. The main obstacle is that the JavaScript engine discards all your changes in the base objects like Function, Object etc. So the key extensions which makes the things work — f.x. Function.prototype.toClass, override and other — are invisible outside of the file where they are defined.