Related
What are the pros and cons of echo3 framework compared to other java web frameworks?
Echo3 is still under development. Echo2 is stable (but old). The main "pro" is that you don't write javascript or html, you write Java GUI code. The main "con" is that it has not been widely adopted. I've used Echo2 5 years ago and it was a nice framework, but the development of Echo3 is slow (thought it has not stopped).
Perhaps it is worth taking a look at other similar frameworks like GWT or Vaadin.
These (Echo, GWT, Vaadin) differ from traditional frameworks (like spring mvc, struts, wicket) in the fact that you don't write HTML, css and javascript. That's why they are more suitable for highly-interactive web-applications that would resemble a desktop application. If you, for example, need to have bookmarkable URLs, want to rely on browser navigation and such browser-intrinsic things, don't go for Echo/GWT/Vaadin (although they do provide some support for these things)
I went to the Echo3 website and found an argument that discouraged me from testing it. It seems that it is a dead project:
the current version of Echo3 is 3.0.beta8, released August 6, 2009
Technically, I don't know...
Recently the final 3.0.1 version has been released. A 3.1 version (with WebSocket integration etc.) is just around the corner.
The original creator/maintainer has all but dissapeared, but there are considerable community efforts in reviving the project (and make it less dependent on a single (albeit very gifted) person).
Old question, but some people may still ask it...
I've been working with Echo3 for some time now, and the biggest problems are indeed that is is not widely adopted, as already mentioned and that the development progresses very slow.
When choosing a framework, you normally limit yourself to it's technologies, and Echo3 simply lacks a few things that I always missed in my projects. For example, the Echo3 table component offers no scrolling, no pagination and no sorting. And a table is one of the most important a components a framework can offer (Echolot has a nice table component, but it only supports text values and currently has no sorting).
So have a good look at the Echo3 showcase at http://demo.nextapp.com/echo3csjs/ and at the widget libraries at http://echo.nextapp.com/site/echo3/addons and see if that is enough for you.
Also, it changes the way you can design and layout your applications. Echo3 gives you the usual desktop components, like rows, columns, grids and panels. However, it doesn't offer layout manager concepts like Swing does and also does not have any CSS support. When having to follow exact design rules which involve exact positionings and behaviours of components you might have trouble doing this with Echo3.
I am torn between Wicket and Vaadin. I am starting a micro-isv and need to make a choice of web framework. I have narrowed down my choices to Wicket and Vaadin. I have used both frameworks and I love them both. however I need to make a choice.
If If I choose Vaadin:
I wont have to worry much about the look and feel. It comes with nice themes.
I will do all my programming in Java which am very good at and wont have to spend time hacking CSS which am not very good at.
And most of the components that I will need for a business applications are there OUT OF THE BOX including, desktop like layout, tooltips, Keyboard shortcuts, tables with draggable and collapsible columns to name a few.
However, if I go the Vaadin way:
I will loose the ability to create UI declaratively.
I wont have the fallback feature if the browser doesn't support JavaScript - e.g most non Webkit mobile browsers.
Vaadin company is selling some components - e.g the JPAContainer so am not sure the company will be committed to offering full open-source framework. Business interests will always come first.
Vaadin applications will be mostly for the intranet. They are not very suitable for the internet with a web look and feel.
If I go the Wicket way:
I will have to style my applications and I can hardly give them a desktop look and feel.
Any advice? Anyone with experience on either framework kindly tell me the cons and pros and how you made your decision.
I think I've invested some time for both frameworks. I really like both because they bring the Swing-alike coding to web development. And I don't know easier ones for me (although there is click but I don't like the velocity templating thing)
And yes, there are differences.
I wont have to worry much about the look and feel.It comes with nice themes
true, but every serious company will style its app differently (unless you are prototyping)
I will do all my programming in java which am very good at and wont have to spend time hacking css which am not very good at
Then Vaadin would be 'better'.
i will loose the ability to create UI declaratively.
What are the advantages of that? (BTW: you could code declarative in groovy ;-))
But ok. I know what you mean: if you can afford a few separate designers then wicket is 'better'.
i can hardly give them a desktop look and feel.
Why not? Or what do you mean here? Wicket supports ajax and there are components which supports nice 'desktop-alike' things (ajaxlink, lazycomponent, autocompletion, progressbar, see wicket stuff + extensions). ok, for any more complex component you'll have to code in javascript BUT BTW did you know that you could even use GWT within wicket
Some minor experiences:
Vaadin is surely faster while coding (no css, html stuff). But if you go production keep in mind that the ease of programming can come to the cost of performance on the client side: e.g. if you use the 'wrong' layouts such as Horizontal/VerticalLayout, ... the massive use of javascript could slow down old browser.
But Vaadin is not slow! Use appropriate layouts such as CssLayout or FastLayout and also old browser can serve it. (Although if you would use CssLayout your coding-style is really wicket-alike.)
One issue with Vaadin is that it is a bit harder to profile, because you don't see easily where the client needs all the CPU and the nested divs gets cryptic id-names.
One great thing about Wicket is its warp persist integration
(Guice can be integrated in Vaadin and Wicket)
Testing the UI should be easy with Vaadin (although I didn't found unit testing stuff) and is very easy with wicket.
Last but not least creating lists/tables is VERY easy in Vaadin compared to wicket.
I've worked extensively with Wicket but I've not had any experience with Vaadin so this might be (a little) biased.
I'd recommend Wicket for obvious reasons, but what's probably of interest to you is Wickets openness. As Gweebz rightly pointed out, Wicket uses basic HTML markup as its foundation, so any structural or cosmetic changes are often trivial to implement.
Personally one of the things I really enjoy about out wicket work is the flow between front end presentation and the data backend, we've implemented Spring & JPA/Hibernate which means that any changes in the front end can be translated back into the data base with a single line of code thanks to Wickets model based architecture.
Again I can't say much for Vaadin having never worked with it, but if you're looking for architectures to start off with, I'd also recommend you have a look at GWT.
(continued from the comment in the first Wicket-related answer)
The major difference between Vaadin and Wicket is with how UI composition and client side code is written. With Vaadin you usually compose your UI without any templates or HTML at all and you get a sleek, fully Ajax'ed UI out of the box. However, if you prefer the templating approach just use CustomLayout which does exactly that.
Client side coding is rarely needed, but when it is you do it with the Java-based GWT which is IMO a lot more nicer than writing Javascript by hand. Besides, with GWT you automatically get cross-browser compliant solution instead of having to deal with those issues yourself.
When comparing frameworks you also should take a look at community activity and documentation. With Vaadin both of those are excellent. Also note the Vaadin Directory which currently contains 100+ very useful UI components and other addons.
I have a limited amount of experience with each but I prefer Vaadin. It allowed a richer experience with the web application I was developing. The main benefit that sold us though was how easy it was to write unit tests around our UI classes, ensuring the components functioned correctly when interacted with in the expected ways. This is also possible with Wicket however it was more difficult in my experience.
I will also mention that either framework will require some styling. Wicket starts off as plain old HTML and Vaadin starts off with a MacOSX-like theme by default but almost any web-app you write will require at least SOME customization. With this in mind, customizing the CSS of a Wicket app is SIGNIFICANTLY easier than Vaadin for the simple reason that you control the markup. Vaadin hides the markup from you and generates elements with weird IDs and structures so it is harder to customize the look. Just remember this when making your decision.
I am currently working with Wicket and I have worked in the pass with Vaadin. I wil be short in my observations:
Vaadin is entitled to be free but IMO, is not so beautiful like that. If you need support, help, documentation for that painful and tricky problems that you encounter, then you are screwed because you do not have so good documentation/community when compared with Apache Wicket. Vaadin have guys to help you, but you have to pay for it.;
To program in wicket you need to be a strong programmer. Vaadin also requires good Java knowledge but you can easily do some spaghetti code if you want (just saying, not doing..);
Apache Wicket really separate the web technologies (Javascript, HTML, etc.) from the framework technology (Java). Vaadin also try to do it, but IMO is not so elegant and transparent on that.
Appart from that, we are talking about two different types of frameworks, two different approach, which have pros and cons that I advice you to search and compare and see what really fits your needs.
Edit: Oh, and about the look and feel, for instance you always have Wicket Bootstrap
Also do notice that even though Vaadin base framework is free, for some additional functionality you might need to buy extensions.
Ex - If you need to integrate a good charting solution such as Highcharts, you'd have to pay and buy the vaadin charts extension (even though highcharts is available free for FOSS apps, the vaadin charts plugin built on that is not given free for FOSS apps).
Thank you for your question.
The answer is short and simple
Vaadin is a great tool for java developers who needs to develop web apps, but it is a powerful WAR Machine if you have moderate javascript knowledge, and some basic css skils.
Vaadin is not slow, it is even faster than React and Angular.
If your app is slow, it's because you designed it wrong, and that's true to any framework you use.
Keep in mind this, Vaadin uses web components, so most of the UI is built on the client, no heavy rendering on the server
In your case you said you don't have css knowledge, two options:
Use Vaadin, or hire frontend developer.
I am a web developer for more than 10 years, and I have started as a php developer and a javascript developer.
I can tell you that once I've got into Vaadin, I can not develop another way.
What to choose depends primarily on the business requirements (see points 2 and 4 of your question)
However, if I go the Vaadin way:
I will loose the ability to create UI declaratively.
You can try using the ZK framework - similar to Vaadin with a declarative user interface in XML
I would like to write a somewhat complex web gui application.
It will be used to edit certain content by displaying panels and allowing the user to drag items to edit the content.
The explanation is somewhat abstract, but the point is that i'm looking for a modern gui writing technology, the more standard it is the better odds of me finding information and samples to using it.
I've been using JavaFaces to write some simple web pages and have taken a look at RichFaces for purposes of writing the app described above.
I would love to hear recommendation of similar technologies (For example - What was used to write this website?)
Thank you!!!
Update: Thanks for the answers so far, Since I was asked for more clarification I'll try to explain the use of the app:
It will be used to edit a complex script. There will be one panel with the actions of the scripts (The phases) and the other panel will show the content of the currently selected action. To each action type there will be a different set of attributes to modify.
You will be able to reorder actions by dragging them to a new location (Kinda like powerpoint slides organizer or flickr photo organizer) and also copy them that way.
The content of the action attribute panel will be able to display various types of content such as html text and buttons and all kinds of stuff.
Hope that helps. Thanks Again!
Update2: After reading this StackOverflow Thread I'm leaning towards RichFaces for it's vast support and standardization.
It seems you need a RIA. The Java worlds offers the following options:
Google Web Toolkit - a powerful RIA technology, which will require you to go through a steep learning curve. Nice component frameworks are SmartGWT, gwt-ext and ExtGWT. In my opinion all of them have some drawbacks, but in your case you might not observe them.
RichFaces - quite powerful as well, and since you have JSF experience, I'd recommend this.
ZK - never used it and I don't like some aspects of it (at least a while ago when I last checked it), but it's still an option.
Echo3 - similar to GWT in the way of development, but very different in the actual result. I'm not sure, however, whether it's still in development
JavaFX - if you are adventurous, and your application won't be used by the open public, try it.
ASP.NET MVC was used to write this site.
To your question: you should use the technology you like. If you've used to Java, you may wish to explore various MVC frameworks for that. Or you can try out new unfamiliar to you (yet) technologies.
Take a look to GWT and SmartGWT. Together are quite a powerful combination to write RIA webapps.
An interesting framework that I would be glad if I had the time to look deeper into is Cappuccino. Look at 280Slides for an example.
Flex is also nice open source option to create Rich Internet Applications. If you would like to stick to the JavaScript then you can use JQuery, YUI etc
There is also one very interesting thing called Vaadin check it http://demo.vaadin.com/sampler/
ICEfaces is one possibility. Demos here.
I used richfaces including drag and drop functionality, realy nice to offer good usability.
If you like the Java Web Technologies take a look at zk. It promises the same things as ICEFaces. I don't know if it can live up to that promises but IceFaces coul certainly not for me.
ZK should enable you to build your web app like a common swing app.
I'd suggest that you do not invest into technologies/frameworks which are based on integration of browser side ajax capabilities with server side frameworks if you'll need advanced functionality in the browser.
What is advanced and what is not is a completely different topic of course, but just to give you a heads up, as you start facing more and more complex UI requirements, you'll discover that the connectivity to back end framework (like JSF) will become more of a problem than a capability. Especially with things like JSF lifecycle, and most of the server side frameworks being based on the idea of an HTTP post (for client-server communication), you'll have issues.
An example: you'll be requested to develop a very specific UI widget that has drag and drop capability. If the Ajax-jsf integration framework of your choice does not contain this widget, your problem is born at this point. You'll start looking for ways of injecting data into existing channels, and it will get messy.
To avoid further speculation, let me just repeat that if you are sure that your chosen technology setup will give you 90%+ of the capabilities you'll need, that is ok. If you end up developing too much custom stuff, then consider an integration between a powerful client side (javascript or flex or silverlight) layer and a simpler server side layer (resteasy etc) Initial development may not be as fast as the other options, but if you'll need flexibility, this will end up being a much cleaner setup. I'd suggest you take a look at DOJO, and ExtGWT .
Cheers
Seref
It looks like XHTML + JavaScript could be enough for the dragging & dropping functionality you describe. This means you can use just about any web framework of your choice. If you need frequent asynchronous server calls (AJAX) then GWT is the most standard Java framework I think, although it has its peculiarities. Personally I like Wicket because it does not use XML configurations, relies heavily on code and has a nice community around it. Wicket also offers good AJAX support btw.
I'm trying to establish whether we are better off rendering charts serverside and pushing them to the browser as images or using a javascript charting library to draw the charts clientside.
I'm looking at the JFreeChart and Dojo Charting libraries, my target is an existing JSP site that runs in JBoss.
Does anyone have any experience with this who might be able to point out the merits/flaws of each.
At the moment I'm seeing Client side rendering as being a hell of a lot more efficient unless the dataset is Huge.
I would like to recommend a library I wrote: charts4j which is a server-side charting solution. Here are some features:
Supports nearly all features of the Google Chart API
Hides the ugly details of creating the URL parameters that are necessary for communicating with the Google Chart API
Can be incorporated into any Internet enabled Swing or web application environment (JSP/Servlet, GWT, Spring MVC, etc.)
100% pure core Java solution. No need for special graphics libraries, etc.
Super-scalable & Lightweight. Only one 160Kb jar and an Internet connection required
Well documented
Best of all, it is FREE!
Here are some testimonials. Also check out the FAQ.
I have an example of incorporating this technology into a Spring MVC (using JSPs) app on my blog.
I would recommend determining your performance/provisioning needs and making the decision from there. If you are expecting a large number of clients, each requiring a large number of charts which may need to update periodically, offloading the processing onto the clients will likely be the better solution. As jesper mentioned, you would also be able to do more interaction directly with the charts on the client, rather than requiring callbacks to the server for more complex functionality.
If the general use-model for your charts is simple (e.g. static charts being generated on the fly by the server, w/out needs for updating), and the number of clients is low, you might be fine using hardware to better improve performance. Server-side would probably be sufficient in this case.
Scalability and performance can be hard to implement later down the road. If you have the potential to mitigate this from the beginning, you should do so, since current use models so often change as future users decide they need faster/better functionality.
JFreeChart is very well established and has been about for many years. I've used it on previous projects and it's worked very well. It can be used from a rich client application or from a web application. It has example applications for both scenarios. If you're distributing your application it's also GPL licensed.
The advantages for doing it server-side are that you can render the resulting chart as an image and not worry about cross browser compatibility. I've incorporate JFreeChart by rendering from a Servlet and from Struts, works very well.
I can't speak for Dojo charting, as it's reasonably new.
The first deciding factor should be whether or not you need the charts to be accessible with JavaScript disabled. If you do or think you might, it rules out JavaScript completely.
I see a lot of valid points on either side, but one thing that I like about doing the charting client side, is the ability to do some interaction with the chart. Using the Dojo charting library, you have a variety of methods for chart interaction such as dojox.charting.action2d.Highlight and dojox.charting.action2d.Tooltip. You can also have you charts update dynamically without the need to refresh, and I can see some situations where that can be useful.
Of course, this is all up to you, but I like charts I can interact with a whole lot better than images rendered from the server, and I think a lot of people agree with me on that one.
If you go with javascript you may also want a server-side solution, in case javascript is turned off.
If you use unobtrusive javascript then if javascript is turned on it can change the links for the server-side solution to use a javascript charting tool.
I found it best to use php on the server-side as gdlib is nice, and my tomcat server would throw errors at times due to not being able to connect to an x11 server even if it was running in headless mode.
There are many solutions possible, or you can do it yourself. Graphing isn't hard, it depends on what you need. For example, if you can go with using svg then that would allow animated charts, but needs a plugin for many browsers.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm at the beginning/middle of a project that we chose to implement using GWT. Has anyone encountered any major pitfalls in using GWT (and GWT-EXT) that were unable to be overcome? How about from a performance perspective?
A couple things that we've seen/heard already include:
Google not being able to index content
CSS and styling in general seems to be a bit flaky
Looking for any additional feedback on these items as well. Thanks!
I'll start by saying that I'm a massive GWT fan, but yes there are many pitfalls, but most if not all we were able to overcome:
Problem: Long compile times, as your project grows so does the amount of time it takes to compile it. I've heard of reports of 20 minute compiles, but mine are on average about 1 minute.
Solution: Split your code into separate modules, and tell ant to only build it when it's changed. Also while developing, you can massively speed up compile times by only building for one browser. You can do this by putting this into your .gwt.xml file:
<set-property name="user.agent" value="gecko1_8" />
Where gecko1_8 is Firefox 2+, ie6 is IE, etc.
Problem: Hosted mode is very slow (on OS X at least) and does not come close to matching the 'live' changes you get when you edit things like JSPs or Rails pages and hit refresh in your browser.
Solution: You can give the hosted mode more memory (I generally got for 512M) but it's still slow, I've found once you get good enough with GWT you stop using this. You make a large chunk of changes, then compile for just one browser (generally 20s worth of compile) and then just hit refresh in your browser.
Update: With GWT 2.0+ this is no longer an issue, because you use the new 'Development Mode'. It basically means you can run code directly in your browser of choice, so no loss of speed, plus you can firebug/inspect it, etc.
http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM
Problem: GWT code is java, and has a different mentality to laying out a HTML page, which makes taking a HTML design and turning it into GWT harder
Solution: Again you get used to this, but unfortunately converting a HTML design to a GWT design is always going to be slower than doing something like converting a HTML design to a JSP page.
Problem: GWT takes a bit of getting your head around, and is not yet mainstream. Meaning that most developers that join your team or maintain your code will have to learn it from scratch
Solution: It remains to be seen if GWT will take off, but if you're a company in control of who you hire, then you can always choose people that either know GWT or want to learn it.
Problem: GWT is a sledgehammer compared to something like jquery or just plain javascript. It takes a lot more setup to get it happening than just including a JS file.
Solution: Use libraries like jquery for smaller, simple tasks that are suited to those. Use GWT when you want to build something truly complex in AJAX, or where you need to pass your data back and forth via the RPC mechanism.
Problem: Sometimes in order to populate your GWT page, you need to make a server call when the page first loads. It can be annoying for the user to sit there and watch a loading symbol while you fetch the data you need.
Solution: In the case of a JSP page, your page was already rendered by the server before becoming HTML, so you can actually make all your GWT calls then, and pre-load them onto the page, for an instant load. See here for details:
Speed up Page Loading by pre-serializing your GWT calls
I've never had any problems CSS styling my widgets, out of the box, custom or otherwise, so I don't know what you mean by that being a pitfall?
As for performance, I've always found that once compiled GWT code is fast, and AJAX calls are nearly always smaller than doing a whole page refresh, but that's not really unique to GWT, though the native RPC packets that you get if you use a JAVA back end are pretty compact.
We have been working with gwt for almost 2 years. We have learned a lot of lessons. Here is what we think:
Dont use third party widget libraries especially gwt-ext. It will kill your debugging, development and runtime performance. If you have questions about how this happens, contact me directly.
Use gwt to only fill in the dynamic parts of your apps. So if you have some complex user interactions with lots of fields. However, don't use the panels that come with it. Take your existing stock designer supplied pages. Carve out the areas that will contain the controls for your app. Attach these controls to the page within onModuleLoad(). This way you can use the standard pages from your designer and also do all the styling outside the gwt.
Don't build the entire app as one standard page that then dynamically builds all the pieces. If you do what I suggest in item 2, this won't happen anyway. If you build everything dynamically you will kill performance and consume huge amounts of memory for medium to large apps. Also, if you do what I am suggesting, the back button will work great, so will search engine indexing etc.
The other commenters also had some good suggestions. The rule of thumb i use is to create pages like you were doing a standard web page. Then carve out the pieces that need to be dynamic. Replace them with elements that have id's and then use RootPanel.get( id ).add( widget ) to fill those areas in.
Pitfalls that we've run into:
While you can get a lot of mileage from using something like GWT EXT, any time you use this sort of thin veneer on top of a JavaScript library, you lose the ability to debug. More than once I've bashed my head on the desk because I cannot inspect (inside my IntelliJ debugger) what's happening in the GWT EXT table class... All you can see is that it's a JavaScriptObject. This makes it quite difficult to figure out what's gone wrong...
Not having someone on your team who knows CSS. From my experience, it didn't matter that the person wasn't expert...it's enough that he has some good working knowledge, and knows the right terms to google when necessary.
Debugging across browsers. Keep an eye on Out of Process Hosted Mode[1][2][3], hopefully coming in GWT 1.6... For now, you just have to get things good with hosted mode, then use the "Compile/Browse" button, where you can play with other browsers. For me, working on Windows, this means I can view my work in FireFox, and use FireBug to help tweak and make things better.
IE6. It's amazing how different IE 6 will render things. I've taken the approach of applying a style to the outermost "viewport" according to the browser so that I can have CSS rules like:
.my-style { /* stuff that works most everywhere */ }
.msie6 .my-style { /* "override" so that styles work on IE 6 */ }
Finally, make sure you use an editor that helps you. I use IntelliJ -- it's got lots of GWT smarts. E.g., If I try to use a class that isn't handled by the JRE emulation, it lets me know; if I specify a style for a widget, and I haven't defined that style yet, the code gets the little red squiggly... Or, when looking at the CSS, it will tell me when I've specified conflicting attributes in a single rule. (I haven't tried it yet, but I understand that version 8 has even better GWT support, like keeping the "local" and "async" RPC interfaces and implementations in sync.)
GWT 2.0, which is supposed to come out sometime in the next few months, solves a lot of the issues discussed.
Create layouts using an html/xml like syntax
Dynamic Script Loading - only the essential JS will be downloaded initially. The rest will be downloaded as needed
In-Browser Hosted Mode - This might take care of the hosted mode speed issues discussed, among other benefits
"Compiler Optimizations" - Faster compilation, hopefully
GWT 2.0 Preview Video at Google I/O
Not "unable to be overcome" but a bit of a pain for something basic.
Date handling:
GWT uses the deprecated java.util.Date which can lead to unexpected behaviour when dealing with dates on the client side. java.util.Calendar is not supported by GWT. More info here.
Related problem examples:
GWT java.util.Date serialization bug
Get Date details (day, month, year) in GWT
Client side time zone support in GWT
I'll add some points to the ones already mentioned:
Databinding/validation. GWT doesn't have a databinding/validation support out of the box, although there are some projects on this area starting to emerge. You'll find yourself writing alot of this:
TextField fname, faddress;
...
fname.setText(person.getName());
faddress.setText(person.getAddress());
...
Lazy loading. Since gwt is on the client side, lazy loading is really not an option. You'll have to design your RPCs and Domain Objects carefully in order to
send all your object data that is needed
avoid eager fetching all of your data
You'll have also to make sure that you will not send proxies/non serializable objects. hibernate4gwt can help you with these points.
UI design. It is harder to visualize an UI in java (Panels, Buttons, etc) than in html.
History support. GWT does not ship with a History subsystem, nor does it ship with any subsystem for nice urls or statefull bookmarking. You'll have to roll your own (although it has support for History tokens, which is a start). This happens with all AJAX toolkits AFAIK.
IMHO, GWT is missing a framework that has out of the box support for all of the issues mentioned on this 'thread'.
I'm working on a project right now that uses EXT GWT (GXT) not to be confused with GWT EXT. There is a difference, EXT GWT is the one that is actually produced by the company that wrote ExtJS the javascript library. GWT EXT is a GWT wrapper around the ExtJS library. GXT is native GWT.
Anyways, GXT is still somewhat immature and lacks a solid community that I feel GWT EXT has. However, the future is with GXT, as it's native GWT and actually developed by the company that made ExtJS. GWT EXT is somewhat crippled as the license changed on the ExtJS library, thus slowing the development of GWT EXT.
Overall, I think GWT/GXT is a good solution for developing a web application. I actually quite like hosted mode for development, it makes things quick and easy. You also get the benefit of being able to debug your code as well. Unit testings with JUnit is pretty solid as well. I haven't yet seen a great JavaScript unit testing framework that I felt was mature enough for testing an enterprise application.
For more information on GWT EXT:
http://gwt-ext.com/
For more information on EXT GWT (GXT):
http://extjs.com/products/gxt/
No major pitfalls that I haven't been able to overcome easily. Use hosted mode heavily.
As you are using GWT-ext you will almost never need to touch CSS yourself unless you want to tweak the out of the box look.
My recommendation is to use a GWT "native" widget over a library one where they are close in features.
Re search engine indexing: yes the site will not have navigable URLs normally (unless you are only adding widgets to elements of a regular web site). You can do history back/forward functionality though.
I used GWT and GWT-ext together on a project a while ago. I found the experience quite smooth as web development goes, but my advice would be this:
Don't mix GWT native widgets with EXT widgets. It's confusing as hell, since usually the names are the same (GWT.Button or GWText.Button?)
One thing that happened to me that really made the code more complex than I'd like, was that I wanted a Panel that was
a) dynamically updatable
b) cascadable
GWT native panels are dynamic, Ext panels are cascadable. Solution? A GWT.VerticalPanel wrapping a GWTExt Panel... Chaos. :)
But hey, it works. ;)
I second the comment from ykagano, the biggest disadvantage is losing the V in MVC. Although you can separate the true ui class from the rest of your client side code, you cannot easily use an HTML page generated by a graphic/web designer. This means you need a developer to translate HTML into java.
Get a wysiwyg ui editor, it will save you lots of time. I use GWTDesigner.
The biggest upside of GWT is being able to forget about cross browser issues. Its not 100% but takes almost all that pain away. Combined with the benefit of hosted mode debugging (as opposed to Firebug which is excellent but not the same as a java debugger) it gives the developer a huge advantage in generating complex ajax apps.
Oh and its fast at runtime, especially if you use a gzip filter.
Slightly off-topic, but the #gwt channel on irc is very helpful, in-case you have a persistent problem.
GWT is pretty straight-forward and intuitive.
Especially with the release of UIBinder to allow GWT widgets to be laid out in XML and then coded-behind in Java.
So if you have used other Ajax or Flash design tools, or Silverlight, etc, GWT is very easy to learn.
The major hurdle, if not pitfall, is GWT RPC. The very reason you wish to use GWT is because of GWT async RPC. Otherwise, why not just rely on css to format your page?
GWT RPC is that element that allows your server to refresh data on your server without having to refresh the page. This is an absolute requirement for pages such as stock performance monitoring (or the current national and public debt of the US or the number of unborn babies aborted worldwide by the second).
GWT RPC takes some effort to understand but given a few hours, it should come all clear.
Above that, after putting in some effort to learn GWT RPC, you finally discover that you cannot use JSPs as the service component for RPC, unless ... I have an 8 part (I think) series on my blog on how to use JSP as the GWT RPC servicer. However, since you had not asked for answers but just issues, I shall desist from advertising my blog.
So. I very much believe that the worst roadblocks/pitfalls to using GWT is finding out how to properly deploy GWT async RPC and how to enable it to use JSP servicers.
We've had a very hard time marrying our GWT codebase with HTML web templates that we got from a web designer (static HTML pages with specific div ids that we wanted GWT to manage). At least back when we used it, we couldn't get GWT to integrate with parts of our website that were not coded in GWT. We had it working eventually, but it was a big hack.
The Async interface you have to write for each service interface looks like something that could have been automatically generated by the GWT compiler.
Compile times become long for large projects
But for a large Javascript project it's the best choice
GWT 2.4 has fixed many of the aforementioned issues and a great widget library is just coming out of Beta (Ext GWT 3.0.4 a.k.a. GXT), which is written completely in GWT, not a wrapper of a JS lib.
Remaining pain:
Lack of CSS3 selector support, you can use "literal()" in some cases to get around it.
Lack of support for CSS3 and modern browser events like transitionEnd.
Lack of Java Calendar class support (many years later).
Lack of JUnit4 support (5 years and counting).
Lack of clear road map and release schedule from Google GWT team.
Regarding GWT 2.4, Use Firefox when debugging GWT, it alot more faster then using chrome.
And if you'll using only firefox, consider putting this line in your project.gwt.xml file
<set-property name="user.agent" value="gecko1_8" />
Also, If you're using eclipse, then add the following under arguments -> VM arguments:
-Xmx512m -XX:MaxPermSize=1024m -XX:PermSize=1024m
You can divide your server and client, and use the following under arguments -> Program arguments:
-codeServerPort 9997 -startupUrl http://yourserver/project -noserver
Also, to prevent refreshing your server on each change, use JRebel
http://zeroturnaround.com/blog/how-to-rock-out-with-jrebel-and-google-web-toolkit-gwt/
And here's a live demo
http://www.youtube.com/watch?feature=player_embedded&v=4JGGFCzspaY
One major pitfall is that sometimes you need to explicitly assign an id to what ultimately becomes an HTML element to be able to use certain CSS styles. For instance: a GWT TabPanel will only do :hover over tabBarItems when the tabBar of the tabPanel has been assigned an id and you specify a :hover on that elementId.
I wrote about some other disadvantages of GWT elsewhere, but they are already covered by rustyshelfs answer :).
I have done a lot of work on GWT recently, and this is wht i have to say:
CSS styling is tricky only sometimes, use IE developer tool in IE and firebug in Firefox to figure out what exactly is happening and you will get a clear idea of what css needs to be changed
You can use tricks to get google to index it. A very famous site is http://examples.roughian.com/ check its ratings at google. A far less famous site is www.salvin.in (couldnt resist to mention that), i optimised it to words: salvin home page (search google for these three words)
I do not know much about GWT-EXT, But i too am of the belief that there is no need to include Third party libraries.
Best of luck on your decision :)
GWT does Browser Sniffing instead of Feature Detection and your application will not work on some browsers (specially new ones)
Here are some references of the problem:
google-web-toolkit Issue 2938: RFE: improve the user.agent property-provider to cope for userAgent string "masking"
Iceweasel no longer supported? - Google Docs Help
GWT implementations for every browser
Here are some references to Feature Detection:
Browser Detecting (and what to do Instead)
Feature Detection: State of the Art Browser Scripting
Browser Feature Detection
Extracted from Comparison of JavaScript frameworks - Wikipedia
The GWT team make a lot of great improvements in to last year releasing GWT 2.7. One major weakness of GWT was that compilation takes to much time in GWT 2.6 and below. This is now gone GWT has not incremental compile which is super fast and compiles only the changes.
GWT 2.7 now has (Source):
Incremental builds now just seconds
More compact, more accurate SourceMaps
GSS support
JSInterop
Great JavaScript Performance
Smaller Code Size
The best way to get reliable facts are from the gwt survey. One of the biggest issues with GWT has always been a long compile time. Fortunately, it's improving very quickly so it won't be a significant issue in the near future. Another pitfall is that GWT is dramatically more complicated because Java is a more complicated language that resists bad coders every step of the way. In addition, compiling adds a layer. For example, js interop requires a little boilerplate. The fundamental issue is that GWT wasn't designed to be simple. It was designed from the ground up for extremely complicated web apps and the entire community consistently prioritizes, performance, code quality, architecture etcetera over easy coding.
Remember that you can use js in GWT at any point so if you are struggling with GWT consider using js. At the end of the day GWT is js so you can do anything in GWT that you can in js. In fact, most GWT projects use js. The problem is that GWT is drastically more complicated. Nevertheless, it's sometimes worth the extra complexity.
It's worth noting that GWT 3.0 will bring massive improvements.
Re-using RPC service objects.
It causes race conditions with symptoms that look like the app hanging.
Pitfalls I ran into
1. Different behaviour in superdev mode. E.g. Someclass.class.getName() works absolutely fine in Superdev mode and returns the fully qualified name of the class. In productive mode this does not work.
addWidget(widget) will call widget's removefromparent()
GWT is a technology masterpiece. It unites client and server programming making it one coherent application - the way software was written before "layering", and the way it should be written. It eliminates different skills sets, miscommunication between team members, and generally the whole Web Design phase: both the artistic and programming. And it is the closest you'd get to mobile e.g. Android development. In fact GWT was designed to generate different native UIs, not just HTML. Though it requires enormous discipline to ensure such decoupling - to keep your inner layers presentation-agnostic.
The first mistake you should avoid, which took me four years to realize, is using third-party extensions like EXT-GWT aka GXT and SmartGWT. It is very tempting to start using their pretty desktopish widgets instead of investing in your own styling, but I cannot tell how many problems I had with SmartGWT until I finally got fed up. In short it freezes the core GWT feature set at the certain (pretty outdated) level and then builds on top of it. Also keep in mind, that chiseled desktop look and feel looks silly nowadays, not to mention the sluggish performance, tons of bugs, and compatibility features - especially on mobile devices. You want to stay as close to the native browser controls, as possible i.e. dropdowns rendered as native <select> elements, not some custom-painted controls.
Thanks to mobile trends the whole UX is becoming simpler and flatter, so you don't need to do much to style a sharp-looking application. Though if you want "3D" look, there are also gradients. CSS3 made everything easy, and GWT wraps it an elegant object-oriented manner unlike the raw CSS. So don't be discouraged by looking at rather ugly barebones controls in the GWT Showcase. The GWT team intentionally didn't offer any styling, because it it the developer's job.
The rest is pretty much conventional browser programming in strongly typed Java with beautiful concise APIs. But of course never forgetting your code runs inside the browser, so all of the calls are asynchronous e.g. you cannot call GWT-RPC methods in a loop (to populate some list), but need to recursively chain them if you ever come to to this situation.
There are some self-proclaimed "anti-patterns" like don't use GWT-RPC. It's been good to me so far: for 10 years. Simplicity is key. I wouldn't think even a second to sacrifice some marginal performance for code elegance and maintainability. besides this is not where your bottlenecks would be - in the database. Of course mind how much data you are sending to the client.
And if you cannot find or style the existing gadget - read rich HTML5 element set, you can always wrap a third-party one. I did it with a popular jQuery FullCalendar. Not rocket science at all. Everything else like Google Maps and Google Charts has semi-official GWT wrappers.
GWT is perfect. The only reason it doesn't get enough love is because early Internet adopters who still influence the industry didn't come from Computer Science and object-oriented languages to appreciate them. They have either artistic (Photoshop/WordPress) or network (Perl/Python) background.