Develop Reference

JavaScript: RIA toolkit

I'm looking for JavaScript RIA toolkit. My requirements are: good look, free license and sane API. Any ideas?
Thats what I've found so far:
ExtJS
pros
perfect look
lots of widgets
support for mobile platforms
modular system
embraces HTML5 and CSS3
cons
costs money, expensive ($500+)
very flat lurning curve. no quickstart guide (but thats already doesn't matter because of point #1)
QooxDoo
cons
just ugly. looks like something that survived 90s and didn't change at all
Dojo
pros
good look (not much themes, but thundra looks good)
free licensing
cons
too asynchronous (their AMD stuff)
very unusual and cumbersome API that i can hardly call sane
messy docs (i've found out what is their AMD only from #dojo irc channel)
SproutCode
pros
MVC
generators
docs
cons
templating that i don't need
didn't find the way to put it in production w/o lots of dependencies
still can't figure out how to create RIA w/o writing own styles and layouting
Wijmo
pros
jQuery-based
cons
costs money
doesn't have layouts

If you and your team are not very experienced in JavaScript and you aren't interested in investing your and your team's time into front-end technologies then your best bet will be (prioritized order):
Ext JS
it's declarative, has MVP
since it's GPL licensed you can use it free of charge as long as you do not distribute your application outside of your organization. If you're a contractor and you give away the code copyright to your client than you client will be able to use it inside his organization.
jQuery UI + any jQuery Grid plugin (if you need it)
jQuery has a massive community
it's easier to find people familiar with jQuery
it's totally free
Yahoo UI
good community
lots of widgets, styling via CSS
best Accessibly support (if you need it)
GWT
Java-based (and many Java developers love it)
harder to debug and to build complex layouts
However, I strongly suggest you to gain some knowledge and experience with front-end technologies, especially CSS. CSS is easy as long as you research some basic rules and patterns. You don't need to become a CSS guru to be able to do styling and layout proficiently.
So if you wish to learn front-end a bit or you have some experience with it my list will be quite different. Before picking the widget library I suggest you start off with some MV* framework.
Backbone
MVP
a current trend leader, big comminity
Knockout
MVVM pattern, data bindings
suits bigger teams of people with different degree of proficiency
integration with Microsoft web stack
There are many others but the all are very similar to Backbone or Knockout
Given you've picked a framework here are your best widget choices:
jQuery UI
great integration with all MV* frameworks
Yahoo UI
best accessibility
And these libraries are very undesirable:
Ext JS
totally circumvent all normal web-development practices, doesn't respect CSS
extremely hard to customize
harder to debug
non-free in case you want to distribute your application
GWT
edit-compile-deploy-test loop is very long. Hard to work on fast speed.
hard to debug some cross-browser issues
As you can see both Ext and GWT are somewhat controversial. Use Ext if you know what are you doing, i.e. when your team isn't good at webdev and if you don't need to customize it's look and feel. In most cases some education and jQuery UI is a much better bet.

SproutCore vs. Cappuccino

Aside from the language differences Javascript vs. Objective-J what benefits does Cappuccino provide over SproutCore and vice-versa in your experiences?
In terms of a long-term forecast, is SproutCore more "supported" than Cappuccino because it is backed by Apple?
I am trying to choose between the two. I am both familiar with JavaScript and Objective-C.

This is an interesting question, and one that has been popping up fairly frequently on various messages groups, twitter, and even IRC. There's a couple of ways to evaluate SproutCore versus Cappuccino, but, perhaps, some of the immediate caparisons that people look at are the following:
1) Their respective feature set
2) Ease of use
3) Community support and documentation
Let's look at the first point -- there respective feature set. By "feature set" there's a couple of ways to look at it. From the number of UI widgets they have; the foundational support to connect things together and communicate with some kind of back-end; the framework's general architectural approach, although not necessarily a "feature", but still important; and, yes, even the language you can use.
Regarding language, I think it's important that you do not dismiss what is being used (JS versus Obj-J). Why? Because of adoption and where you are coming from. SproutCore came from the perspective that JavaScript is indeed the language of the web, so it's what you use to program against the framework. Where JavaScript lacks in language OO completeness (proper object-object inheritance, etc) it makes up for in the framework (e.g. MyApp.Foo = SC.Object.extend({...})). Cappuccino comes in from a different angle. They use Obj-J as a primary language enhancement to JS in order to inject language features that JS is missing; this instead of injecting those language features directly into the framework (Cappuccino) itself. Of course, as the folks over at Cappuccino have noted before, you can still use JS to program against Cappuccino proper, but, then, you miss out on what Obj-J provides. Note to the Cappuccino community: Please correct me if I'm wrong :-). Finally, if you're someone who is already familiar with Obj-C then Obj-J may be more your cup of tea. Hey, even Sony is apparently now jumping on the whole Obj-C bandwagon to develop against their mobile platform :-P.
Looking at the architecture of the two frameworks, they both looked at Apple's Cocoa framework for guidance/inspiration in one form or another. Cappuccino took Cocoa fully to heart and basically ported Cocoas API. Again, if you're coming from developing apps in Apple using Cocoa then you're probably going to feel right at home. SproutCore on the other hand took inspiration from Cocoa where it felt right. As for pure architecture, they both follow MVC, they both make use of Cocoa-style bindings, they both have a data store mechanism, and they both have their own respective style of rendering and composing UI widgets/views.
The rendering of views is, to me, a particular area of importance. Both frameworks have some level abstraction in order to remove you from directly dealing with CSS and HTML even though at the end of the day they have to render to what the web browser ultimately understands.
On the Cappuccino side, they completely abstract away CSS and HTML from you. Instead, you use the framework's various rendering primitives to "draw" your views. Because of this level of abstraction, Cappuccino can make use of the best rendering approach available instead of coupling you, to some degree, with CSS and HTML.
As for SproutCore, you are rendering closer to the "metal" so to speak. When doing a pure rendering of a view, you make use of a rendering context object that provides a certain degree of abstraction, but, ultimately, you are directly injecting HTML and adding class names to apply CSS. Even after your view has been rendered and you want to manipulate certain parts of the view based on an event, you can directly access to the DOM elements and manipulate their properties. Depending on where you are coming from this may seem good or bad. Good for those who are used to working with CSS and HTML and like the more direct control over how the views are rendered and styled. Bad if you want to generically render a view in order to make use of the best render approach based on what the browser allows (HTML/CSS, SVG, HTML5 canvas, etc). But, note, there are future plans to make SproutCore have a more abstract rendering approach but still allow you to directly work with HTML and CSS if you so choose. So you'll eventually get the best of both worlds.
Now, as for the stock UI widgets/views the two frameworks come with -- they both have a lot right out of the box in order to get you going. Buttons, labels, lists, segmented views, radio buttons, scrollers, etc -- they're all there. Therefore, it's safe to say you're fine in both camps.
Going all the way back, let's now discuss the ease of use. To me, ease of use is based on you own personal experience working with JavaScript, HTML, Obj-C, Cocoa, other MVC frameworks, documentation, and community support. If you've never worked with Cocoa, or never built a decktop- or iPad-like app, then it's fair to say you're going to have a bit of a learning curve no matter what framework you choose. That being said, what you don't know and want to learn can be acquired through each framework's respective community and docs. Both have active communities in one for or another, so you won't be left out in the cold if you get stuck somewhere. As for docs, Cappuccino, admittedly, has the upper hand. The docs for SproutCore are lacking, but the code base is at least fully commented. The SproutCore community is fully aware of the docs needing to be updated, and it is currently something that is being dealt with, so keep checking.
Finally, you mentioned the long-term forecast for the two frameworks. It's public knowledge that Motorola bought the Cappuccino framework, so you certainly have a big company backing its growth and longevity, or at least it seems like that way for now. As for Apple and SproutCore, I personally can't speak for them, but Apple does not own the framework. There are many companies and various individuals that all use and contribute back to the framework in some way. That might give some people and companies pause or discomfort for those who are looking at SproutCore due to the more organic nature of the framework's development, but I don't see that as a problem. My feeling is that both frameworks will be around for a long time, especially now that more are looking at developing next generation desktop and iPad apps using open source frameworks. And, hey, competition between the frameworks is good -- keeps everyone on their respective toes :-).
Hope this information helps you out with your decision!
Cheers,
Mike

