• explanations
• documentation : https://www.tennaxia.net/ujf/doc/
• sample : https://www.tennaxia.net/ujf/examples/
• to see how wonderfull things you can do with see https://www.tennaxia.net/ujf/examples/datagrid/datagrid_css.html

Soon after applying a number of the techniques in your book, I was seduced by the Lightbox script, which uses Prototype/scriptaculous, and I implemented it on a couple sites. But it bothered me that so much code was needed for such a small effect, and the more I looked at the Prototype examples, the more they seemed (without behaviour.js) antithetical the ideals of your book.

That’s when I discovered jQuery, the compact JavaScript library created by John Resig. Everything about it made sense to me, from the CSS selector expressions to the intuitive event handling — all of which could be done in a separate JavaScript file.

Back in June when I first started using jQuery, the documentation was, admittedly, pretty limited. But that has changed quite a bit in the months since then. Not only has the API really taken shape, but the site’s explanations and examples have become more numerous, more detailed, and more useful. The jQuery discussion list has also been an invaluable source of information about some of the finer points of the library.

As for me, I wholeheartedly agree with the need for even better documentation, more tutorials, and more accessible examples. That’s why I started the Learning jQuery blog in September. Rather than stunting my JavaScript development, jQuery has helped me to understand much more about what JavaScript can do and how. It has also helped me become a better, more efficient, more responsible web developer.

I don’t know enough about the other libraries to comment on them, since I haven’t been "bouncing from one library to the next," but I can say that (in my experience, at least) jQuery works as an excellent complement to DOM scripting.

This is definitely not true for the Java and .Net programmers I work with. Not comfortable with JavaScript —and seduced by the object-oriented syntax of many of the libraries— they tend to favor libraries. But after getting hooked, they end up bouncing from one library to the next, searching for some feature that the current silver bullet does not have. Or they encounter some problem with the library and if they don’t feel competent with JavaScript, they certainly are in no position to modify these libraries, which are often pretty advanced stuff.

Many JS libaries are over-engineered playthings. I am not attracted to complexity. Until I find a library that simplifies my development tasks, I will stick to what I am doing.

As Eric[1] once said to me when I brought this up, "you choose your battles". There are some applications where I write my own code, for example, to replace YUI’s getElementsByClassName with a faster, but less generic version[2].

[1] http://blog.360.yahoo.com/ericmiraglia

[2] http://bluesmoon.blogspot.com/2006/06/yui-addlistenerbyclassname.html

The code itself is not the interface. The documentation is.

A short description of all the possibilities will allow users to decide whether it’s worth their time (and money?)

An in-depth description of the library itself (containing loads of examples) will make it easy for them to use it.

If users "get" it, they’ll use it.

The only thing that’s missing is a API documentation about Prototype.

This is not the case for people just starting web development (anyone who started after early 2005, when good JavaScript libraries first started appearing).

I’d break down the percentages like so: * Hardcore JavaScripters (like PPK and Stuart): 10% use libraries * Long-time Web Developers: 50% use libraries * New (post-2005) Web Developers: 80% use libraries

I’m finding this to be true, from experience. Although, having some real numbers would be awesome. Remember: What’s good for PPK, isn’t necessarily good for everyone who isn’t PPK.