Re: Example of keyboard drag and drop.

Unfortunately I've not been able to locate any official stuff on this. 
It came up in a panel discussion where there was a general concern over 
the proliferation of JS libraries and that a better system was needed. 
If JS libraries are to be the next layer of bricks in the web's 
foundation then they need to be managed in a more intentional way. 
Downloading the same library over and over with each site is just not 
scalable. My ideal last mile UI would be for the browser to prompt me 
saying "This site uses the foo JS library. Would you like to add that to 
your local managed versions?" and clicking Yes would stop the madness of 
perpetual downloads. There would need to be some kind of UI that also 
polls for updates and prompts me to say "There is a newer version of the 
foo library. Would you like to download it?" so I could be sure to keep 
current, if I wanted to. Where it gets a bit messy is backwards and 
forwards version managment. If I have foo v 2.0 installed and a site is 
trying to use foo 1.0. should I get prompted? Should my local managed 
version keep a back catalog of previous version that it builds over time 
from sites that seem to use them? What about Dojo and it's multiple 
fragments that get loaded on demand? Each of those could/should be a 
local versioned copy. How will the browser even know what version of the 
library the web page is using?

Anyway, this could be a wonderful thing if the standards can get 
hammered out. There is some sense that JS libraries are stopgap 
temporary measures until the browsers catch up with some chunk of 
capability. Another viewpoint is that JS libraries, like plugins, serve 
a broader purpose that might best be served by keeping the 
implementation in their original form. If it's the latter, then we need 
to give library management first class status in the sets of objects a 
browser needs to store, track, version and update.

CB

Joseph Scheuhammer wrote:
>
> Hello Chris,
>
>> Interesting, but 230K of Javascript seems kind of heavy ...
>
> Indeed.  There are provisions within dojo to create a distribution of 
> a just those parts of its library that one needs.  However, we are not 
> using that functionality yet.
>
> The general question of how to minimize the JavaScript download 
> footprint is on our radar.  Thanks for the information about Mozilla 
> self-updating cache
>
> I know that Sakai is also worried with respect to various sakai tools 
> using various JavaScript toolkits and, then, various versions 
> thereof.  It's also an issue in the case of portals where individual 
> portlets can potentially require different toolkits.  I don't have a 
> solution; just noting that this is something we are all going to have 
> to deal with.
>

Received on Tuesday, 13 November 2007 22:30:24 UTC