jQuery in Action, 3rd edition
The moose likes HTML, CSS and JavaScript and the fly likes Standard Javascript library API Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » HTML, CSS and JavaScript
Bookmark "Standard Javascript library API" Watch "Standard Javascript library API" New topic

Standard Javascript library API

Bruno Taranta Arruda

Joined: Sep 26, 2006
Posts: 13
Is there space for a standard API for rich javascript libraries, I mean, to assure compatibility between libraries like Jquery and Prototype?


Best Regards,

Bruno Arruda
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15302

What kind of compatibility are you looking for? Generally speaking libraries don't interact with each other. JQuery can sit nicely next to any other library and play nice. The obvious difference is the approaches the different libraries take in solving the same problems.

GenRocket - Experts at Building Test Data
Ulf Dittmer

Joined: Mar 22, 2005
Posts: 42965
Namespace issues might arise when several JS libraries are used, and the problem of how to assign to global event handlers like window.onLoad (which some JS libraries do). So there's some potential to avoid libraries from stepping on each other toes.

The OpenAJAX project is working on this; check out the "Hub" and "Registry" sections.
[ January 15, 2008: Message edited by: Ulf Dittmer ]
Bear Bibeault
Author and ninkuma

Joined: Jan 10, 2002
Posts: 63865

Originally posted by Ulf Dittmer:
Namespace issues might arise when several JS libraries are used

See this topic for a discussion on how jQuery avoids this issue except for a single global identifier (the name jQuery).

[Asking smart questions] [About Bear] [Books by Bear]
Yehuda Katz

Joined: Jan 14, 2008
Posts: 21
I agree with Bear 100% about the namespace issues.

There are basically two camps amongst the JavaScript libraries: those that try to avoid namespace collisions and and those that don't. The former camp includes jQuery, YUI, Dojo, Ext, and a few others. The latter camp includes Prototype and Mootools.

jQuery and the other libraries that try to avoid collisions go so far as to avoid extending standard classes (like Array, etc.) and use other tricks like proxying calls through a wrapper (Bear has discussed the jQuery wrapper at length in other threads). As a result, using jQuery even with a single library like Prototype should not cause collisions (we consider a report that jQuery and Prototype are not compatible to be a legitimate bug ticket).

On the other hand, using Prototype and Mootools together is a recipe for disaster, since they both define the same global classes and override native classes with the same methods. Mootools goes as far as to say in their FAQ (quite honestly), that "mootools is not trying to be conflict free. Therefore, do not expect this to be a bug or unwanted behavior--mootools will not try to become conflict free. Expect, to make a choice between mootools and the other frameworks."

There's nothing wrong with taking that attitude; not trying to be conflict free allows you to make some interesting tradeoffs in terms of expressiveness of the API. But since most libraries don't go that way, there isn't a huge risk of namespace collisions in most combinations.

With all that said, once you start using the libraries, you'll see that each of them takes their own approach to an API. For instance jQuery places a huge premium on its "get some elements; do something with them API" while Dojo uses a much more traditional modular approach.

So while there might be some benefit to coming up with a nice underlying "private" set of functions for things like document ready (there's really only one way to do it), there wouldn't be much benefit in trying to compromise the approaches of the libraries into a single API. I don't know a single library contributor who would be happy with the results of such an attempt.
I agree. Here's the link: http://aspose.com/file-tools
subject: Standard Javascript library API
It's not a secret anymore!