I'd like to touch on the comments made about objective-j Michael.
You're not going to lose anything if you drop down to JavaScript instead of objective-j. In all actuality the distinction is kind of difficult to make, especially in cases where we have toll-free bridged classes (more on that in a bit).
Objective-j is really just a thin wrapper over js. It provides classical inheritance something that has traditionally been implemented as a language feature, which sproutcore implements as a framework feature, it also provides code importing, accessor generation, static scoping, and support for messaging nil.
Objective-j instance variables are accessible via the traditional dot syntax if you want... I like to think of it like this: once you start writing a method, you're mostly writing JavaScript. That is, loops, variables, functions, closures, etc are all just javascript. You're not losing anything by dropping down, that's exactly how the language is designed.
We take it a step further by "toll-free bridging" some of our classes CPDate, CPArray, CPException, CPString and perhaps more that I can't recall. Toll free bridging just means a CPArray IS a native js array, and a native js array is a CPArray, so you can use methods and functions of both world interchangeably.
So for example would could do:
var foo = [];
[foo addObject:"bar"];
foo.push("2nd push");
var value = foo[0];
var value2 = [foo objectAtIndex:0];
alert(value === value2); //true
As you can see I'm using objective-j syntax and js syntax together... You can imagine the power if this.
The final thing I want to put out ther, just to make sure there is no confusion: objective-j gets parsed in the browser. It doesn't need to be compiled before hand (although we provide compilation tools for when you're ready to deploy your app).
I think some people are needlessly put off by objective-j as if it's some monstrous beast that will take time to learn, and while objective-j adds a lot of great features to js, to actually learn them won't really take you the better part of a day if you're already familiar with object oriented programming, and obviously if you're coming from cocoa you'll be able to jump right in.

