Develop Reference

Can GWT be compared to javascript based frameworks?

How does GWT compare (or can it be compared) to Javascript frameworks such as backbone.js, angularJS, Ember, JQuery, etc.? Do they aim to accomplish the same job, making them competitors, or can they be used together?

Yes and no. While GWT's compiler is essentially a Java-to-Javascript converter, the benefits it offers far outweigh anything I've seen from any popular JS libraries.
Since GWT-based apps are written in Java, they gain many of the benefits thereof, such as being strongly typed and extremely easy to refactor. If something changes that affects another class, you know it immediately. And for those things that Java isn't great at, you can always use Javascript to handle the case with JSNI. Google has also provided a great plugin for Eclipse which allows you to debug your code like nothing I've ever seen of a JS library. Another benefit of this is that you write your client- and server-side code in the same language, and GWT does the heavy lifting of tying them together.
There are also the benefits of the automatic generation of multiple permutations. GWT kicks out a copy of your code that looks and behaves identically (inasmuch as is possible) on the most commonly used browsers. Your clients all see the same thing without you carrying the extra weight. You aren't responsible for writing endless lines of code to deal with those countless browser idiosyncrasies that have plagued web developers forever. While to some extent these things are handled by some JS libraries, GWT makes it completely effortless.
In my experience, the libraries you mentioned are all great in their own right, but simply can't provide the powerful debugging, portability, extensibility, maintainability and portability that GWT does right out of the box. GWT isn't really built to work with other libraries, and instead gives you the capacity to do (mostly) everything those libraries can without their help. (Of course that isn't to say that you can't use other libraries wherever you want...you can if you really feel the need to do so.)
So in my opinion, no, there is no competition. GWT is the figurative heavyweight champion in this arena.

Frameworks, design patterns, and libraries for building an HTML5/javascript tablet app

I would like to build an HTML5/javascript news reader for tablets. I know HTML, javascript, and CSS pretty well, and I am a proficient programmer in Python and Java. I understand generally how I would go about building this app, but I want to know if there are any frameworks, design patterns, or libraries in general that I should take advantage of to avoid doing everything from scratch.
Thanks so much for your help.

Browser compliance:
Modernizr, DOM library of choice, ES5 shim, etc. Will deal with making sure you it just works across devices and browsers.
Overall structure:
You may want to structure your codebase, either roll out your own micro framework or use existing ones like backbone, agility, spine, knockoutjs
Micro libraries:
Need some specific functionality? Go to microjs and check your not re-inventing the wheel. Or check NPM for whether it already exists.
Server side things:
There's the general unit testing frameworks, source control, server side frameworks, build environments, packagers, minifiers, etc. That you need to take care of.

I'm pretty sure there's a mobile version of jQuery. Not sure what the feature differences are besides some optimizations for touch-based interface, but jQ is pretty well-established and future developers are likely to be familiar with it.

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.

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.

GWT or DOJO or something else?

I come from the Microsoft world (and I come in peace). I want to rapidly prototype a web app and if it works out, take it live - and I don't want to use ASP.Net.
I am not sure which web application toolkit to use though. Should I use GWT, DOJO...other recommendations? I am open to any server-side language but am looking at RoR, Php or even Java (J2EE to be precise). I am not much of a Javascript/CSS guy so a toolkit that might make it relatively easy on me on those fronts would be preferable.
Also, I am a mac user at home. What IDEs go along with the framework you would recommend?
Any recommendations guys?

If you're open to doing Java, GWT is the way to go. It allows you to have a relatively uniform codebase across client-server, and to only use one language on both.
There are some limitations to doing very off-the-beaten-path AJAXy things (which GWT makes difficult, but not impossible), but it doesn't sound like that's your use case anyway.
GWT will allow you to scale up by using more of its features as your app gets more complex - and your prototype won't be throwaway code.

If you want to write the front and back end in JAVA, and want to do complex ajax type thing, then GWT is a great way to go.
The easiest way to think about it is that building a GWT app is kind of like building a JAVA swing application that hooks into a server. Just like a swing app that uses a server you can make it fat or thin. When you're done it all compiles down into HTML and javascript, and has very good modern browser support (ie6+ ff, opera, safari).
It does abstract all the javascript and HTML away, but if you want it to look good you'll still need to understand CSS.
I think anyone who says that that it ruins MVC or that it's a muddying of client vs server doesn't understand GWT. GWT is a CLIENT side framework. And it is only used on the CLIENT. GWT does provide an RPC mechanism to hook it into JAVA (and other) back ends, but that's just a communication protocol, it doesn't mean that your server code magically becomes your client code. Sure you can write a whole bunch of business rules into your UI if you really wanted to, but you can do this with any framework, so it would be silly to say that GWT is somehow different in that respect.

GWT is a good choice, while if you choose more powerful JavaScript framework based on GWT (e.g. SmartGWT), the compiled stuff is too heavyweight.
Choose direct JavaScript if you need a compact project.

I am a fan of GWT, however I am very familiar with Java. I found it to be intuitive, and surprisingly easy to get good results quickly. If you are to use GWT, then you'll definitely want to use the free, and immensely powerful Eclipse IDE.
One disadvantage of GWT is that it requires Javascript to be supported by the browser, there is no "graceful degradation".

We have evaluate a large list of frameworks and have decide us for Echo2.
You need only to code in Java. Javascript you need only if you want write your own components.
There are no startup performance problems with large projects like GWT.
You can use the full range of Java in your client code because it run on the server. In GWT you can use only very small set of Java classes.
The IDE for Java is Eclipse. This is independent of the used framework.

I'm a fan of jQuery, the chainability of actions, traversals, and commands is really powerful. A good friend of mine is crazy about Mootools, he works at a Java shop FWIW. He mentioned a cool feature of Mootools is that you can specify the functionality you want the framework to include and it will generate the entire library on a single line in a file that you can include on your page to minimize the weight of the framework (pretty cool feature). Really it just depends on what you are most comfortable with. jQuery has great tutorials, is super fast, and can be used along with other javascript frameworks.

Not related to GWT, but have you considered other backends that GWT could work nicely with?
Grails is one backend that ties quite nicely with GWT.

Personally, I would avoid server-side frameworks that try to embed or hide the client-side framework. I'm sure that GWT is great for getting something going quickly, and is probably fine for certain kinds of applications, but you'll probably run into lots of problems "on the edges" for more complex applications. Decoupling the client framework from the server-side framework avoids those problems.