[Web-SIG] JavaScript libraries

[Ian Bicking]

Donovan Preston wrote:
> I think there is no substitute for experience. Personally I have  
> found that using abstractions which try to shield you from browser  
> unpleasantness merely obscure the real source of the error or  
> incompatibility which inevitably happens anyway.

I don't think you can Make Anything Possible given the right library, 
and I think overambitious efforts (especially ones that cover up 
Javascript entirely) are unlike to succede.  But the library can give 
direction, and help keep wary developers from venturing into difficult 
territory.  Libraries embody a lot of knowledge beyond their 
functionality.  If you emphasize innerHTML-based functionality because 
it works, then you've indirectly saved the library users time and 
headaches.  In this way a more limited library that emphasizes the 
easiest constructs could be very useful.

This is why I personally am looking for that small library that does all 
the convenient or particularly useful things I'm interested in, and does 
them really well, but doesn't get too fancy.

> Of course, not everyone has the time or patience to accumulate the  
> needed experience. With the renewed interest in DHTML thanks to  
> gmail, Google Maps, and AJAX, I think it is time to set up some  
> community specifically to discuss modern javascript techniques.  
> Searching the web yields pitiful results, with lots of ancient  
> javascript designed for copy-and-pasters who want rollovers on their  
> animated gifs.
 >
> The shared brain power of a new list and web site which attracted  
> users from communities other than the Python community could be  
> valuable, as well. At the same time, we could subtly enlighten people  
> to the joys of Python just by exposing them to it.

The Javascript development community is young in other ways.  Public 
repositories and basic open source project management practices are 
uncommon.  We're still getting over a stage where everything is 
presented as recipes instead of working code; I think that's widely 
recognized, but it doesn't mean that there are a lot of good patterns 
for how to do that.  And the prototype stuff makes it hard for OO 
programmers to get their bearings.

Little things have left me feeling unsure.  Just to give one example, 
how should I "activate" a library?  Should it run onload automatically 
and search the page for activating elements?  I guess that's kind of the 
"unobtrusive" technique, but it often seems rather wasteful.  Should it 
be activated by a function call?  How are options passed in (and later 
managed)?  Should it involve a prototype for storing options, then 
methods for attaching the object to elements on the page?  Hell, I still 
don't understand prototypes in Javascript at all.  It's this stuff where 
I get confused, and so I'm actually looking for more than a Javascript 
library to smooth out a few rough edges -- I want a model for good 
Javascript development that I can learn from.

-- 
Ian Bicking  /  ianb at colorstudy.com  / http://blog.ianbicking.org