I wrote a blog article exactly about "cappuccino vs. sproutcore". It is not a technical comparison but compares other interesting data.
http://elii.info/2010/11/cappuccino-vs-sproutcore/

From the Cappuccino website:
"On the other end of the existing frameworks are technologies like SproutCore. While SproutCore set out with similar goals to Cappuccino, it takes a distincly different approach. It still relies on HTML, CSS, JavaScript, Prototype, and an entirely new and unique set of APIs. It also requires special development software and a cumbersome compilation step. We think this is the wrong approach.
With Cappuccino, you don't need to know HTML. You'll never write a line of CSS. You don't ever have interact with DOM. We only ask developers to learn one technology, Objective-J, and one set of APIs. Plus, these technologies are implementations of well known and well understood existing ones. Developers can leverage decades of collective experience to really accelerate the pace of building rich web applications."
So it seems that Cappuccino does not have/need any build tools, and completely abstracts the browser away from the developer. Whereas in Sproutcore you get build tools (a development server, for example) and the developer should be somewhat aware of what DOM is.

Michael Cohens answer pretty much covered everything since it was extremely detailed.
I have been struggling with a decision for the past 3 weeks. I have read everything there is out on the web about both frameworks and I have written a lot of source samples with both and still cannot make a decision. The following issues have me jumping from one framework to the other and keep making my decision tougher.
Sproutcore has a better data store api than the one cappuccino has.
Sproutcore makes use of bindings better than cappuccino currently does. Cappuccino does also have kvc/kvo support but bindings are not totally there yet. For example in sproutcore you can implement incremental loading with bindings and ArrayController very easily where on the other hand in cappuccino its not as straightforward. Of course cappuccino offers the CPTableView DataStore api which is pretty clean and can achieve similar results just not with bindings. Its what cocoa did before core data. Bindings are constantly being worked on in cappuccino though.
Cappuccino has a better view api according to my personal taste. Although I am used to developing html and the DOM I much prefer the idea of abstracting the DOM completely away and getting rid of css.
One issue that is really important to me is the lack of a good TableView in sproutcore. Currently SC.TableView is in alpha and it is not performant at all. I dont know of a timeline for the tableview in sproutcore. I tried asking on the irc sproutcore channel but got no satisfying answer. Cappuccino on the other hand has a great and very optimized table view.
I have found more real world applications written on cappuccino than on sproutcore. There is also a pretty nice full blown application that is provided by cappuccino as a source sample and is very helpful. Check out http://githubissues.heroku.com/.
Despite the fact that I have no experience in objective-c and I much prefer the pure js syntax I will probably go with cappuccino on my current project and hope sproutcore comes out with a better table view in the future.

Rich Javascript UI Frameworks, EXT, DOJO and YUI

