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