What JavaScript library should we use? (Regardless of licencing issues)

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
kkaefer's picture
jQuery
69% (86 votes)
Prototype
15% (19 votes)
Other library (specify in comment)
4% (5 votes)
Custom built library
12% (15 votes)
Total votes: 125

Comments

I still think our best bet

Steve McKenzie's picture

I still think our best bet is to do a custom built library that is the style of prototype.

Wont it be re-inventing the

silence's picture

Wont it be re-inventing the wheel? we will be implementing most of the functins from protototype again?

Interface elements for jQuery

canen's picture

This may be helpful: http://www.eyecon.ro/interface/

wow

ultraBoy's picture

Awesome. Thanx for the link!

Great!

silence's picture

I didn't have a thorough look at it but.... Its really looks great! If the liscensing issues abt this one too can be resolved, may be we can use it.

I think as well that we

Frando's picture

I think as well that we should use an external library. We don't have to reinvent the wheel, and there are some really good js frameworks out there.
Jquery [1] for example seems like a good candidate, as it's quite small and can be really easily extended by our own methods (without having to hack anything of the jquery scripts).
So why should we recreate all this basic stuff?

[1] http://jquery.com/

Custom

Jaza's picture

I assume that the 'drupal.js library' counts as 'custom built', which is why I've gone with 'custom'. We already have a super-lightweight, solid library in Drupal core - let's work on improving that library.

Jeremy Epstein - GreenAsh

Jeremy Epstein - GreenAsh

My point (for JQuery) is

ultraBoy's picture

My point (for JQuery) is here: http://groups.drupal.org/node/657#comment-1711

OK. I'm all for JQuery. The

Steve McKenzie's picture

OK. I'm all for JQuery.

The reason why I first wanted the custom library was so we can aim more and making it specific for Drupal work.

JQuery will do just fine.

Now, how are we going to start? when are we going to make this final choice? Lots of people voted on the custom built library...

arguments against internal

sime's picture

I don't mind changing my vote to JQuery. There are good arguments for it, sure. But I don't think Jaza's point has been addressed.

So why not internal? The arguments so far seem to be:
1) don't re-invent the wheel.

Soooo. I'd like to hear more reasons against an internal library. Are the JQuery maintainers better coders? Do we not have the resources on hand? Are we simply too far behind to catch up to some of the coolness?

A good point for a custom

scroogie@drupal.org's picture

A good point for a custom library would be the inclusion into drupal. I guess a library like jQuery will never make it into core. drupal.js already is in core...

"I guess a library like

ultraBoy's picture

"I guess a library like jQuery will never make it into core." - WHY?

Well, have a look at other

scroogie@drupal.org's picture

Well, have a look at other discussions, e.g. on Template Engines, WYSIWYG editors or forums.

Don't see your point

robertDouglass's picture

When Steven posts here and says that "Adding jQuery's query system would simplify some parts of drupal.js, so I would be in favour of that", this is a big clue that doing work in this direction is a good idea and that change is not only possible, but likely. If you feel strongly about the funtionality in JQuery, and would like to see parts of it in core, this is your chance. It is time to get some prototypes on the table for discussion. It is time to submit patches. You really couldn't ask for more wind in your sails.

I see your point...

sime's picture

and I like it.

I will like it even more when I see a Drupal issue titled "Pave the way for jQuery". :-)

well... monday morning for

Steve McKenzie's picture

well... monday morning for me..

with Steven giving his 2 cents on this topic, I believe we should follow what he says. The more I look into JQuery, the more I like it.

I vote we use it and start are next stage.

Is anyone against confirming that JQuery will be our library of choice?

If we're all agreed, I'd like to call a meeting for the end of the week (Friday ?) to discuss what we need to do next and who's going to start on what (probably some mini milestones too).

See Steven's comment up above

robertDouglass's picture

anything can make it into Drupal core, if it brings the right combination of value and licensing terms. Looks like there is some good support behind JQuery. I say it is time to start making some first attempts to integrate it, and that means starting with the Drupal core files.

A couple answers...

John Resig's picture

