• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

Standard Javascript library API

 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Rancher
Posts: 43026
76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 ]
 
Sheriff
Posts: 67590
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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).
 
Author
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic