well, there are prototype based (in the sense that the native
prototypes are altered, prototypejs and mootools as two examples) and
non prototype based (for example: YUI, jQuery).
The prototype approach yields to an easier to read api: [1, 2, 3].each
vs. $([1, 2, 3]).each, but also makes the library incompatible with
another library which also alters the native prototypes
(Array.prototype.each in the above example.
In short: you can normally include multiple non prototype based
library, but only one prototype based. MooTools + jQuery + YUI for
example would work, but MooTools + Prototype.js wont.
IMO, one page should pick one single framework anyway and dont
duplicate the file-size overhead, thats why i think the prototype way
is the cleaner/better one for most purposes.
Jan
On Oct 13, 2008, at 15:27, Chris J wrote:
I understand the argument for not trying to make MooTools compatible
with other libraries and I agree with it.
My concern is when we as developers don't have any control over what
other scripts are included, like writing a plugin for Wordpress for
example. In situations like those, do I have to ditch MooTools for a
more third-party-friendly library? It's not reasonable to push the
compatibility problem onto the end-user.
What do you do?
I'm experimenting with adapters (similar to ExtJS) for other libraries
to maintain a consistent api across all of them. That way, if another
library is already included, I just include the adapter. I'm basing
the api heavily on MooTools since it's so awesome.
--
my blog: http://blog.kassens.net
