[Web-SIG] JavaScript libraries

[Ian Bicking]

Christopher Lenz wrote:
> 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.

Maybe people are reading more into this than what I personally want. 
For instance, I've found this code very useful for table display: 
http://www.kryogenix.org/code/browser/sorttable/

Way easier to implement than server-side table sorting, and a better UI 
to boot.  But it has some problems; it's not as extensible as I'd like, 
and I'd like to include support for zebra tables 
(http://www.alistapart.com/articles/zebratables/) since they go together 
well.  And I'd like them to use something like this to avoid memory 
leaks: http://novemberborn.net/javascript/event-cache

It's not a big project, nor necessarily a big library.  There are some 
key pieces that many systems share (like perhaps event cache, a couple 
backward-compatibility fixes like adding Array.push, some functions for 
manipulating CSS classes), and then there's optional stuff built on 
that.  There are several issues these libraries have to deal with, many 
of which I don't know much about, and might be widely missed in simple 
recipe-based Javascript.  Like the memory leak issue.  Performance 
issues come in there too, one of those refinements that requires some 
intuition and will never happen until a bit of code reaches some maturity.

I'm not talking frameworks for rich client-side development, just 
incremental bits of code that are robust, documented, and use a 
consistent set of reliable patterns.

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

Personally this doesn't matter much to me.  I'd rather put more effort 
into identifying a minimal core and including just the needed libraries, 
and in applying things like gzip or even source compression to the code 
(with a link back to the original code, of course -- at least that would 
be required by the LGPL, which makes me inclined in that direction for 
Javascript licensing).  Javascript is cacheable and reusable; it's no 
bigger than a large logo.

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

 >>> import urllib 
      >>> c = 
urllib.urlopen('http://simon.incutio.com/js/getElementsBySelector.js').read()
 >>> len(c)
6292
 >>> len(c.encode('zlib'))
1794

1.8K isn't so bad.

I put it through http://www.creativyst.com/Prod/3/ and get 4560 bytes, 
1275 bytes compressed.

> 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

Last time I looked at it, it didn't have its own site, and the docs were 
all very Rails-specific.  Now that I look at the code it's pretty 
comprehensable on its own, and they seem to be moving it towards being 
its own package, so that does make it more interesting.  There's some 
clever code (in a good way) in there too, like:

var Try = {
   these: function() {
     var returnValue;

     for (var i = 0; i < arguments.length; i++) {
       var lambda = arguments[i];
       try {
         returnValue = lambda();
         break;
       } catch (e) {}
     }

     return returnValue;
   }
}

var Ajax = {
   getTransport: function() {
     return Try.these(
       function() {return new ActiveXObject('Msxml2.XMLHTTP')},
       function() {return new ActiveXObject('Microsoft.XMLHTTP')},
       function() {return new XMLHttpRequest()}
     ) || false;
   },

   emptyFunction: function() {}
}

That's a kind of pattern I see over and over again in Javascript, doing 
funny little things to test the functionality of the client, and it's 
nice to see a robust pattern to handle that common case.


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