I'm fairly new to programming and have been taking courses on Lynda to learn the fundamentals. I have some knowledge of Java and HTML, but I wanted to refresh my memory so I can start learning Objective-C. The Lynda course has us working in JavaScript because of its pretty core syntax. So, in order to get a point of reference, I tried downloading some .js files integrated into HTML pages from various sources. However, this proved to be unhelpful and I am at a loss for understanding because of the way the files are formatted. It seems as if most files put one line of code after the other. I realize that because of flexible whitespace restrictions with JavaScript that this does not hinder the way the code runs, but why did the developers choose to put it all on one line like that? They obviously didn't write the code that way, as that would be extremely tedious and hard to work with, so why did it come out that way when I try to view it? Is it just something that happens when you try to download the resources of a page? Any clarification would be appreciated.
Below is a photo of a JavaScript file I tried viewing. As you can see, all the code is restricted to one single line.
Also, if anyone could offer some insight about where to go after I've finished my course if I'm looking to develop for iOS, that would be greatly appreciated. Lynda also offers an Objective-C Essentials course, as well as an iOS Development course, but I feel like it's a pretty linear path that could be expanded on greatly with some literature or other online documentation.
what you are seeing is a minified version of the javascript file. The main advantage of minification is that it reduces the amount of data that needs to be transferred (bandwidth usage).
If you wish to view the code in human readable format, you can use online tools like this
Yes as karthikr said it's minified. Which means its all there but without the line breaks. So to see it all you have to scroll right.
Or you can use http://jsbeautifier.org/ to bring back the break lines.
There are several reasons for minifying javascript. One is that it makes the code less readable (yeah, some devs don't want you to "steal" functions and see what it does easily). Another, and a big part of why, is that it reduces bandwidth. A file with long variable names and whitespaces everywhere can be multiple times bigger than a minified version - so it improves performance!
Bandwidth costs money, especially for users and especially if they're on mobile devices with a bandwidth limit.
So to solve this problem developers will minimize the file size of what ever they can.
The JavaScripts you are seeing have been minified by libraries such as Uglify or YUI compressor (list not exhaustive).
Doing this will take out unnecessary whitespace and reduce the lengths of variable and function names that are not globally exported.
Developers may also gzip the files too which will reduce the filesize even further.
Edit: grammar
I am looking for a Java library that let's you write large PDFs sequentially with a minimum amount of memory. Most of the libraries I had a look at has to build up the document in memory first before you can actually write it.
The problem I have to deal with are OutOfMemoryErrors. It would be great if I could flush the writer programmatically whenever needed e.g. for each page.
Does anyone have any recommendations? I need something with a license along the lines of the LGPL (so not the GPL or the Affero GPL that iText uses).
You can do that with iText. It supports writing to OutputStreams.
The free version of Docmosis has a fairly open license so it might suit you. It uses a template-approach which is different from building from code. Docmosis processes all documents in a stream-based fashion since it's intended for singificant parallel use and for large documents. It also allows you to offload the most CPU intensive part processing to another server. Hope that helps.
I actually, had same issue as you do, a friend help me out, but he did in C# and using an api called GhostScriptSharp, you should check for it.
I can't give you a copy of the code, since its copyrighted, but i'm sure it would help you out, since the tool i think is builded on Java.
jPod can swap indirect objects and supports incremental writing.
This is still not optimal as you need an "increment" on each flush, but better than nothing...
EDIT
Öhhh - this is one of the famous examples of self describing code :-) Your're right, theres not much of a tutorial or that - but the Javadoc is quite good.
jPod writes incremental by default. See "CosDocument.setWriteModeHint" to set to full mode.
The example "CreateDoc" and "AppendPage" are simple examples of how to add pages. You may do the same and call "save" every 10 or 100 pages. This should "soften" all references to pages in memory and if not held by some other references of yours, the can be garbage collected.
THere's still the question how you fill the pages? THere are examples dealing with content streams, too (DrawText,..). BUT jPod is not like iText, jasper or whatever. There's only PDF model abstractions. You have no "Layouter" or "Renderer" that creates page content from text, html or something like that. How do you do this?
I'm working on a school project in which we would like to analyze the content of webpages. We don't, however, want to deal with things like Nav bars and comments. If we were looking at a specific website we could make a parser to filter that sort of extraneous stuff out specifically for that site, but we are hoping work on arbitrary sites that we may not have ever encountered before.
I feel like it's a bit much to hope for, so I won't be surprised if nothing like this exists already, but does anyone know of a tool that can do that sort of content isolation on arbitrary websites? I've had a bit of luck diffing pages with others from the same site, but it's imperfect and leaves comments and such.
I am working in Java, but would welcome anything open source in any language that I can use for ideas.
I'm a little late to this one (especially for a school project), but if anyone finds this at some future point, the following may be helpful.
I stumbled across a Java library to do exactly this. Performance, in my simple tests, is similar to Readability.
http://code.google.com/p/boilerpipe/
You could try an unofficial API of arc90's Readability.
Basically what Readability does is extract content on a webpage and presents it to you as a nicely formatted article. Nav bars, comments, and all the other stuff that surrounds content on a webpage is gone.
im also a bit late to this conversation but ...
the Java Boilerpipe extractors are probably what you want (ArticleSentencesExtractor probably), although there is at least 1 port of the arc90 readability to java on github.
If you want to build a poor mans boilerpipe you might try diff'ing 2 pages from the same site (assuming they are using the same template you will likely get an interesting result)
The main difference between boilerpipe, readability and a diff based hack is that boilerpipe will strip out all html but preserve some structure
I doubt that anything exists that would do what you want. Without some sort of semantic markup it is next to impossible to distinguish "real" content from the other stuff. This is a task that requires real intelligence.
There are of course good tools for parsing HTML of varying degrees of correctness, and it is often possible to cobble together some pattern-based solution for dealing with pages on a particular site ... assuming that there are common structures / patterns to be elicited.
I code primarily in javascript and in vb.net. I've found that if I can achieve the same thing in both javascript and vb.net that I feel far more productive and expressive using javascript for the task. I often find myself researching server-side javascript implementations to see if anything has gone mainstream so that I can code my back-end business logic and data access in javascript. Given all the advanced tooling and language features in .Net this preference seems somewhat paradoxical to me. I'm not suggesting one is better than the other (I've been a vb programmer since I started programming), I'm just wondering if my preference is entirely subjective or if anyone else shares it. So, does anyone else enjoy coding in javascript to the point where you prefer it to the .Net and Java environment, and if, so why?
Personally, I'm much more "productive" in .NET than in JavaScript, simply because the framework is more rich and there is much built-in functionality. I also have not started writing code using TDD in JavaScript, perhaps because of the lack of readily available tooling in Visual Studio. For C# and VB in Visual Studio, there are many different ways to achieve very productive TDD. As far as the languages are concerned, I'd say that JavaScript could potentially be "quicker" to hack something together in since it is dynamic - which can lead to more terse code, LOC-wise. Note: "quick" and "productive" are of course different measurements.
javascript just has a higher signal-to-noise ratio, since it doesn't require all that superstructure of declarations and explicit typecasting. If you are confident of your coding, it's much faster to write and debug.
With static-type languages I spend more time thinking about language requirements than problem-solving requirements.
If you want a direct comparison, try ActionScript. It's literally javascript with all rigging added - they hoped it would be the next standard version but failed. It's kind of a litmus test - some people prefer it because of the explicit typing and error-checking. You and I would not so much because of the overhead.
When developing a reasonably large application, I feel more productive in java/c# due to static typing and a larger and more mature set of libraries and tools.
This question is highly subjective though, different people are going to have different experiences and opinions. If you have a choice, you should be doing what works the best for yourself.
I think that if the application required much about correctness and good structure. It should be a server side language. You can achieve things with Javascript but I guess that it's not very complex.
I feel much less productive programming in Javascript than Java. The main reason is that there are so many more portability issues with Javascript implementations; e.g. between different browsers. Other issues include those mentioned by others:
Java has better tools support, both for coding and for debugging across multiple deployment platforms.
Java has far more extensive libraries, both standard and as 3rd-party extensions.
Doing multi-threaded stuff in classic Javascript is sooo convoluted.
Java's primarily static type system (in my experience) makes it better for programming in the large.
However, there are still situations where Javascript is a better solution than Java or C#, despite the productivity issues above, and any prejudices one might have against Java.
node.js is currently the hot serverside JavaScript solution. It would be a big departure from .NET, but its gaining traction.
I think JavaScript as a language offers a very similar set of tradeoffs as other dynamic programming languages. It has some really excellent capabilities to do a lot with less code, but it doesn't have the same safety features or speed.
For the most part, I find that I can get more done faster with JavaScript than Java for example, but it can sometimes be tedious to refactor. Occasionally there are times when tricky run time errors sneak in that would have been caught at compile time in Java.
It also helps that I work in JavaScript a lot and have built up a large library and framework of reusable code. JavaScript doesn't come with too much out of the box.
I feel much less productive programming in JavaScript than Java. The main reason is that there are so many more portability issues with JS implementations across different browsers.
I used to feel that way as well, but as I have learned JavaScript I have also learned to get around the quirks neatly, I don't really think about browser differences when I code anymore. When there is problems it's almost always with HTML and/or CSS.
On the other hand I have never had a pleasant time writing ASP.NET, whatever I need to do, it is so hard to find any useful articles/documentation/examples. Recently I needed to interact with an MS SQL database, as seen on MSDN the "System.Data.SqlClient Namespace" contains 26 classes, each with a rich stack of methods, members, properties etc. Probably totalling around 1000 documented identifiers. One only need a handful of these to write perfectly fine code, the problem is finding this handful hidden between all the junk. Nowhere to be found is a neat little 20 lines example containing the useful functions in action (or at least if so I haven't found it). I suppose one can learn to get around the kinks of .NET and MSDN, but I fail to understand how .NET has become so widespread when there is perfectly good alternatives.
In my case:
ASP.NET -> Massive productivity fail due to wasting time finding out what function does some trivial task.
Ok here is my opinion I'm a javascript developer and is all I do, I have a good knowledge about .Net (c#) and Php, And I'm very productive with javascript as I'm in building with C#, but always depends of the application, One thing that you can't do when build with only server side code is get a fully independence between backend code and frontend code you have to mixup (server code and xhtml || css code, but with javascript and some webservice or ashx files, you can really split this issue you get a lot of good points. For example you can build two team one of frontend (designer) and the second one just of programers, And belive this is great, many times just the backend team does not think the same way of the backend team and many time have different goals in their head. The second good point and a very very good is with this you don't care about if your front end designer are building the site just with javascript or with flash wich is ecmascript (javascript flavor), or an iphone.
The bad point is that you have to know alot!!! of javascript because almost all the time you are writting code without intelligenSense or a IDE, is just you and your knowledge, you don't have many feedback from the browser when you have an error writting the code so debuggin can be a problem at least if you don't use firebug (firefox) || .NET IDE.
And for "kwyjibo" I only use a fully JAVASCRIPT AJAX solution only when the site is very complex and have to be a really really USER FRIENDLY 'cool' solution.
But yes you CAN be the same productive =)
I've always thought to myself if JavaScript went on the desktop, it would demolish Ruby, Python, and Perl as the language of choice for ad hoc scripting -- but that's pure speculation :)
But since you asked, productivity and familiarity go hand in hand. I write a few lines of JS once a year at most, so I constantly refer back to the documentation to get anything done. On the other hand, I use .NET everyday :)
I think there's some argument that Javascript is more productive than VB.NET. VB is bulky by design, and all those extra half seconds it takes to write out 'Public Property whatever As Type get ... end get set(value as Type) end set' will add up (even with the IDE filling in most of the boilerplate automagically).
C# is a little closer to JavaScript in terseness. (And speaking just for myself, I find I'm much more productive in F# than C# :) ) So you can write code in both languages at the same speed, how fast can you debug it? At least for me, Firebug is ok, but nothing in the world beats the Visual Studio debugger.
If you're finding VB.NET isn't up to snuff, you're in good company ;) Try switching to C# as your default language, see if it makes a difference.
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.