Now, both Prototype and jQuery use the infamous “$” alias so you’d think there would be an instant conflict but this peaceful co-existence between the libraries is able to happen because of a nifty feature included in jQuery; jQuery.noConflict(). Essentially, jQuery.noConflict() allows you to rename the default alias “$” used by jQuery to something totally different thus avoiding naming conflicts with other libraries such as Prototype and MooTools (both of which use the “$” alias). This is very cool and obviously of tremendous benefit since it allows developers to leverage the best features of both Prototype and jQuery.

With all of the framework projects jockeying for position and at times, throwing barbs at each other, it’s truly refreshing to see a website take advantage of the great features included in these two great JavaScript libraries.

In most development environments I applaud efforts for integration of different system. It drives me nuts when a framework locks me into that framework and only that framework.

But the case of JavaScript is special. These frameworks must be downloaded by the client. I feel like we are already asking a lot of our users to download a large JavaScript framework. Even when we compress/minify/etc the source to make it as small as possible we are asking a lot. To use multiple framework to ease our development we are trading a little convenience on the programmer side for a lot of convenience on the user site for a lot of users. Just look at the stats for that site (courtesy of YSlow):

This site is around 180K for one page view (I’m looking at the results page). If someone is viewing this on a modem then they are downloading this page at about 5K/sec (that is the speed I seem to remember in my modem days). This means they will need to wait over half a minute before they can see their results.

Even worse is the number of HTTP Requests:

This page has 16 external JavaScript files.
This page has 5 external StyleSheets.
This page has 40 CSS background images.

This massive number of resources is in large part due to using multiple frameworks.

I’m not saying you can’t mix frameworks. You may have good reason to but consider the trade-offs from your user’s point of view. Not your own point of view. And I wouldn’t encourage it for the common case. Maybe one day these performance issues will change causing the trade-offs to change but right now avoiding bulk is still necessary. There is nothing this site doesn’t that cannot be done in one framework (perhaps augmented with some 3rd party extensions).

Protocolous for effects, jQuery for ToolTips and other things … I don’t see one single reason to include 2 frameworks on one page, when you need Tooltips and effects. Both frameworks have effects, both can calculate browser dimensions or catch user events. One framework can do the job without any drawbacks. And when you use one framework for all your projects, for example mootools, you have reusable code and you also save a lot of time, simply because you can write your widgets one time and reuse/extend them in all your following projects.

I know, time is money and using ready-to-use js-plugins can save time … but do not pinch and scrape on your web frontend where people can see it ;-)

@Eric: Good assessment of the load on the client; we’re aware it’s pretty large, and are working to consolidate things. As with all development efforts it’s a balance of spending time on bugs, functionality, and optimizations.

Clearly, given the richness of both Prototype and jQuery, it’s better to use a single framework. In this case, what you see is a slow and gradual evolution from a starting point (Prototype) over to jQuery. We started with Prototype due to it’s tight integrations with Ruby on Rails, and we’re *slowly* migrating over to jQuery. There are a number of reasons for the migration, but to avoid the flames, I won’t cite them here :)

@Harald: Have you ever thought of the fact that perhaps they *wanted* to use specific functionality from both libraries? Is it not conceivable that they preferred the clueTip plugin vs. a PT alternative or that the effects in Script.aculo.us better suited their needs than the ones in jQuery? While I know that the MooTools project promotes a single framework ideology, it’s unrealistic to think or expect that a business would limit itself to one framework. DaveG gave a great rationale as to why both frameworks are used and this is hardly an uncommon reason. One size does not fit all.

Kudos to jQuery for allowing compatibility and it may be a trend we see more of in the future, but from a managers point of view I’d prefer not to have two architectures and code bases to manage and train up staff for.

As a developer this smacks of laziness, it seems very heavy to include two libraries that each could provide what they are looking for! Theres massive amounts of duplicated functionality – both libraries are good, so why not learn to master one?

@Ross: I really think it just depends on what the goals of the site are. As Dave eluded to, they’re in the process of migrating so this strategy makes sense.

Comment by Rey Bango — November 5, 2007

…this is a nice combination I have used before — Prototype and jQuery. Specifically I love the tab widgets (Ajax tabs, pre-load content JS tabs) built on top of jQuery, then in general I prefer to use Prototype for unobtrusive JavaScript development. The compatibility of Proto and jQuery is not new news as it’s linked on the front page of jQuery’s site (http://docs.jquery.com/Using_jQuery_with_Other_Libraries) but it’s good to give a heads up to the community about

@Mark: Definitely not new news. My point was to show that it is possible, at sometimes desirable, to use different frameworks and that its great when they can be implemented without conflicts. :)

Comment by Rey Bango — November 5, 2007

@Rey, I think in the interests of the users it doesn’t matter your or Harald’s point of view. All Harald, Eric, and Ross want to state is that it’s inefficient for the user — not necessarily for the site (although the bandwidth used to be a problem). I think anyone would agree with your point as long as they don’t mind unloading some burden to the user.

In my projects, which are mostly pure AJAX applications, I use Scriptaculous (and therefore prototype) as well as Mootools. Mootools provides really nice cookie and drag n drop support that’s much better than Scriptaculous’, but since it’s API is FAR too verbose to actual use, I use prototype for most everything else (unless it’s too verbose then I’ll use my own stuff– building an AJAX framework isn’t exactly spinal surgery.)

@Olmo: I thought we were having a free-exchange of ideas. I believe all our points of views (me, Harald, Eric, etc) matter as they help to shed different perspectives on what might be best for both a site and users. I fully understand what Harald, Eric, and Ross are explaining and they make sense in some cases but I’m not in agreement that it’s the right solution for all scenarios.

Comment by Rey Bango — November 5, 2007

I guess I got confused. I thought you were devalue-ing their opinions. :). No worries.

@Olmo: Naw man. I respect everyone’s opinions but there are plenty of times where I just won’t agree with them and I like to share my views. I actually like these exchanges (yes even with you Olmo) because it helps me learn from people who I find, in many cases, VERY qualified.

This is a bit of a shameless plug, but my site dealscout.com has been up for about a year and is similar to getitnext.com in that it does AJAXy eBay searching.

I don’t use any JS libraries except someone’s autocomplete code (8k) which I customised. All my other AJAX/JS functions (dealing with JSON data, table rendering, sorting etc.) are in one 11k JS and that’s not even compressed. I haven’t felt the need for a big framework so far…