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/ _______________________________________________ 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
