JS Libraries/Frameworks - Why so many?

I’m going to preface this by saying two things:
1. I am very new to MODx
2. I love MODx

Okay, with that out of the way, here are my questions.

1. Why does MODx use so many javascript libraries? We have mootools, prototype, scriptaculous and jquery all as part of the basic install.
2. Why is MODx still using mootools 1.11? (1.2.3 has a "built-in" noConflict mode for other Libraries/Frameworks that use the $)

I’ve been trying to implement a jQuery slideshow in conjunction with MaxiGallery. It’s taken some time to sort out the conflicts and my own bugs, but it’s working... as long as I’m not logged in as an admin. I’ll sort that out... I hope! LOL. I’m no javascript and certainly not with any of these libraries. I use jQuery because I’ve picked up enough of it that it makes sense to me.

I’m not complaining, just curious as to why we use so many and wondering if anyone has come up with any efficient method of eliminating further conflicts.

Evo only uses Mootools, albeit it’s still 1.11. It should be upgraded in the future.

Many folks have contributed their own work as Add-Ons to MODx. In Evolution, the most useful and commonly used of these user-contributed Add-Ons have been included in the basic installation. Most are used and demonstrated in the sample site that also is distributed with the Evolution core. Unfortunately, every contributor has different preferences on the front-end Javascript libraries they choose to employ, and it is difficult to get individual contributors to change their preferences. Our hope is that as more developers adopt the platform, they will start to develop and release sets of Add-Ons which use common JS and/or other developer libraries. We do not want to prescribe which ones they should use however.

That makes sense. So some of the additions to the core installation (like QuickManager) were developed as add-ons, which is why is uses jQuery instead of MooTools.

I am glad you don’t want to reign in developers by requiring development in only on library. One of the great things about MODx is it’s flexibility. What about my other question - is there a best practice or most efficient way of including another library without conflicting with any of the previously installed libraries or is it really just a matter of what you’re trying to do that determines their use?

Quote from: nickfury at Aug 16, 2009, 09:27 PM

What about my other question - is there a best practice or most efficient way of including another library without conflicting with any of the previously installed libraries or is it really just a matter of what you’re trying to do that determines their use?

It’s ultimately dependent upon the constraints of each site design, as far as front-end use of these libraries is concerned. I often find our team trying to coordinate component development around any libraries that have already been chosen or are already being used on a particular client project. It’s not always easy, and sometimes we have to develop custom versions of components to work around the conflicts, but we value the ability to be able to choose the appropriate libraries for the tasks at hand.

The manager is a little less flexible in this regard, but the team has made great headway on improving the consistency in the use of Javascript libraries there in the recent 1.0.0 (Evolution) release.