Re: The future of gitweb - part 2: JavaScript

From: Drew Northup <drew.northup@maine.edu>
Date: Apr 20, 2011, 18:39 UTC
Message-ID: <1303324764.20895.35.camel@drew-northup.unet.maine.edu>
In-Reply-To: <201104141154.55078.jnareb@gmail.com>

On Thu, 2011-04-14 at 11:54 +0200, Jakub Narebski wrote:

Show 7 quoted lines

> * incremental blame (Ajax-y, requires server side knowing above)
> * setting local timezone in which dates are shown
> 
> Possible other JavaScript-based enhancements include:
> * sorting tables like in Wikipedia, avoiding trip to server
> * MediaWiki-like history view for selecting commits to compare
>   (base does not exist yet, and could be used without JavaScript)

Show 11 quoted lines

> First issue is which JavaScript framework or library to use:
> * jQuery (lightweight, most popular, used e.g. by MediaWiki)
> * MooTools (lightweight, 2nd most popular, opbject-oriented)
> * YUI, The Yahoo! User Interface Library 
> * other: Prototype, Dojo, ExtJS, SproutCore,...
> 
> 
> Second issue is how to use it / how to include it:
> 
> * Use some external Content Delivery Network (CDN), like 
>   Google Libraries API

> * Mark appropriate JavaScript library as dependency in gitweb/INSTALL
>   to be downloaded in appropriate place but do not provide sources.
>   Perhaps add target in gitweb/Makefile that automatically downloads
>   it.

> * Provide copy in git sources (in git.git repository), minified or
>   development version or both.  This would bloat git repository a bit,
>   and we would probably want/have to update library at its releases.

> * Instead of including source code or build (minified) version in git
>   repository, we could include JavaScript library as a _submodule_.

> * WordPress (jQuery)::
> 
>     jQuery (development version) is in wp-includes/js/jquery/*
>     in wordpress RPM

> So what are your ideas and comments on the issue of JavaScript code
> and JavaScript libraries / frameworks in gitweb?

I would like to note that we are going to have to stick with a specific version of whatever we end up using during a release/bugfix family. A failure to do this has led to numerous headaches over in WordPress land. Some theme designers were going out on a limb and overriding the version of jQuery that WordPress itself includes (sometimes with a newer one, sometimes with an older one). The substitution led to a lot of brokenness all over the place. It apparently isn't that easy to debug either. If we do not insist on lockstep updating of our use of a JS library we're probably just as well off not using one at all. The easiest way is to distribute it with the sources, but it may not be the best. Also, we are under no obligation to stay bleeding edge with whatever JS library we choose. This is a good thing as we don't need the random breakage that a "flavor of the month" updating policy would cause.

-- 
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59