Scars?

Gaping, open, unhealing wounds!

Build a second ap of equal capabilities without using js, and ensure that the first emphatically refers the JavaScript-less user to the second.

If, as your question three acknowledges, there is any class of customers/clients who may not be able to use your js version, then hard reality is likely to ensure that the members of that class will be the make-or-break demographic for the ap.

That said, you haven't given us much to go on about the target audience, nor about the required capabilities of the ap, nor clear rationale for using js. Have you satisfied yourself that these and other parameters actually dictate use of a technology tarred by widespread misunderstanding of its hazards? Have you satisfied yourself that using js is really necessary or desireable.

Just as it's said that "Hope is not a plan" so it might be said that "'I wanna' do it that way' is not sufficient justification for doing so" ...at least, not when a job, profit or the utility of the product is compromised.

Goverment regulations mandate accessibility, javascript is not part of that spec.

I can give some insight into #1. Prototype is certainly the JS library of choice when putting together AJAX driven GUI's ... but don't overlook Yahoo's YUI ... especially their Browser History Manager. Also, watch out for using $() and GetElementById() in IE -- they can be painfully slow. As for #3 -- i either say Javascript all the way or not at all. You need to understand your audience and give them the best choice. Otherwise you might end up making 2 sites (apps, etc.).

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

I agree with jeffa almost wholeheartedly. My only other suggestion would be to try out the dojo family of tools. They provide a really comfortable level of abstraction which encourages reuse and fast prototyping, however I think that to get the full benefit you need to "drink the kool-aid" and honestly, it can be a lot of kool-aid. :)

Results 1 - 13 of 13 for "mootools sucks". (0.22 seconds)

Results 1 - 42 of 42 for "jquery sucks". (0.19 seconds)

Results 1 - 40 of 40 for "ext sucks". (0.25 seconds) + Results 1 - 3 of 3 for "ext js sucks". (0.21 seconds)

Results 1 - 47 of 47 for "dojo sucks". (0.23 seconds)

Results 1 - 59 of 59 for "yui sucks". (0.18 seconds)

Results 1 - 100 of about 326 for "prototype sucks". (0.12 seconds)

jQuery is *extremely* sweet in syntax, simplicity, power, and "fit" for XHTML/CSS/DOM. That said, its UI suite is not mature and it has missing pieces like combo boxes. For my own part I still pick it because it's so easy to do things yourself, like combo boxes; which I've done and forgotten already because it was a two hour exercise.

Ext is awfully powerful and pretty out of the box. It's also *huge* and many of its pieces are not designed with degradability in mind; its form objects do not plug-into existing forms; they write forms. Not cool. Though the FormFu plugin might be able to do both which could be really neat. YUI is a lot like Ext which is a fork from it but not as powerful or well designed.

I've never used Prototype but I've heard it's not so hot from devs I respect. Earlier versions of dojo were dog barf and had zero documentation. dragonchild has pointed out that the current version is quite nice but I have scars from a legacy app built with an early version (which version was a mystery for quite awhile as the devs didn't even think it was necessary to include a version number anywhere in the code; sigh) and I haven't forgiven the kit yet.

Update: Ext has dual licensing. If your code is OS, it's free. If your code is closed, you have to buy dev licenses.

Any opinions or recommendations about mootools? Would you recommend to use it together with the catalyst framework? Or use it at all?