[development] replace drupal.js with prototype.js?

Herman Webley herman.webley at gmail.com
Tue Nov 15 15:01:13 UTC 2005

I definitely want to see some AJAX love for Drupal.

1. drupal.js is very good.
2. prototype.js is 45k. Then we're gonna want to add Rico or
Scriptaculous on top of that. All of the other libraries with visual
effects are pretty big as well. Thats probably too big to include on a
page by default (if people are complaing about the size of the css
file :) )
3. xajax integrates very well with PHP. With just writing PHP it would
allow us to have pages update via AJAX using php callbacks (it
generates all the necessary javascript). I like that approach. We
could extend what exists currently in drupal.js to add similar
functionality. We could even simply switch to xajax or something with
a similar concept. It would also remove knowledge of javascript as
barrier to AJAX additions to Drupal. We can use the resources saved by
not dealing with js directly to ensure that everything falls back
nicely in the absence of JS.
4.Our xmlrpc system is still based on a 3rd part library. The 'Not
invented here' syndrome isn't too bad in our community.

I think all the jazzy js effects should be left as a contrib addition
(at least for now), and that basic AJAX functionality, that can be
easily used should be added to Drupal core.

PS Visual effects can be very useful (not just snazz). Cinematic
effects can be used as UI aids, and I think that a drag 'n drop
position selector for blocks and book pages (rather than assigning
weights) would just rock!

On 11/15/05, Khalid B <kb at 2bits.com> wrote:
> > Are we risking the possibility of running into problems like we did with
> > the third-party xmlrpc library we used?  I know this isn't PHP code, so
> > there shouldn't be any exploits, but are there other issues we should keep
> > in mind?
> This is what I was thinking too when I first read this thread.
> More specifically, we may have XSS vulnerabilities by third party
> javascript libraries.
> Don't get me wrong: this is not NIH (Not Invented Here), and I support
> taking the best tools from whereever they are.
> All I am saying is that it needs to be audited for such possibilities.
> We learned the hard way with xmlrpc.

Best regards,
Herman Webley

More information about the development mailing list