Are the JQuery maintainers better coders?

I feel pretty confident in saying that we're good at what we do. In addition to maintaining jQuery, I'm also writing a book on Javascript, and doing the Javascript-based UI for two startups. The other committers are all developers at different businesses around the globe and are quite active and exceptionally competent.

Are we simply too far behind to catch up to some of the coolness?

It's very difficult to develop a full library, in any capacity. What jQuery is now is the result of months and months of work and planning. I'm not saying that the Drupal community couldn't do it, but it seems like that's time that could be better spent developing cool Javascript-Drupal interactions, rather than worrying about "such and such IE bug". As a plus, all bugs can just be passed off to the jQuery community, and we can handle them just fine (leaving you will more resources all around).

I'm totally agree with your

ultraBoy's picture

I'm totally agree with your answers. Creating such a library is a REALLY BIG work. I don't think drupal community would do it itself with good quality and enough fast.

Nice to see you here and thank you for your outstanding work.

Dojo

redmonk's picture

Dojo seems to gathering a lot of support lately, and I agree that using a supported 3rd party library will "get us there" faster.

--
Steve Ivy
http://redmonk.net

What is the actual goal?

drumm's picture

Prototype and Dojo occupy different ends of the spectrum in my mind, they solve different problems. I would use prototype to sprinkle AJAX and yellow fades over my webapp; I would use dojo to build a rich JavaScript application. Before deciding on the tool, we need to know what we are using the tool to do.

thank you drumm for throwing

Steve McKenzie's picture

thank you drumm for throwing in your 2 cents. This is exactly the problem right now..

my opinion of what we are using the tool for is to richen up the users experience with an easy to use codebase, allow for more dynamic content coming from the client side end rather than page refreshes and to also have the choice of add some pretty effects along the way.

did I miss anything?

electing 3 decision makers

sime's picture

I have been waiting months for this sort of decision, it means a lot to me ... so at the risk of appearing to be a naive fool, here's the best nudge I have to offer.

3(?) people should make a decision. They are elected by others on this thread. No-one can elect themselves.

I don't really know people that well, but Steve MacKenzie seems like a good choice for my vote.

thanks sime :) I'd vote on

Steve McKenzie's picture

thanks sime :)

I'd vote on Nedjo.

and i like this idea sime cause it's so true that this can go on waiting now for months and it was just what i was thinking. So ya, lets speed this up.

Lately I've been just swamped with crazy big sites.

I just launched www.askaninja.com and www.hopeisemo.com which are both client sites of Raincity Studios. Both of those sites are the same really, and running off the same code base. It was an extreme rush job that lacks a few things still but the purpose of the new sites was to get askaninja to 4.7 and cleaned up (which i believe was accomplished well) and to get a new branding set up to launch new sites (like the hopeisemo one). Now I have to have another site (different client) ready for tomorrow and also have the new Raincity site ready ASAP. Then there's about 3 - 4 other little jobs I have to do as well. BLAH.

I want this to start for the last week of June while I'm at Seattle Drupal Camp. I also whish some of you could come because it would be a great time to hack out some stuff but I know it's hard for some of you to get there.

Everyone cool with this?

jQuery gets my vote, on two conditions

Steven's picture

(repost from an email conversation a while ago)

Transplanting an entire library to replace drupal.js is a big and unnecessary step.

However, jQuery is quite impressive. It is based around mirroring CSS selectors in JS and achieves this using a very minimal code base (10KB in compressed/unreadable form). It would allow us to simplify many of our autoAttach handlers for example. Right now, they each select and iterate over the DOM tree. This would be replaced by something such as: $('textarea.autocomplete').

jQuery is also modular, which means we can just import its query system, while sticking to our own functions for Ajax requests. Unlike e.g. Dojo or Prototype, it does not attempt to be an all-round solution, it just makes it easy to perform common JS tasks, in an elegant fashion. In this way, it is very Drupal-like.

Adding jQuery's query system would simplify some parts of drupal.js, so I would be in favour of that. Of course, if this is done, the code in all our .js files needs to be reevaluated and tweaked to reuse as much jQuery features as possible.

jQuery also has some extra modules available (basic animations, advanced events, ajax, ...). Each needs to be evaluated on its own merit. For example, Basic Animations could be considered, because it provides very much bang for your buck. Module coders like to be able to use simple reveal/fade/slide/whatever effects, but do not want to be bothered with writing their own animation code. We could for example include these modules with Drupal, but require anyone who wishes to use it to specifically add the .js file themselves (like they would include e.g. upload.js).

Of course, nifty features aside, there are some big questions that need to be answered before we can consider this:

  • How stable is jQuery? Any version we include at release time will be the version that will be used for a major Drupal branch and its contributed modules for several months. While we can include updated versions in a maintenance release, we do not want to break any modules when we do this.

  • How sure are we have that jQuery will remain small and nimble? With JS there is always a temptation to add just a little more flexibility. Pretty soon you have a page that takes ages to load (coughdiggcough).

Conditions Clarified

John Resig's picture

Sorry I'm late to the discussion, it looks like a lot of progress has been made. I'm going to try and clarify anything that needs clarification to help move things along.

How stable is jQuery?

Quite stable. I'm very serious about selecting which code to include/exclude from the main jQuery core. Right now, we're in the processing of pushing for jQuery 1.0 (due out by the end of this month). This release will have all known bugs resolved, additional documentation, and more test cases. This 1.0 release will be supported for a very long time, as it will be the base for all future development. The nice aspect of this (and it's been mentioned here before) is that additional functionality can simply be added in the form of a plugin.

How sure are we have that jQuery will remain small and nimble?

You can feel very safe that I'm doing everything in my power to keep jQuery small. Even if I went nuts and added a bunch of stuff, the community simply wouldn't accept it; none of the developers or users feel that it's acceptable to have a large code base. Every single byte is analyzed for inclusion.

Let me know if you have any more questions.

Backward compatibility?

Dries's picture

What is jQuery's take on backward compatibility?

Dries, could you specify

kkaefer's picture

Dries, could you specify what you mean with "backward compatibility"?

Backwards Compatability

John Resig's picture

From the initial release of jQuery up until now (and the release of jQuery 1.0 at the end of this month) the API has been relatively stable, a few growthing pains, but nothing too bad.

My goal for jQuery 1.0 is to have a super-stable release with a stable API that will be available, and supported, for a very long time. It is this release that I'm helping the Drupal devs integrate into drupal.js (et. al). The core of jQuery is very solid at this point, it is for this reason that I'm creating this stable release, giving everyone something that they can continually rely upon.

Post-1.0 I'll have a separate branch of the 1.0 code that will probably have a couple API changes; features added/removed, all of this will be released separately, and maintained concurrently, with 1.0. Thankfully, due to jQuery's plugin architecture, this whole process should move rather smoothly.

Let me know if this helps to alleviate your concerns.

I'm surprised no one has

dan33's picture

I'm surprised no one has mentioned moo. If all you want is a few simple little bells and whistles such as fades, slides, so on and so forth, then you can't beat moo. Moo uses a stripped down version of Prototype called Prototype lite, which is about 4k in size. Moo itself is also 4k in size. Note this is uncompressed. Compressed, you're probably looking at 2-3k in size for the full package. Way smaller than jQuery at its compressed 16k in size. Moo can be found here: http://moofx.mad4milk.net/

Now about Prototype. Uncompressed it is fairly large, I believe the latest version is 50k. Compressed, however, it's not all that much alrger than jQuery, about 20k (jQuery is 16k in size compressed, not 10k as their web site suggests). Also, in the latest version, Prototype supports the $$() function which is identical to jQuery's $() function (selecting by CSS markup).

Given that, I will say overall jQuery seems to be smaller than Prototype. The plugins linked above for special effects are also smaller than Scriptaculous, comparing both compressed. I believe Scriptaculous files are about 30k in size each, so I doubt they'd reach 5k compressed.

One thing that I'm shocked is that no ones mentioned cross browser and browser support, or first hand experience with working with any of the libraries. Does jQuery handle this without any issues? At first glance, their event system doesn't seem very cross browser friendly. The last thing we need is to introduce a framework that will alienate a large portion of the users. Has everyone actually used the various different libraries to build JavaScript rich web sites? To me this seems like a hypathetical discussion and no ones actually used the libraries that have been mentioned thus far. I'm not sure who uses jQuery, if anyone, but Prototype is heavily integrated with Ruby on Rails. Someone mentioned support, and with Ruby on Rails backing Prototype (since it's part of the Ruby on Rails core), it has more than enough support to keep it going for a very long time.

I'd like to stress here that there are many options for a JavaScript library. You should always use the right tool for the right job, and never bloat with needless code. If you want to do some quick special effects, you should be using Moo. If you are programming a large JavaScript app and need something to make your coding life easier, choose a larger framework such as Prototype + Scriptaculous or jQuery + Plugins. If you want a rich Ajax environment to work with, well, choose a library for that. If you need a rich event module, choose the best library for that (something tells me it's not jQuery).

Last thing. I'll leave you all with a link to the Prototype documentation: http://www.sergiopereira.com/articles/prototype.js.html

EDIT:
Looking further at jQuery, AJAX is not even part of the main file, it's a seperate plugin. This means, IMO, you're getting less features with jQuery than you are with Prototype at the same compressed file size. I honestly do not see any advantage of jQuery over Prototype upon further inspection.

moo.fx, Prototype, etc.

John Resig's picture

Just want to make some clarifications:
- The current moo.fx is 4.8k compressed.
- moo.fx + prototype_1.5.0 is 26.9k compressed.
- The latest version of jQuery is 16k, not the 10k advertised - this is an error on my part, as I haven't accounted for the AJAX plugin yet. jQuery 1.0 (due out at the end of this month) will be no larger than 15k (and ideally, less than half the size of moo.fx + prototype compressed).

With jQuery, we take browser support very seriously. We currently, actively, test on all of the following browsers:
- IE 5.5, IE 6.0, IE 7.0
- Firefox 1.0, 1.5, and 2.0
- Safari 1.3 and 2.0
- Opera 8.5 and 9.0
On occasion, we also have users who test in Safari 1.2 and Konquerer.

At first glance, their event system doesn't seem very cross browser friendly.

It is completely cross browser friendly. I'm not entirely sure what browsers you were worried about in particular, but if you could let me know, I could look into it.

Has everyone actually used the various different libraries to build JavaScript rich web sites?

Yes? That seems like a silly question to ask. Upon request, I could give you a list of a couple dozen plugins that've been developed and at least a handful of very popular commercial sites that use jQuery.

If you need a rich event module, choose the best library for that (something tells me it's not jQuery).

Again, I'm not sure where you're getting this concern from. I'd be happy to get you in contact with any of the couple hundred developers who actively participate on the jQuery mailing list.

I was under the impression that the Drupal community was looking for an active, strong, small, and useful library that could be used to do: DOM Manipulation, Events, AJAX, and Effects - all of which jQuery actively supports. Let me know if I can help to clarify any other concerns for you.

Reply to your edit: The default build includes the entire AJAX plugin by default - so that 16k that you see does include all of the AJAX functionality. Additionally, any plugin is completely optional, and can be left out of the main build. It is entirely up to you how much additional functionality you want to include/exclude.

You clarified the browser

dan33's picture

You clarified the browser support fairly well. That's good. Your web site also suggests that Ajax is a seperate plugin, and not included in the core file. So you can understand my confusion. Even the reference chart says Ajax plugin on it.

About moo, you are wrong about moos file size. I'm sorry but moo.fx is 4k uncompressed. It also uses prototype.lite, which is also 4k in size. I have it downloaded and looking at the source code. It is not compressed. Moo also does not use the full prototype framework. It an use the full prototype framework, but that'd be silly, as the moo developers strive for very small source files. In fact that's the developers primary goal, which makes moo uncontested for simple JavaScript effects. In total, it is 8k in size uncompressed, which is half the size of jQuery in its compressed form.

I was under the impression that the Drupal community was looking for an active, strong, small, and useful library that could be used to do: DOM Manipulation, Events, AJAX, and Effects - all of which jQuery actively supports.

This is the definition of every other framework out there, including prototype. It doesn't seperate you from anyone. However, Prototype goes further to allow easier manipulation of the JavaScript language itself, with numerous nice features such as Object.extend(), the Enumerable class which has tons of features, and Array, String, and other extensions to the JavaScript core language. While one could argue they're trying to Rubyize the language, another could argue that it makes working with JavaScript far easy by wrapping common functionality into a simple method. For example, the Enumerable class offers: each, all, any, collect, detect, entries, find, findAll, grep, include, inject, and so on and so forth. The Array is extended with all of Enumerables functionality and also first, flatten, indexOf, inspect, last, reverse, and more. The String is extended with stripTags, stripScripts, escapeHTML, unescapeHTML, toQueryParams, camelize, and more.

There's just so much that's included in Prototype, far beyond what I listed above, for only a few extra k in size. 16k vs. 20k is what we're talking about here, in compressed format.

Prototype Namespaces and File Sizes

John Resig's picture

Your web site also suggests that Ajax is a seperate plugin, and not included in the core file. So you can understand my confusion.

Sorry about that. Physically, the AJAX code is formed as a plugin - it is not a requirement, by any stretch. However, it is also included with the default build of jQuery (even though it is just a plugin, it's popular enough to have a 'promoted' status).

In total, it is 8k in size uncompressed, which is half the size of jQuery in its compressed form.

Just to clarify the issue of file size. What you're proposing is a library that has AJAX + DOM Manip. + Selectors + Event Registration + Effects. Currently, Prototype 1.5.0 has all but effects (and comes in at 22.5kb compressed).

To also get effects, you would need to include moo.fx (or similar), which you stated. To get that you would need both the normal moo.fx library and the moo.fx.pack, which would provide you with enough of the backend to write some effects of your own - none of which moo.fx provides by default (but we'll ignore that for now).

Prototype 1.5.0 + moo.fx + moo.fx.pack together is 26.9kb, as I mentioned before.

While one could argue they're trying to Rubyize the language, another could argue that it makes working with JavaScript far easy by wrapping common functionality into a simple method.

There are, certainly, an equal number of people who do not enjoy the default language objects being extended, as it begins to pollute the object namespace and interfere with different programmatic conventions. This brings up another point, and one reason why I'm against using Prototype, personally: There is a large amount of global namespace pollution. After running a quick test, Prototype 'claims' 27 different global variables for its own, whereas jQuery only extends one: $ (and even that is re-mappable to other names).

Just to clarify the issue

dan33's picture

Just to clarify the issue of file size. What you're proposing is a library that has AJAX + DOM Manip. + Selectors + Event Registration + Effects. Currently, Prototype 1.5.0 has all but effects (and comes in at 22.5kb compressed).

To also get effects, you would need to include moo.fx (or similar), which you stated. To get that you would need both the normal moo.fx library and the moo.fx.pack, which would provide you with enough of the backend to write some effects of your own - none of which moo.fx provides by default (but we'll ignore that for now).

Perhaps you're misunderstanding why I brought up Moo. I brought up Moo as a "right tool for the right job." If all someone wants is simple effects, Moo is uncontested. It only requires prototype.lite, and you only need to use moo.fx. Obviously if someone wants more than simple effects and wants to build a fully blown JavaScript application, then moo is not the "right tool for the right job," prototype + scriptaculous or jQuery + plugins would be, or some other large framework would be.

There are, certainly, an equal number of people who do not enjoy the default language objects being extended, as it begins to pollute the object namespace and interfere with different programmatic conventions. This brings up another point, and one reason why I'm against using Prototype, personally: There is a large amount of global namespace pollution. After running a quick test, Prototype 'claims' 27 different global variables for its own, whereas jQuery only extends one: $ (and even that is re-mappable to other names).

I don't see it as pollution at all, I see it as filling the gaps in which JavaScript is missing. There are a lot of common tasks which JavaScript does not do, which leaves the user with a lot of for-loops. All Prototype does is wrap these common tasks into nice little functions. In fact, that's the entire point of a framework. If it doesn't make programming in JavaScript easier, both the core language and DOM, then why am I using it?

These "pollution" objects as you call them that bloat the code (to only 4k more in size than jQuery when compressed, which IMO isn't much "bloat" at all), include:

$A (convert anything to an array, including DOM nodes), $H (hash object), Enumerable, Element, Insertion, Field, Form, Position, and a few others.

All of those objects make the DOM easier to work with, and that's exactly what a framework is built for. Looking at jQuery's documentation, it can't touch the feature list which Prototype provides. Again, you call this bloat, or "pollution", while I call it useful and much needed functionality that any JavaScript framework would be insane not to include.

Perhaps it would be sensible

scroogie@drupal.org's picture

Perhaps it would be sensible if you could give us some examples of those improved javascript programming which shows that prototype makes my life easier and shows why it is the 'right tool for the right job'. My first impression is that we dont need this additional javascript extensions.

Do I need to even give

dan33's picture

Do I need to even give examples? Virtually any complex JavaScript application would make extensive use of the full Prototype framework.

Forms: Form, Field objects
Node manipulation: Element object
Arrays/loops: Array extensions
Extending objects: Object.extend
String manipulation: String extensions
AJAX: Ajax
DOM manipulation: Insertion

The list goes on. Just look at the documentation: http://www.sergiopereira.com/articles/prototype.js.html

Again, if you're just making a few simple JavaScript special effects and don't need that, no problem, that's what prototype.lite + moo.fx is for. I feel like I'm repeating myself for some reason. The concept of using the right tool for the right jobs seems fairly straightforward to me. If you don't need all of the functionality, then don't include them in your application.

If you're looking at code samples and an quick tour of the framework, take a look at this article: http://www.sitepoint.com/article/painless-javascript-prototype

Instead of taking my word or someone elses for anything, I strongly recommend you download both frameworks and use them yourself. Then make an accurate and educated decision based on actual usage, rather than hypathetical situations. The worst thing that we could do here is to include a JavaScript framework into the Drupal core with a few hasty decisions.

What Drupal needs

Steven's picture

We need to put this discussion in the right perspective. Drupal Core is not and will not be a client-side Ajax application any time soon. It simply does not fit well with graceful degradation and accessibility. Furthermore, you need to keep in mind that a lot of Drupal's flexibility is hard to reconcile with client-heavy logic. I'm thinking about form APIs form_alter, localization, db_rewrite, menu items, access control, filtering, etc.

For example, prototype's extension of the built-in String type to do HTML manipulation (e.g. strip HTML tags) is something which I cannot see being useful for us at all. Drupal already has a robust and extensible filter system on the server side, which any good module should make use of. Custom coding hacks result in inconsistencies.

Of course, a contributed/custom module has every right to throw all that in the wind. They are free to include another JS library. But IMO that is not something that Drupal Core should actively cater to. At most, we will make sure our own JS (whether it is 100% custom or includes existing libraries) plays nice with others.

Our priorities are to make sure that:
- Drupal core has clean, well working, degradable, minimal JS functionality
- JS development for Drupal in general, within the mindset of the project, is easy and accessible, even to those who are not Javascript experts.

This is reflected all across drupal.js. For example, we have a global "killswitch toggle" where we disable all JS on browsers that are not up to snuff. We provide a standard way of having JS-only CSS styles (html.js selector), to avoid the ugly problem of collapsible page sections 'snapping shut' after the page finishes loading. It's IMO this sort of stuff that helps make JS better in Drupal.

"Just bells and whistles" is completely the opposite of our philosophy.

(edit: In case it wasn't clear, I see jQuery as an ideal tool to achieve these goals)

Our priorities are to make

dan33's picture

Our priorities are to make sure that:
- Drupal core has clean, well working, degradable, minimal JS functionality
- JS development for Drupal in general, within the mindset of the project, is easy and accessible, even to those who are not Javascript experts.

If that's all you're looking for, then the obvious solution in my eyes would be moo.fx + prototype.lite, and that's it. Combined they are ~3k compressed, compared to the 16k jQuery. If you want jQuery's special $() function, you can accomplish similar functionality with moo.dom, which is only 1-2k compressed.

It doesn't sound like your'e looking for a large JavaScript framework, and in that case, jQuery is definitely the wrong direction, and so is the full Prototype framework.

Breaking Prototype

John Resig's picture

Just to quickly clarify another issue, that I'm sure is worrying you: jQuery, even though it uses $(), does not break Prototype or Scriptaculous. In fact, different jQuery developers have developed Scripaculous plugins for jQuery, and they work just great. So even if jQuery was included in a page by default, you'd still be able to use Prototype and/or moo.fx and not worry about anything colliding.

Actually, I was the one

sime's picture

Actually, I was the one worried about this. It's good to know, that clears up a lot of concern I've had.

CSS Selectors and Prototype

John Resig's picture

I forgot to mention that the $$() selector offered by Prototype 1.5.0 is quite different from what $(), in jQuery, provides.

Prototype 1.5.0 supports CSS 1 and most, if not all, of CSS 2. This is fine for basic queries, but comes up quite lacking in many instances.

It is for this reason that jQuery supports CSS 1, 2, 3, and basic XPath. For example, the following is a valid query:

That gives you all DIV elements that have at least one P element inside of them - and do not have a class of 'special'. This powerful syntax, alone, can become invaluable when building complex, dynamic, applications - once again saving you much coding time and cutting down the filesize of your code drastically.

Another point to mention is that the Prototype development community is not focused on working together with the Drupal community - their focus is working on integration with Ruby on Rails, and making Javascript look and behave more like Ruby. However, if there were bugs, issues, or feature requests that the Drupal community had with jQuery, they would be taken with the utmost concern and be dealt with immediately.

Some very good points made.

dan33's picture

Some very good points made. Hard to argue with that. However, we are talking about JavaScript. JavaScript works with the DOM, not the Drupal core. So noting that Prototype is used heavily with Ruby on Rails is only a good thing, IMO.

Prototype Clarification

John Resig's picture

I'm not saying that Prototype is a 'bad' library, or that the people who write it are incompetent, quite the opposite actually. It really is some excellent code that they've written. However, what I am saying is that Prototype's concerns are not Drupal's concerns. They already have one whole user base demanding features for an application that is quite, tangentially, different from Drupal. Whereas jQuery's focus is only on the code itself, and improving the quality of the code for all users - which could include Drupal, should a final decision be made.

The point that I'm trying to drive home is that Prototype developers are not Drupal users, whereas there's a large contingent of jQuery developers who are - and would love to see this advancement come through.

However, what I am saying

dan33's picture

However, what I am saying is that Prototype's concerns are not Drupal's concerns.

The point that I'm trying to drive home is that Prototype developers are not Drupal users

That's just a moot point. JavaScript libraries shouldn't be geared towards any CMS concerns, they should be geared towards the manipulation of the DOM and making JavaScript easier to work with. And you'll have to forgive me for saying this, but using jQuery with Drupal would skyrocket your popularity, so you'll have to understand when I have a lot of speculation about using jQuery when Prototype already offers everything I need.

right tool for the job

sime's picture

wryd33, I feel that you're misrepresenting the situation by saying we should just use the "right tool for the job". If your module uses prototype and mine uses scriptaculous, have we created a kind of incompatibility, whereby there is namespace conflict (I think same-named functions overwrite each other).

Both scriptaculous and moo

dan33's picture

Both scriptaculous and moo are extensions of prototype. They are nothing more than "plugins". Moo has the added benefit of being able to use prototypes base functionality and nothing more, dubbed as prototype.lite (4k in size uncompressed). There would be no problem including prototype.lite in the drupal core then allowing modules or templates to request certain scriptaculous plugins (which would include the rest of prototype as a side effect), or moo for simple effects.

Some background

nedjo's picture

Both Moo and Prototype have been closely used and considered. See Steve McKenzie's moo.module, the SPAJAX module, etc.

For some background, please see the discussions in this forum:

http://groups.drupal.org/ajax-developers

As you are a newcomer to this discussion, it would be great as well if you could explain a bit about the experience, contributions, and interests you bring. Thanks.

From the link you've given

dan33's picture

From the link you've given me, it looks like there's already plans to go ahead and throw jQuery into the core of drupal, so it's pointless for me to continue debating this.

As you are a newcomer to this discussion, it would be great as well if you could explain a bit about the experience, contributions, and interests you bring. Thanks.

I'm not really sure what that has to do with the current discussion. As a user of Drupal and a JavaScript programmer, this topic concerns me. That's all that should matter.

Does jQuery support JSON out of the box?

dan33's picture

From my understanding jQuery doesn't have JSON support, and only through a 3rd party "plugin". Since there's an obvious requirement for JSON, as it seems this group prefers it over XML (based on these comments: http://groups.drupal.org/node/614 ), are there any plans to put JSON support into the main jQuery file?

Currently, jQuery

John Resig's picture

Currently, jQuery deterministically figures out if the result of an XMLHttpRequest is XML or "other" (as deemed by the browser). After doing so, the result is passed to the handler (whether it be the XML Document or a text string). This text string can contain plain text, html, YAML, or JSON - or any other plain text data structure. While there is no 'native' support, a JSON request can be as simple as:

$.get("foo.js", function(json){
    eval("json = " + json);
    // ... do stuff with the data ...
});

Although, as we speak, I'm working on the AJAX portion of jQuery for the upcoming 1.0 release, so I may sneak native JSON support in (effectively evaling the returned JSON string for you, ahead of time). Is this what you were looking for?

Drupal.js already has a json

drumm's picture

Drupal.js already has a json parser as of 4.7.

If we're going to start

dan33's picture

If we're going to start custom building additional functionality, then what's the point of using a 3rd party framework aside from further bloat? The whole point of choosing a framework is that it provides what we're looking for, so we don't have to spend our time re-inventing the wheel. If we have to program a few functions from scratch, then perhaps we should be looking at a framework that provides everything we need out of the box.

I am still unsure of why everyone is so gung ho about jQuery without taking a look at other available frameworks. If the drupal team decides to use jQuery in the core, fine, all I ask is that you at least look at the other available frameworks. It almost looks like someone posted some "cool" code samples in jQuery, then all of the sudden everyone was "ooh" and "aaah" without even bothering to realize that jQuery is one of many frameworks. Does anyone realize that the cost of jQuery's $() function comes at a steep cost of speed? Surely performance is an issue as we don't want the end-user loading slow Drupal pages. This is just one example of what needs to be looked at before choosing a framework.

A list of core frameworks that should be looked at:
- Prototype
- jQuery
- Yahoo (YUI)
- Mochikit
- Dojo

Others based off prototype that should be looked at:
- Moo (prototype.lite)
- Scriptaculous
- Rico

Belive me, we have also

kkaefer's picture

Belive me, we have also considered other libraries such as prototype, Dojo and Mochi. But these are aiming for heavy client-side programming. Drupal uses JS do tiny enhancements such as collapsible fieldsets. We are not aiming for a one-page administration. Therefore, we don't need massive JavaScript libraries with tons of pre-made widgets. That is also why client-side execution speed does not really matter.

However, we want to continue adding such small enhancements to Drupal to make the administration even more convenient. And that is where jQuery can help us a lot because it provides features to rapidly develop "behaviors" (such as collapsing).

Another reason why we chose jQuery is the support of the author, John Resig. Prototype is specifically made for Ruby on Rails, same with some other toolkits. Having someone to support us is a real advantage.

I doubt you really took an in-depth look at jQuery or you wouldn't rant against it all the time.

without taking a look at

scroogie@drupal.org's picture

without taking a look at other available frameworks

This is not true.
It has already been said that there is a module for prototype/scriptaculous. There is also a xajax module and some custom build ajax modules like Javascript Tools (which is in fact a bundle of ajax modules), ajax_spellchecker, etc.