Disclaimer & Long Winding Question Approaching
I know topics like this have been beaten to death here so suffice to say I'm not asking about which framework is better, I don't really care about opinions on the better framework. They all do pretty amazing things.
The Question
Given that I have an existing web application, made of mostly regular HTML+CSS (jQuery where needed), which is the optimal framework to integrate a few "rich" pages into typically a regular stream of HTML.
Reason
I am trying to bring our proven application into the realm of awesome desktop like UI but I want to do it one small piece, one screen at time. But for our users, support personel and especially me taking it slow is the only option.
Also, with our branding requirements having a framework that just takes over the viewport isn't an option, it has to play nice with other HTML on the screen.
Imagine the example being a rich user manager in an otherwise plain HTML+CSS environment.
Experience Thus Far
Dojo + Dijit
Pros: The new 1.5 widgets plus the claro theme is the cure for what ails us. Dojo seems to be able to use markup to create the UI which is very appealing and has a fair amount of widgets.
Cons: Holy bloated lib Batman! Dojo seems to be enormous and I have to learn a custom build system to get it to stop requesting 4,800 javascript files. This complex empire of Javascript makes me believe I won't be able to create much that isn't already there.
ExtJS
Pros: Amazing set of widgets, does everything we could possibly want. Seems quick, every version brings new improvements.
Cons: I'm not sure how to use this without the entire display being EXT. I'm still building a web site, so I would prefer something that could integrate into what we already have. Some pointers here would be great.
YUI
Pros: Well, it's Yahoo isn't it? AWS console is downright wicked. Plenty of support and a giant community.
Cons: Well, it's Yahoo isn't it? AWS console is the only wicked thing. Complex for someone who's used to jQuery.
Help Me
I am willing to accept experience, links to ways to solve problems I've outlined, new toolkits (even though I'm pretty sure I've seen most by now) or even just advice.

Regarding ExtJS, it's pretty easy to start it in an existing div with something like this:
Ext.onReady(function() {
App = new Ext.Panel({...})
App.render('div-id')
});
The App panel can then have it's own layout manager.

This might be useful if you're familiar with jQuery, but not yet familiar with YUI 3 syntax: http://www.jsrosettastone.com/
Each of the libs you listed is excellent. When embarking on a larger scale project, the quality of a lib's documentation, community, and commitment to support become more relevant.

With Dojo, keep in mind that outside of dojo base, it only ever loads what you tell it to. But yes, without a built layer, that means it could easily end up requesting 50 JS files at startup for a large application using a bunch of widgets.
There are several pages in the reference guide documenting the build script: http://www.dojotoolkit.org/reference-guide/build/index.html
Rebecca Murphey wrote a nice blog post outlining an example app and build profile that you might find illuminative: http://blog.rebeccamurphey.com/scaffolding-a-buildable-dojo-application
If you get stuck, there's likely to be people in the Dojo IRC channel that can help.
RE ExtJS: I'm not sure what your exact situation is, but keep in mind that if you're intending to use it in commercial non-open-source software, you need to pay for licenses: http://www.sencha.com/store/js/
I'm a little curious as to why you think the size / number of requests is specifically an issue with Dojo though. I haven't used the others, but I'd expect it to be somewhat of a potential concern with any of them.

How to decouple javascript programming from frameworks?

I have one question about Javascript frameworks. I'm using ExtJs on my application, but there are many problems with licensing and such things, so i wonder about this thing.
Is there a way to follow some strategies in developing Javascript so that i could easily switch from one Javascript framework to some other framework?

If you did that, I have a feeling you would have developed your own JavaScript framework. I doubt that's feasible. Better choose one at the beginning and stick with it.

I think it is never really easy to switch entirely from one Framework to another without rewriting most parts of the application. Especially the JavaScript Frameworks are extremely different. I don't really know any realistic alternative to what ExtJS offers (I know they had some licensing issues but I still don't get why commercial application developers are so hesitant to pay the 330 to 1300 $ for what the Framework has to offer. And if you Open Source it you don't have to worry about licensing anyway).
What you should do is to get rid of any JavaScript Framework specific code on the Server side (make the data transfer as generic as possible). This makes it way easier to switch to another Framework on the Client side even though you'll probably have to rewrite most of the codebase there (but only there) (I don't even see an easy way to e.g. just switch from Prototype to jQuery and they are relatively similar to each other). The only JS Framework I know that has a "Library Independent" approach is JavaScriptMVC (you can e.g. switch between native, jQuery or Prototype for underlying functionality, but even they are considering to base it entirely on jQuery for the next relase).

