• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Standard Javascript library API

 
Bruno Taranta Arruda
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is there space for a standard API for rich javascript libraries, I mean, to assure compatibility between libraries like Jquery and Prototype?

Thanks.

Best Regards,

Bruno Arruda
 
Gregg Bolinger
GenRocket Founder
Ranch Hand
Posts: 15302
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ulf Dittmer
Rancher
Posts: 42968
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Pie
Posts: 64959
86
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).
 
Yehuda Katz
Author
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic