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 / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
