Comments on: DOMAssistant 2.5 released – Making a run at the the major JavaScript libraries

By: Morgan Roderick

Morgan Roderick — Wed, 19 Dec 2007 11:41:42 +0000

Good to see some of the lesser known frameworks get some press. Diversity inspires, and having access to more tools, allows you to make better decisions, when choosing the right tool for the job at hand.

By: robnyman

robnyman — Wed, 19 Dec 2007 08:51:36 +0000

Jordan,

Would you like to elaborate on that? The syntax for CSS selectors is exactly the same as W3C, although it also offers a way of referring to IDs without the starting # (the effect of this backwards compatability, as mentioned in the post, is that if you were to want ALL the elements of a certain tag in the entire document, there’s a slight twist to it, where I discuss the pros and cons in my blog).

By: Jordan

Jordan — Wed, 19 Dec 2007 04:39:15 +0000

@robnyman:
I gather from the blog that the CSS selector syntax in DOMAssistant is slightly different than the W3C. Particularly with the (“#id”) syntacies.

By: robnyman

robnyman — Tue, 18 Dec 2007 15:27:42 +0000

Dov,

Very valid questions. First, I’d say that whatever JavaScript library one prefers, I think it might be just a tad naive to think one library will be the perfect option in any context and situation. Most JavaScript libraries out there do compete, but also complement, each other.

To make the case for DOMAssistant:
- Lightweight.
- It contains the features people needs in most projects, without the overhead over sometimes superfluous methods.
- As opposed to, for example, jQuery, the DOMAssistant CSS selector syntax exactly matches the W3C syntax. No need for anyone to learn a certain JavaScript library’s syntax, instead learn the standardized approach from other existing technologies.
- Very easy syntax. While, for example, the Events module is namespaced under DOMAssistant (DOMAssistant.Events), you don’t need to use that tedious syntax to use it. Instead, it hooks into the DOMAssistant core, so you can use it on any element, like this: $(“container”).addEvent(“click”, functionToCall);

At the end of the day, though, I want people to use what they’re happy with. If you love jQuery or Prototype, by all means, use it. But whether its DOMAssistant or any other JavaScript library, I think you should know about the options, and sometimes consider that other libraries might be more suitable in certain scenarios.

By: Harald

Harald — Tue, 18 Dec 2007 15:04:26 +0000

Not sure about that run on the major libraries, maybe it was just sarcasm. When you really want a minimal modular base for your own framework, Base 2 seems to be the best choice because it runs even on the oldest browsers, the code is fantastic, it provides inheritance and includes a lot of helpers extending native javascript behaviour (similar to MooTools or Prototype but without extending native prototypes).

MooTools works great with AIR btw., I already saw some nice animations in AIR apps using MooTools Fx :D

By: mrmass

mrmass — Tue, 18 Dec 2007 14:43:33 +0000

Or – if you intend to use jQuery with with Adobe AIR and can’t because of the restrictions to the eval() function – DOMAssistant could provide to be a good alternative.

By: Joeri

Joeri — Tue, 18 Dec 2007 12:51:39 +0000

I think it’s meant to form a light-weight basis for your own library. This could make sense for people who want to develop their own library syntax (as a wrapper around domassistant), or for highly specialized web apps that need a more specific library than jquery or prototype.

By: Dov Katz

Dov Katz — Tue, 18 Dec 2007 12:40:01 +0000

I read the blog page on DomAssistant. What would be the 2-line answer to developer X as to why he should consider using DomAssistant, where, say, he’s using Prototype or JQuery? What is the value proposition to developers over those 2 libraries? I’m having a hard time determining the answer to those from the blog, and I’d like to make a more educated decision about DOMAssistant.

Is it the lightweightedness? If so, I see value in the mobile arena, but on a standard page, these libraries get cached so over the long-term of an intranet or internet site it’s less of an issue.

Is it the API elegance/friendliness? If so, I think it might have been worth taking the existing libraries and a’la Jack Slocum, getting your API wrappers to work on top of them.

Again, I don’t doubt that its an excellent library, I just want to know what I’m missing if I choose to stick with what I currently use….

Thanks in advance