Let me try to blow in some fresh air into the discussion.
The major problem with many Ajax libraries and frameworks is that every and each of them have different (and proprietary as well) API. Moreover different libraries also enable and promote different programming models. This is all indeed reasonable, since there is no API standard that have all features that frameworks have to offer. However many frameworks forget that there is quite a basic API and programming model that lays in the browsers natively - XML (in simple case HTML) for layout, CSS for styling and DOM for scripting. This bundle is not only available from browsers, but also for example in Gecko XUL technology, Flex and Silverlight too.
There is a Javascript GUI Framework that brings that natural programming model back to the hands of developers - Ample SDK. Working with that you can layout your interface in a XML appliance (XHTML, XUL or SVG1.2), style the UI with CSS3-featured rules and still write code against standards-based API DOM (Level 2/3) - all cross-browser.
Having choosen for that approach you can make sure that tomorrow, when browsers have all implemented the basic features (mentioned above) equally good you can reuse lots of application javascript code, since it will then run natively!
Indeed that was part of the story - interacting with the View (although many javascript frameworks and libraries do not draw any line between M, V and C - that is the pain). Coding Javascript application is often way more than just interacting with DOM, and then MVC and PAC code architectures come in place. They have proven their efficiency, they are implementation-agnostic. Pick one implementation (as suggested by Daff - PureMVC, for example) or create your own.

ExtJs Vs Ext GWT Vs SmartGWT

I am going to start a new application which mainly consist NavigationPane, Grid, Toolbar. Layout should look like this demo page http://www.gwt-ext.com/demo/
I am quite confused which one to use in terms of writing less code, more performant, etc..
Could someone tell the pros and cons of all these technologies.
All the while I coded in javascript, so that way ExtJs seems to be the easy one for me to code. But I am curios to try GWT Ext, Is it true that it could do a lot just by writing few lines of java code.
For eg: To achieve the layout ( given in above gwt ext demo url), which one should I opt ExtJs or GWT Ext.
I read SmartGWT is relatively slower than GwtEXT. Does it have any advantage over GWT EXT. I am also looking for hibernate based data modules ( as my application is going to have many database calls). Anyone of SmartGWT or GWTExt has support for such modules. I came to know that smartgwt doesn't offer all of smartclient enterprise version functionalities, that we are allowed only a few of smartclient features. Will it be an issue?
Your response is highly appreciated.

The GWT-Ext main page now says
"GWT-Ext is no longer under active development and has been superseded by Smart GWT. Assistance will be provided to existing users of GWT-Ext looking to migrate to Smart GWT."
so why would anyone use it?

To write the least code, use SmartGWT Pro. It provides a wizard that allows you to just pick from a list of Hibernate entities you've created, and instantly you have the ability to perform all CRUD operations on that entity, no code required. Then you can add business logic.
The wizard:
http://www.smartclient.com/smartgwtee/showcase/#tools_hibernate_wizard
The link about is just screenshots, but there are several Hibernate samples in the showcase. See especially the Master-Detail Batch Load and Save sample.
As far as performance, real-world performance of most enterprise apps is dictated by how often the application has to contact the server. In this area SmartGWT has a large lead because of features like Adaptive Filtering (see the Featured area in the SmartGWT showcase).
Almost all reports we receive of SmartGWT being "slow" are due to having Firebug enabled. Disable Firebug and performance is fine, so normal end users will never perceive slowness.

About 6 months ago, we studied whether we would use ExtJS or GWT-Ext for an internal application. We wanted the back-end to be J2EE standard frameworks (struts, spring, hibernate for persistence, etc.). We ended up choosing ExtJS because it seemed to us that GWT was not stable enough (too many changes in the API that is still recent), and Ext-GWT was always lagging behind in development.

application which mainly consist NavigationPane, Grid, Toolbar.
Well, this tells us a lot about your app, doesn't it :)
I think it comes down to how good you are at either Java or JavaScript. They are quite a different languages you know :) But if you are well-versed at both but only used Ext JS, then picking up Ext GWT (or GWT Ext, if you meant that), shouldn't be such a great deal. And if that application you are planning is going to be as simple and small as your description of it, then it's probably a perfect opportunity to try out something new.

I use GWT-Ext and it is quite good especially if you don't mind tweaking things with JSNI to customize the already existing Ext widgets it is incredibly powerful. Unfortunately development is stagnant, so my future projects will probably be either in SmartGWT or Ext-GWT. SmartGWT is written by Sanjiv Jivan (same guy who wrote GWT-Ext) and it has most of the widgets we need. I must say most of the skins are quite dated except the Enterprise skin which looks good, but you can always roll your own skin.