Related
I have what I think might be a strange question to ask.
Recently I was playing with some java web frameworks (jsf with primefaces) and I noticed that it's quite good at handling form data or when you play along with the jsf components. I also did a project using grails and again it was useful for form data.
But the moment you want to do something which requires a little deviation; then I found myself doing weird things (examples are tag clouds with large strength values using primefaces and single page webapp forms with grails).
This resulted in some very messy html+javascript code for my grails things(which I blame on my inexperience with javascript). This was done because I was using expression language (grails in this case) to populate some of the javascript. The worst part was that I had a bunch of custom javascript code inline with my server pages (I could of refactored a little out but I think one would still have alot of javascript calls inside a single page).
So now to the question(s) :)
[main question] Are there any resources that demonstrates how to design or at least implement maintainable javascript with server pages (gsp, xhtml, etc) ?
The reason is that I find that there are some neat javascript frameworks, but using them with server pages seems a bit unnatural if one takes into account the expression languages for server side frameworks? Unless it's normal to do this type of thing :) ?
Are there appropriate frameworks for Single page webapps using java?
My current answer is that GWT, Vaadin (based off GWT) and perhaps JavaFX qualify. Maybe ZK, Flex and (Grails/Roo + Flex/GWT) also qualify as well?
Are java web frameworks still useful for presentation layers?
My current answer is that they might be when you are dealing with portal type webapps or Web 1.0 apps for lack of a better word. The other case is that they could be when you use alot of role based security and you want to filter things out based on roles, but even that has counter arguments.
My other answer to this is that it might be better to use a java server to provide your web services and then rely on something else to do the front end?
This might be OP, but for single page apps, it's easier to serve up data from the server via JSON(P)/XML/whatever and then use things like Backbone to process and modify the view(s) accordingly. That way, the server can use REST/SOAP/websockets/whatever, and the browser app becomes a full-fledged app.
I haven't actually done this, so don't quote me, but I imagine that it should make sense.
I saw some other similar questions on this topic here but they were not very helpful so I a posing this question.
What is the fastest way to convert a reasonably sized, simple web app to a Java desk top based client targeted for pc and mac? Unfortunately I can not share a whole lot of details about the app here due to various reasons. The most complicated UI in the app though is a page that contains a multi level threaded discussions (please see here for an illustrative example of what I am talking about.) The current web app is based on python so I can not re use anything from the server side code (dont think this is an issue)
I have never done any swing or awt or any other Java based thick client GUI work. My thinking is more or less defined by web based applications. I am capable of doing end to end web app development (including backend and decent UI using HTML, CSS and JS) using Java or python. For your answers please focus on Java solutions only.
So here are my questions
What is the best framework or tool I should use? I found some of the following tools on the web as part of my research.
Awt - does not look like this is a good choice.
Swing which I believe is bundled with regular Java SDK/JRE. - This may be my best
bet.
SWT which seems to compliment Swing in some fashion.
Griffon based on an article here. This framework uses Groovy ( I
have no clue about Groovy, btw) Adobe Air flex. Any open source
frameworks?
What are some of the other issues that I need to keep in mind? Some that I would like your comments on are:
How does the fact that it needs to be deployed on the client complicates things? Since we are using Java, I believe this to be a non issue. I am aware of the usual trade offs between a web based app and a desktop app (e.g. ease of deployment and upgrades etc etc.)
How easy is it to create a one click installer and bundle the app and the environment needed - eg. JRE etc?
The product needs to work on Mac and Windows. Does that complicate things in any way (Again, since it is Java I am assuming there are no gotchas but would like to be forewarned if there are any)
What is the framework or technology that may be good to have on the resume as a skill set?
My deadline is a max of 2 months - would that be enough for a reasonably simple web app given that I need to learn all of these technologies? I am just trying to get a sense here - I know it is most likely impossible to give an accurate answer - just assume I am smart enough and can pick up any unfamiliar tech stack fast enough.
Thank you!
GUI toolkit
Given "Mac and Windows", I'd say that settles my recommendation as "Swing" (perhaps with SwingX1).
I agree with your assessment of AWT. It does not support formatted text in any component out-of-the-box. It also lacks trees, tables (and other components) & people with recent experience using it. Note though, that it is also "bundled with regular Java SDK/JRE" just like Swing, it is just that it is older and less enabled than Swing generally.
If anything complements Swing it would be SwingX. SwingX is built on Swing and provides advanced controls that are not available 'out of the box' in the J2SE.
Swing and SWT are mutually incompatible - use one or the other.
I have no experience with Griffon.
Swing is the most used of the options outlined, so for getting help (ignoring other potentially important factors in the decision), it would be a good choice.
Note 1) Add SwingX if they have any groovy components that present threaded conversations easily, but I suspect a JTextPane would suffice.
Deployment
As far as deployment goes, that is a little more tricky than it seems. Many desktop computers do not come with Java as standard. Those that already have it, might have an old version.
To ensure a JRE of the right minimum version to run the app. is available, use the deployJava.js (mentioned, with links, in the JWS page below).
To provide a 'one click' launch experience for the user, look to Java Web Start.
Cross-platform gotcha's
Unfortunately, though Java is x-plat, there are plenty of things that programmers can do that stuff that up. E.G.
Not accounting for the platform default:
File encoding (file.encoding2)
Line break (line.separator2)
File separator (file.separator2)
Coding fixed size ('absolute layout') apps. that will be shown as different sized apps. on other OS.
...
Note 2. That is showing the property to use for each.
Timetable
Obviously I cannot speak for you, but I can tell you that I would have had no chance of going from 'which technology' to a 'deployable app' within two months.
Hope you're more capable than me! ;)
You said that you wanted a Java solution, but be aware that there are plenty of Gui options in Python, and you already have your web application written in Python.
Groovy is a different programming language than Java, but Groovy runs on the JVM. Do you want a Java solution or a JVM solution? I ask because you mention Griffon.
Assuming you want Java, I think your main options are Swing, SWT, JavaFX 2, and Apache Pivot. Oracle has said that they intend for JavaFX to replace Swing as the GUI platform of choice. That said, JavaFX 2 is in its infancy, and only a preview release is available for Mac right now. The upshot of JavaFX and Apache Pivot is that you could use the same code for your web application as your desktop application.
You can try doing so in small steps:
* As a first step you can create an applications with SWT and embed your application in a browser control.
* Then you should move pages and some controls from the web app to the desktop one by one.
In this way you can get a minimal application in hours :)
P.S. If you want an iOS app with this approach it's worth looking at this open source project: http://en.wikipedia.org/wiki/PhoneGap
One of the main strength of GWT is to code in java and everything gets compiled and is loaded by several browsers through gwt deferred binding??
Apart from this, i.e. working only on a single code base, do GWT has any other advantage compared to other existing framework??
Edit:
I'm trying to say why should we use gwt and not another framework?? What is there in GWT that makes it special for web application development?? What GWT makes for us and another framework or toolkit don't do??
As i said above GWT makes deferred binding which is a plus, so I wanted what other things it do that makes it special and unique??
My point of view :
Pure Java : In standard web application you write html, css, php, javascript, mysql and others and others. In gwt you write java and java and java. Pure Java knowledge is enough for everything.
gwt-rpc mechanism is very simple to communicate with server and uibinder or any other tools are enough for ui development. plus there are many widgets that facilitate front-end developing
Debug : Debugging Java code is very very easy than debugging Javascript code
MVP Development with Activities and Places
Compiler that you can do all the thing, that you can do in Javascript, in GWT. In addition, working with JSON and XML is very easy and History management is unbleviable
and at last I'm a big big fan of Google and they did it so they did the right thing
One of the other benefits of GWT is that you can share code between the client and server components of your app. For example, if you're doing a graphical app you can write computational geometry code and have the same code evaluate on both sides. Of course, you can also do the same thing by using server-side Javascript (for example, Node.js), but server-side Java has serious advantages for performance, ease of deployment, and interoperability with other things.
My favorite benefit is their RPC mechanisms. JSON gives you a huge reduction in payload size, but GWT's serialization policies allow the data to be sent over the wire without key labels for each value and reduces payload size by another 30% or so. On top of that, its easy to build those services using Spring and Hibernate.
Another benefit is the use of md5 hashes for the filenames of compiled JavaScript, allowing you to set never expires cache headers for all of your code.
Last but not least (actually, it is the least cool of the benefits), there are free tools now for GUI design so you don't have to build a GUI by writing XML and Java or HTML and CSS.
GWT follows a principle of no compromise high-performance Javascript.
They have already invested a lot of work into making your application highly performant. For instance, the "compiled" Javascript files it generates are actually .html files. This is due to an issue that some browsers do not correctly support compressed .js files. This sort of tweaking is beyond what most people would do manually.
There are easy to use tools to help you improve the performance of your own application. GWT.runAsync, for instance, allows you to define splitting points in your Javascript which will be used to automatically divide up monolithic Javascript files into bite sized chunks to load.
As has been said, the RPC mechanism performance and ease of design is amazing. MD5 hash based names for the compiled Javascript means for great caching.
My biggest plus for GWT still has to be the debugging capabilities. Javascript debugging has always been messy and frustrating. With GWT you can employ the full debugging facilities of Java when working on your client side code.
There are no simple answers to these questions:
I'm trying to say why should we use
gwt and not another framework?? What
is there in GWT that makes it special
for web application development?? What
GWT makes for us and another framework
or toolkit don't do??
There is no silver bullet. Everything depends on the project and requirements. GWT may be good in one project and other frameworks may be good in other projects. It also depends which other frameworks are taken into account.
In my opinion the most significant element which makes GWT different from almost all other Java web frameworks is that the client side is fully in JavaScript while most of other frameworks generate usually plain HTML code. The JavaScript approach to the client has its benefits, to name a few:
it is fully AJAX which creates great user experience,
views state is managed in the browser,
it communicates with the server asynchronously;
it communicates with the server only to get the datal
However, there are also some drawbacks:
browser history support - it isn't as good as in HTML based frameworks; proper use of history mechanism isn't easy and requires extra effort from developers;
applications aren't SEO friendly;
more complicated page layouts may kill web browsers - sometimes it takes a long time to generate a page, especially when using additional component libraries;
For developers it is very important that GWT hides JS from them. You write in Java and you get fully working AJAX based client application in JS usually without touching a single line of JS. This is great especially when you need a lot of AJAX in your application and you don't know JS. This is specific to GWT - using JS and AJAX in other frameworks isn't usually that easy (Vaadin may be an exception but it is GWT based).
It is worth mentioning that in many cases GWT can be combined with other web frameworks - this way you can have most of you application content created in HTML based frameworks and some more complicated AJAX parts in GWT.
If you want a recent comparison of Java Web Frameworks, here is an interesting presentation from Devoxx 2010 :
http://raibledesigns.com/rd/entry/my_comparing_jvm_web_frameworks
I'm a full time Java developer of around 4 years, professionally. I'm a GWT fanatic. I love Java. Here's the problem: In my free time I often fall victim to the verbosity of my favorite tools for doing "heavy" development. I also often fall into the trap of obsessively engineering my software. I'll end up with the most beautiful unfinished implementation, ever.
So, here's what I normally work with.
GWT - I use this for dynamic UI and web layout. I love the ease of re-use and it has taught me to absolutely hate javascript. I really can't even bring myself to do much HTML/JS anymore.
Hibernate - POJO to Database, easy-peasy. What i really need from this other than the mapping is that it allows me to have an application that works across multiple databases.
Spring - Mostly security. I've written my own custom LDAP bits for a project.
XML - I've used dom4j and other implementations, including xstreamer. I'd like to use JiBX for XML transport. The problem with this is that I need XML messages that conform to a specific standard rather than being autogenerated. Object->XML->Object are also common enough that it can be a performance bottleneck with large messages (250KB+).
I tried Lombok for a little while and liked it but had occasional issues with it and then I blew up a partition and lost all that work. I don't really feel like doing the same thing again (half the fun was in learning how to do it, now that I know... meh). This taught me why other people want to reduce the explicit code and replace it with an implicit system.
I've been looking into Grails but that runs me into the JavaScript problem (you know, that I don't like it) pretty quickly. I could use GWT with Grails on the back end but I get back into the problem of getting deep in the weeds with GWT. It has also occurred to me that there might be a way to have Grails tags in GSP that are made up of GWT widgets. I'm not really sure how I feel about that.
Another problem I have with Grails is that validation logic before form submission is separated from validation constraints after submission. I don't see how they can be unified (yet) to produce "pretty" front-end validation. I went out of my way to start a JSR-303 compliant validation project for GWT to help solve some of this problem for GWT and really liked the results. It isn't finished but I still find it useful.
So, help me find a better way!
TL;DR - I want to have a Database (and Database-Independent) to GUI solution that allows for dynamic web programming all in one language. Failing that, as close to one language as possible.
TL;DR is TL;DR - I hate JavaScript now, help.
EDIT: I know that it is techincally impossible to do "Web 2.0" development without JavaScript. I'm just trying to not be the guy who has to write it. (Getting a tool such as GWT to do it for me from a language I do like, for example.)
Just learn JavaScript.
Resistance is Futile
...and you will be assimilated.
PD: I'm an ex JavaScript enemy. Now it's my favourite language.
You can certainly develop an entire Web 2.0 project without coding Javascript using GWT (we have), but at the end of the day you still have to know HTML/CSS & Javascript.
This might sound like a stupid statement, but it's not once you consider that GWT is not a perfect abstraction, nor is it designed to be. It wasn't written in Java so that you didn't have to ever code in Javascript again, instead they did it because Java has better IDE's, is statically typed and makes maintenance a hell of a lot easier.
So yes, by all means go with GWT (and check out the new OOPHM, because it's AWESOME) but don't forget that you'll always need an understanding of the underlying frameworks of the web, if you want to develop for the web.
Have you heard of Echo?
It doesn't provide the database part of the problem, but it would work well with any database that you can work well with.
Echo is a platform for building
web-based applications that approach
the capabilities of rich clients. The
applications are developed using a
component-oriented and event-driven
API, eliminating the need to deal with
the "page-based" nature of browsers.
To the developer, Echo works just like
a user interface toolkit.
The latest iteration, Echo3, features
the ability to write applications in
either server-side Java or client-side
JavaScript. Server-side applications
run in any Java Servlet Container and
do not require developer knowledge of
HTML, HTTP, or JavaScript.
You might want to take a look at some of the AJAX powered JSF libraries. IceFaces and RichFaces are both solid.
Been there, done that. I was a GWT developer for 3 years... I started using it in v1.1! GWT is fantastic, and works really well for small applications. But the development comes to a crawl once you it a moderate application size, even if you divide your application in sub-modules.
It is also quite ironic that a UI framework has such limited UI creation tools. :)
Personally I bit the bullet and learned javascript. It isn't as bad as I thought. Especially with jQuery. :)
Obviously there is no perfect framework. But just the fact that GWT has been out for 3.5 years now, and it still largerly ignored in the Java world should tell you something. Since you're doing this on your free time, I would recommend learning the most popular framework: Struts. You'll see its limitation, and also why it is so popular. Of course, you'll need jQuery for that 2.0 functionalities. :)
Take a look at JRapid, a rapid development platform for Java developers. It generates very powerful Ajax enabled UI without the need of coding.
Not sure if you would like this , but have you heard about Haxe?
You might not like it but its AIO (all in one) solution (sort of).
I can understand your dislike of JavaScript and it certainly has its problems but I think your fighting nature at this point.
Web 2.0 is strongly based on JavaScript for a good reason as it provides the ability to perform tasks on the client machine without requiring page loads.
I'm sure there are alternatives but if you want the look and feel of Web 2.0, you will end up doing a lot more work with little reward. JavaScript is the accepted and functional tool for the job.
I'd say stick with GWT and just drink more of the Koolaid. It's a completely awesome development model that seems to be lost on those who haven't tried it.
If you want to improve your GWT experience, jump to the bleeding edge (I work off trunk, it's quite stable) and use the other Google originated projects like GIN, gwt-incubator and Guice. Especially watch Ray Ryan's GWT best-practices Google I/O talk: http://www.youtube.com/watch?v=PDuhR18-EdM
As for the "framework" part: forget 'em. Just use normal servlets and let GWT take care of the RPC for you. Servlets are a pain when you have to deal with JSP and you're own AJAX calls, but when they're only implementing asynchronous app logic, it's not that bad at all. Guice Servlet makes it all quite easy. You can still use a JVM hosted language to write your servlets if you want.
GWT has an incredible advantage over other JavaScript frameworks in that the layer of abstraction it provides allows for major future advances without any changes to your code. If the GWT compiler and browser detection scripts can take advantage of new browser features then you benefit from a simple recompile.
The big annoyance I see in your requirements in XML... hopefully that's just for integration with a 3rd party service and your client-server communication can just be GWT-RPC.
I don't use javascript or ajax, in medium-large application they create a lot of problem with compatibility, because moving some part of code inside client, create security breaches and problem with different browser.
I use only HTML(5) and CSS2/CSS3, and I have a lot successes.
I use this 2 ways:
using "puzzle-techinque". Write a lot of small and simple template (or tiles) to create the big page. I use only JSTL and Spring tag, with Rich/Prime/Ice-faces I encountered a lot of problem with rendering, page building and flow controller, so I discarded them.
using my custom library to parse HTML pages. I create template with my custom grammar, put inside the parser and write on output stream. This is the best way.
If you say me your preferred language and context, I can help you to perform JS-free.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Question for all the GWT gurus out there - which is the best GWT widgets library out there? And why?
List based on the answers:
Default
Sencha GXT
Smart GWT
Vaadin
GWT-Bootstrap
GwtBootstrap3
Rocket GWT (inactive)
Tatami (inactive)
ErraiFramework
GWTMaterialDesign
И наконец- новое поколение основанное на JsInterop:
GWT + Polymer Elements
GWT + Polymer
Angular and GWT
GWTMaterialDesign
Do not bind yourself to ANY of these libraries. Use Vanilla GWT to create the structure of your project. In particular, use the MVP pattern and an Event Bus. Please, see google article to know how to best design your client application with GWT: Building MVP apps
After, you can use any widget of these libraries (say a table, or a combobox, a datepicker, etc) and incorporate it to your project. Try to use extended components ONLY if you don't see a way to do it with vanilla GWT. This way you don't tie yourself to these libraries which are ALWAYS a pain when you try to do something that doesn't appear in the demo application, contain many bugs and their support are poor at best.
How to look for widgets should follow this order:
First check GWT Incubator to see if
there's what I'm looking for.
http://code.google.com/p/google-web-toolkit-incubator/
Then, if you are looking for
something "cooler" check GWT Mosaic
http://code.google.com/p/gwt-mosaic/
Careful with other libraries, I've worked with them (and still have nightmares).
Depends on what you mean by "best". Best looking? Best API? Best for extending to your own custom needs?
E.g., I was just evaluating table classes to use in our application. We've been using GWT-Ext, but it has many performance problems for us, and is very hard to get the tables sized the way we need them. I came very close to going with GWT-Mosaic, but decided instead to build off the widgets in the GWT Incubator.
So, why did I make this choice? It seems that too many of the libraries out there come with their own, for lack of a better word, baggage. Either you have to dive whole-hog into some MVC framework (which may not be entirely compatible with the rest of your code base), or you have to adopt someone's new fangled layout system, or you have to live with the fact that you cannot really debug the code (because its just JSNI wrappers).
Don't get me wrong, the GWT Incubator isn't perfect...the widgets there are in some amount of flux. In my case, this was the best choice, though. It gives me good (but definitely not perfect):
API
Extensibility
Look and feel (well, this is kinda weak, but that's what CSS is for.)
So...the answer (for me) is a combination of:
Stock GWT widgets (with lots of custom styling)
GWT Incubator tables
A few home-grown widgets
(I should add: the "baggage" I'm referring to isn't necessarily a bad thing. But, if you just want a widget or two, it can raise the bar on what it takes to just get your work done and how good youe application looks.)
See this component library GWT Bootstrap this is a implementation in gwt of Twitter Bootstrap.
GWT alone is a pretty good library.
I didn't use all of the mentioned ones but can recommend Ext GWT.
I prefer vanilla GWT.
Some of the other APIs look pretty and their showcases really show off the widgets, but I always find that the performance isn't the best....when I say performance I mean more like response time. I hate when an application feels sluggish.
Most of the libraries mentioned are not open source and even worse: are just wrappers on top of a JavaScript library. The power of GWT lies in the fact that the application works on different browsers (because of the code generation for the "big" browsers specifically). These JavaScript underlying libraries can cause lots of problems.
I agree with jgindin GWT Incubator and GWT Mosaic are the best so far.
Not saying it's "the best", but I've been using GWT-Ext at work lately. It's got some pros and cons:
Pros:
Relatively easy to setup and use
Decent sized community behind it
LOTS of examples online, all of which have accompanying code
Good selection of widgets that cover a wide range of functionality
Cons:
Makes assumptions about your data's format and structure that you may not be able to accommodate
Library is just a JSNI wrapper, which makes it harder to debug and extend
Future support and development on the library is uncertain
Some annoying cross-browser issues still exist (especially with layouts)
Search function on their forums is essentially useless. (This is becoming a big pet peeve of mine >_<)
Do NOT use any of them! If you plan to develop a large scale application, you should consider using MVP pattern. The best implementation around is MVP4G framework, it supports GWT code splitting out of box. There are a lot of great examples, you can start with. The most valuable one is Mvp4GModules.
Add the new one: GWT-Bootstrap :)
There isnt a stable release right now, but will have soon.
My experience shows that there are always many problems with 3rd party libraries. The best way - is to use well-known and well-maked technology itself plus your own components. It may take a longer time to write and maintain them, but TCO is always at lower level.
3rd party libraries often can break your plans unexpectedly. And it's hard to find and fix the source of problem.
So I'd suggest to use plain GWT.
I think SmartGWT is fine if you just whant to use the Widgets as they are,
but if you would like to extend or modify the widgets as I do in
the Gxt Scheduler I think that Ext-GWT is a better choice.
for me EXT-GWT (aka GXT) is the best library currently available,I use it in 6 months project,and it helps a lot with many predefined components like grids,trees....
It's beautiful as well
SmartGWT is a good library and it has a lot of examples but the user interface is not that sleek. For user interface Ext GWT is good.
gwt-mosaic's user group doesn't seem very active and I couldn't find a user's manual besides the wiki snippets. gwt-mosaic introduced me to two interesting tools.
1) gwt-mosaic includes a wrapper for Tibco's PageBus which is a publish/subscribe tool for the JS parts of your app (RPC handlers, widget callbacks, widget setters). This is an alternative to gwt's event bus.
2) gwt-mosaic encourages the use of Beans Binding (http://code.google.com/p/gwt-beans-binding/) for binding data to widgets and validating widgets.
smartgwt isn't cheap for the full feature set and support. The jar is too large for appengine unless you remove the theme files you don't use. They invest engineering on the server side too.
I've heard ext-gwt is sluggish and the JS files are large.
The gwt widget incubator looks deprecated. I believe the deluxe grid will be released with the new gwt.
The lack of look-and-feel, binding, and validation standards is hampering the interoperability of widget libraries.
Definitely not SmartGWT. Their framework is bloated and has a very half-baked nature. They have a million widgets, but trying to get them to work for your project is not easy. Datasources complicate the process of managing your data in a very big way, for example, in order to get to data in your datasource, you must use fecth and inspect often. While you can cache the results, it is not always easy to interrogate them.
RPC is another weak and convoluted area. There is contradicting information in the documentation and in the forums. While the documentation will say that you should rarely use a custom operation as part of a ds, they forum will tell you that it's perfectly fine. Learning to use these tools effectively is an uphill climb on the best of days.
They will oversell the product. For example, the charting/analytics package contains graphs... But those graphs won't display negative values or let you manipulate axis labels in any meaningful way. And they openly respond to queries about this on the forum with a "yeah so what" attitude. "We don't plan on adding that to 3.0x even though that's one of our selling points, it's on our road map." When they sold me the package, they never mentioned that I couldn't display negative values. Really? What graph would not need to be able to show negative values? I can think of only one- the one depicting the number of unhappy Isomorphic customers.
Stay away from these guys, and head over to any competitor's site, for example ExtJS, JQuery, heck even quxdoo. There are a few projects out there that are really gaining ground and actually offer a good solution.
Take great caution if you ever evaluate this product. It looks nice, but about two weeks in to the project using it, you'll start seeing what I mean. Widgets are half baked, datasources are extremely over complicated, and just because you paid for forum support, doesn't mean you'll actually get anything other than snide, condescending answers that at first will make you think you missed something. You didn't they're generally very arrogant.
Best of luck, and stay away from this product if you value your development time and maintainability. Oh and one last thing. Look at the MVC example on their web site. It has literally nothing to do with MVC other than the label reads "MVC". They'll try to convince you that such frameworks are for inexperienced developers, and that such a concept has no place in real programming... Kinda like those try catch blocks.
Google's default library is the most powerful library.
Ext GWT adds bells and whistles but apart from that it's similar to Google's.
We're currently liking the GWT Mosaic widgets. We've worked with ext-JS and we've rolled our own widgets in the past. ext-JS licensing and bulk were a problem for us. Rolling our own isn't what we want to do. Mosaic gives us a happy middle ground which we like to think will be an even happier middle ground as the project matures.
I would say if you need only a few widgets then build your own. You might copy-paste some concepts from the libraries mentioned. But they all lack one or the other thing.
I have played with most of them and abandoned every one.
One thing to be aware of is that from the forums GWT-Ext looks like it will no longer be developed/maintained much (maybe not at all?). On their website they recommend migrating to SmartGWT.
Didn't see this one mentioned, Vaadin (previously known is IT Mill Toolkit), but maybe that's because it's not technically exactly GWT; as their FAQ says:
How does this differ from GWT?
GWT applications run in the browser,
while Vaadin applications run on the
server. We do actually use GWT as a
"rendering engine" on the browser
side, so you can combine Vaadin and
GWT.
smartGWT is slow and examples are lacking and it is very hard to find answers for even the basic questions, i.e. see all my non answered questions on this forum.
I'm dumping smartgwt.
Comparison of the two EXTs here with pros and cons.
We have built a large HR portal and a couple of smaller applications using GWT Portlets. The focus of the project is not so much on building a collection of widgets but on creating a simple programming model.
From the website:
GWT Portlets is a free open source web framework for building GWT (Google Web Toolkit) applications. It defines a very simple & productive, yet powerful programming model to build good looking, modular GWT applications.
The programming model is somewhat similar to writing JSR168 portlets for a portal server (Liferay, JBoss Portal etc.). The "portal" is your application built using the GWT Portlets framework as a library. Application functionality is developed as loosely coupled Portlets each with an optional server side DataProvider.
I am using GWT for a year. After lots of research, I have decided GWT Mosaic as a widget library.. Mosaic uses some of the GWT incubator components such as PagingScrollTable.. But the features of the combobox and table are not sufficient for us.. That is why, we have extended these components to add needed functionality.
Check out SpiffyUI: www.spiffyui.org
It is not just a widget library but complex UI/UX GWT framework.
Two important things -and what the most of libraries miss- are unit testing and debugging. It is where GWT shines. If you use a library which is based on vanilla js, you give away the ability to unit test and debug your project. As a GWT developer you should consider these points and use a library with no or minimal js dependency.
We've been doing gwt projects for more than 2 years, and we stick to the default widgets. We made our own open source library to autopopulate the default ones or our own widget extensions. Please check it, it's called gwt-jet. It's very well tested since we use it in large production environments, and we hope it will grow safely thru time.