[Web-SIG] JavaScript libraries

[Christopher Lenz]

Am 03.05.2005 um 04:11 schrieb Ian Bicking:
> 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.

Personally, I think that the recipe/cookbook style still works best  
for JavaScript. Unlike other so-called "scripting" languages like  
Python or Ruby, which have long grown to be powerful general purpose  
languages, JavaScript really is a language for scripting objects  
provided by the environment (in the case of web-development, the  
browser). Putting together a whole library or application is actually  
discouraged by the properties and restrictions of the language: no  
importing of external modules, no proper namespacing, etc. You really  
have to go out of your way to create a reusable, modular library, and  
it's still going to be a mess.

And because JavaScript code runs in the browser, relying on a library  
means that the user will have to wait until that library has  
downloaded, even though your application is likely only using a  
fraction of the functionality provided by it.

As a simple example, assume you want to reuse a library so that you  
can get all elements from the DOM that have a certain tag/class  
combination. You decide to just use Simon Willison's  
`getElementBySelector` function <http://simon.incutio.com/js/ 
getElementsBySelector.js>. Note though that that code is at least  
three times as large as it'd need to be for your use case, because it  
also supports CSS2 and CSS3 attribute selectors and what not.

For local applications, code size is not much of a problem these  
days, but for web applications, it's a very serious constraint.

> 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.

Well, one exceptionally well-done JavaScript library that I haven't  
seen mention of on this thread is "prototype" (yeah, RoR again). I  
think it should go a far way towards "smoothing out the rough edgews":

  http://prototype.conio.net/
  http://dev.rubyonrails.com/file/trunk/railties/html/javascripts/ 
prototype.js

Cheers,
Chris
--
Christopher Lenz
   cmlenz at gmx.de
   http://www.cmlenz.net/