Great! I’ll get in touch with you over e-mail!

It’ll be about a month before I can contribute in any large way. Right now I’m finishing up a semester studying abroad in the UK.

Yes, and that’s a bit how DOMAssistant started; just core functions for selecting elements by id, class and attribute. THen it escalated into this CSS selector thing, which I was first a bit skeptical about, but now have come to really appreciate.

Finding tricks or pointing out bugs are both highly appreciated.

Harmen,

Thanks for such thorough comments!
I’d definitely say that the general target audience is people who know JavScript to a certain degree, although I’m sure newcomers would also be well of with very simple and solid ways to select elements, adding events etc.

With extending it, taht was exactly why we introduced plugins, since we believe the core should be small, lean and efficient, and then people themselves chan choose to extend it to suit their own needs.

The obvious follow-up question, of course, is: how can we persuade to use DOMAssistant, at least in some cases?

I think that depends on your target audience.
If you want complete newbies to be able to simply add Javascripts to their websites, I guess you have to provide lots of “Accordion menu’s”, transitions, etc. Just some out-of-the-box-cool-stuff. Newbies like hot air ;).

If your target audience consists more of Javascript veterans, than I think you’re on the right track. People who know the ins and outs of Javascript just wish to be helped a little. They already know Javascript is capable of doing cool stuff, so they don’t need to be convinced with sparkles and pretty lights. I think these users are primarily looking for a library with awesome performance and a tiny filesize. These users wish to write their own scripts and a library should make things easy for them, not be in the way.

I think at the moment, your library is aimed more towards the veteran group (which is a Good Thing, ’cause there’s already a lot out there aimed at wowing newbies, think Scriptaculous).

Another thing you could use to persuade, is just fixing really complex things, that even veterans won’t take the time for to develop for any random project. I, personally, am still looking for a decent, cross-browser rich text editor for my clients.
Then you can offer such scripts as bundles, backed up by the DOMAssistant core. Making such “standalone” scripts extensible, or even just scriptable, will also make people familiar with DOMAssistant. If they then like the syntax they might continue to use DOMAssistant for future projects.

I do however take a great interest in JS-libraries, either to pick up some nifty tricks myself or to point out bugs and suggest improvements

Olly, Andreas and Harmen,

The obvious follow-up question, of course, is: how can we persuade to use DOMAssistant, at least in some cases?

Chris,

It makes me happy to hear that you’re using DOMAssistant! And about what should be included in the core of a JavaScript library, we’re definitely on the same page.

A last method could be nice, and I don’t see why we couldn’t add it in a future version.

With event handlers for other ready states, that is unfortunately not possible at the moment. With AJAX, you can make as many parallel AJAX calls as possible, but getReadyState only returns the value for the latest call.

In regards to the documentation, I agree that some points arent really clear, and in the long run, we would definitely try to make it better and more clear. Are you interested in contributing to making it more precise?

I’ve tried Prototype a year ago, mostly to learn from, but at the time I thought it was bloated.
I’ve also used YUI some time ago back when YUI was the only respectable framework, to solve the drag and drop needs of a client.

Overall I’ve never really used a framework for more than a couple of pages that required specific functionality which I didn’t have handy myself at the time.

By developing my own library code I’ve been able to clearly state my preferences;

a consistent interface (example: if all your objects or classes have an init () method, don’t suddenly use setup () for one module)
custom event handlers rock. (example:
var AJAX = new Namespace.AJAX ();
AJAX.onReady = function () {
alert (this.response);
};
They mostly rock because it’s such a familiar system. Everyone with even the slightest bit of Javascript experience knows element.onclick = function () {}.
Being able to extend classes rocks as well. Also, having a good subclassing system is the best way to guarantee consistency.
A tiny file-size! (but I believe you’ve already got that covered ;))

All in all I think you’re doing great work, especially filesize- and performance-wise.
To think a couple of months ago you weren’t sure if DOMAssistant was a successful project… man, that’s just crazy talk!

How about a last() function to go along with the first() function?

In the AJAX module, can you define event handlers for other ready states?

I find that the documentation, while good, sometimes is not precise enough. I end up doing testing to figure out exactly what is going on. For example, you have a function DOMAssistant.AJAX.getReadyState(). I assume it doesn’t mean that only one AJAX call can be made at a time? Can the function only retrieve the state for the last AJAX call?

Every time I read a post DOMAssistant I wanna try it out. Never get around to it though.

How similar is it to jQuery? From what I’ve seen they look almost identical? Perhaps converting my jQ-plugins to DA wouldn’t be too much work…

What I want from a library? All the usual stuff. Simplicity, decent documentation, a nice selection of features, a vibrant community.

Most importantly though, it needs to be faster than light, if not quicker