Using Google Web Toolkit: A Year in the Trenches(tech.dayzipping.com)
tech.dayzipping.com
Using Google Web Toolkit: A Year in the Trenches
http://tech.dayzipping.com/using-gwt-to-build-a-large-web-application
12 comments
I think GWT would be most useful to data-driven apps/services that need a web interface. All of your heavy data mining can be done in highly optimized Java, and then you won't need to context switch in order to implement your web frontend. It's a win-win.
That's not to say that it can't be used in a more "social" context (Rypple uses GWT for their app, and I have yet to see problems there), but I'd imagine that it has greater use for data miners and enterprise applications.
That's not to say that it can't be used in a more "social" context (Rypple uses GWT for their app, and I have yet to see problems there), but I'd imagine that it has greater use for data miners and enterprise applications.
When I was at Google I remember seeing an email on one of the lists from Steve Yegge about GWT. Steve was talking to one of his buddies whose team was using GWT. I don't remember the exact phrasing, but it went something like this:
stevey: I hear you guys are using GWT, how's that working out for you?
buddy: It's kind of like programming while wearing mittens.
stevey: Mittens are good, right?
buddy: Not if you're trying to type.
Make of this what you will.
stevey: I hear you guys are using GWT, how's that working out for you?
buddy: It's kind of like programming while wearing mittens.
stevey: Mittens are good, right?
buddy: Not if you're trying to type.
Make of this what you will.
I've used GWT for about a year, and I like it because I like static typing more so than I like java the language. And yes, i've tried various dynamic languages (ruby and javascript), and i still prefer the statically typed ones for large projects with a large number of developers over a large time frame. I also know that not everyone agrees with that, and if you don't, GWT may not be the best tool for you. However, it works well for me. And if you ignore the language debate, the toolset is very powerful.
(I also hope scala-gwt will become real-world-usable some day :) )
(I also hope scala-gwt will become real-world-usable some day :) )
After using GWT for a year as the basic tool for a project, I am not sure if I would choose it again. I would, but only for a certain type of web apps.
I can't say it is bad. Actually, it has been pretty good. But, somehow when I look at all the other development environments out there, some of them look better. ekidd put it pretty well, actually.
The best side effect of using GWT has been a lot of business logic on the client side.
The worst side effect of using GWT has been a lot of business logic on the client side.
I can't say it is bad. Actually, it has been pretty good. But, somehow when I look at all the other development environments out there, some of them look better. ekidd put it pretty well, actually.
The best side effect of using GWT has been a lot of business logic on the client side.
The worst side effect of using GWT has been a lot of business logic on the client side.
When I visit www.dayzipping.com, I get a javascript error, and it fails to load. The error points to some obfuscated code.
Strange. What browser? Just tested in chrome, safari, and firefox and it works fine.
Chrome 9 for Mac. Standard install, not a dev build.
The error I see is: Uncaught TypeError: Cannot call method 'init' of undefined
The error I see is: Uncaught TypeError: Cannot call method 'init' of undefined
I also see the same error. Running on 64bit Linux (Mint), happens with both FF 3.6 and Chrome 10
How about using node.js. Bang javascript on the server and on the client. Personally I have high hopes for Sproutcore.
There are some real weirdos out there (like me) who do things like this for no reason: https://github.com/cretz/gwt-node
I used GWT for a while in 2009-2010, and didn't like it at all. I kept running into things that weren't implemented in its subset of Java. Debugging was a pain. Compilation was excruciatingly slow because of all the variations of the code that always had to be compiled for different browsers (something like 40 seconds for a fairly small project) and development speed in general was slow. Also, IIRC you could only run your project from Eclipse in some sort of an IE6 based container. All in all, it wasn't a pleasant experience at all, and I'm not sure what the benefits are. Writing a web app in Java doesn't count as a benefit for me, especially with so many constraints around it.
GWT has to be the weirdest project ever. Imagine you were forced to work as a LISP programmer, and out of desperation you would write a compiler that compiles Java to LISP, so that you could continue coding in Java. It's almost like that.
I worked on a fairly large GWT based project. Once your project crosses certain size, the entire compilation of Java to JS is royal pain and really affects your productivity.
I've worked on several large GWT projects, and if compiling to javascript is impacting your productivity, then your development process is not set up right.
In particular, compilation to javascript should not be inside of your basic edit->compile->test loop. Instead, you should be developing in DevMode (formerly known as "HostedMode") where the code runs in a JVM. The step of compiling to javascript should only happen once or twice as your code starts going towards a production environment.
In particular, compilation to javascript should not be inside of your basic edit->compile->test loop. Instead, you should be developing in DevMode (formerly known as "HostedMode") where the code runs in a JVM. The step of compiling to javascript should only happen once or twice as your code starts going towards a production environment.
I briefly tried this and pyjamas last year and I just don't see the point at all. I guess this is aimed at the type of person who isn't experienced in client-side web technologies (HTML/CSS/Javascript). The fact that somebody could code a web application without much knowledge of the front-end web stack really scares me, I don't care how good the abstraction is.
Having to maintain static copies of every page that should be indexed seems like a huge amount of overhead. GWT could be great for an internal app, but until this is resolved, I couldn't see using it for a public-facing application.
That's not a GWT issue, but an issue with architecting a web application in an all-in-one-page AJAX style. The same would be true with any web application written in that manner, regardless of toolkit.
Yes, and? Aren't we discussing the merits of using GWT?
That's exactly my point. Since we're discussing the merits of GWT, we should avoid points that have nothing to do with GWT per se.
To put a finer point on it: GWT does not require you to structure your app that way. If you do choose to structure your app that way, then you're making the same tradeoff that you would make if you were to go down that same path in any toolkit.
To put a finer point on it: GWT does not require you to structure your app that way. If you do choose to structure your app that way, then you're making the same tradeoff that you would make if you were to go down that same path in any toolkit.
I don't see any point in discussing GWT by itself, without any comparison to other development techniques, and when you compare it to traditional approaches, the "SEO overhead" mentioned in the article is a downside.
Ok, but let's cleanly separate the concept of a tool from the concept of a technique.
The technique here is using URL fragments for history management in AJAX applications.
This tool (GWT) does not require that technique any more than JQuery does (or myriad other examples), so the comparison of the tradeoffs of using/avoiding the technique is orthogonal to the choice of tool.
The technique here is using URL fragments for history management in AJAX applications.
This tool (GWT) does not require that technique any more than JQuery does (or myriad other examples), so the comparison of the tradeoffs of using/avoiding the technique is orthogonal to the choice of tool.
That's good to know. From the article, it sounded like hashbang URLs were the default/preferred method of handling navigation.
Yeah, I think that section of the article could be improved.
If I were facing their problem (where they had already chosen to use URL fragments for navigation but also didn't want to miss out on crawlability) I would use a different approach than maintaining a separate set of static pages.
Instead of static pages, I would create a single servlet/cgi that would handle the URLs to these pages. The content for each URL could be created on-the-fly on the server side using some server-side browser (like HtmlUnit, Cobra or Crowbar...) to receive the requests, translate the URL into the fragment-format, run your actual javascript application (which is already written to handle such fragments) and capture the resulting DOM to send back to the actual browser that arrived via the Google search. Of course the HTML could be persisted so that this process would only need to happen once per URL. The benefit of doing it this way would be that when you deployed changes you could simply invalidate the HTML cache and let your system build them again automatically.
But it would probably be better to avoid the problem entirely by thinking about SEO needs up front.
If I were facing their problem (where they had already chosen to use URL fragments for navigation but also didn't want to miss out on crawlability) I would use a different approach than maintaining a separate set of static pages.
Instead of static pages, I would create a single servlet/cgi that would handle the URLs to these pages. The content for each URL could be created on-the-fly on the server side using some server-side browser (like HtmlUnit, Cobra or Crowbar...) to receive the requests, translate the URL into the fragment-format, run your actual javascript application (which is already written to handle such fragments) and capture the resulting DOM to send back to the actual browser that arrived via the Google search. Of course the HTML could be persisted so that this process would only need to happen once per URL. The benefit of doing it this way would be that when you deployed changes you could simply invalidate the HTML cache and let your system build them again automatically.
But it would probably be better to avoid the problem entirely by thinking about SEO needs up front.
Perhaps I don't understand GWT correctly, but it seems like it would be very difficult to layout and design a web front-end from within Java code alone.
It depends. For someone who has no experience with html/css layouts, and has the ability to build his own design from scratch, creating the layout in code might seem simpler. The reason: it feels similar to creating desktop app layouts (i.e. Swing). And you don't have to worry about cross-browser stuff (in theory).
Also, You can now use GWT Designer, an Eclipse plugin that lets you build UIs graphically.
On the other hand, if you are a familiar with html and css layouts, this all might seem like a big mess, and too much work to do something simple. And you will not like the generated code (many many tables, often).
That's why they created GWT's UIBinder. You can use a html-like code to design the UI. This is much easier than making all the panel.add(widget) stuff in code. And it is a nice compromise, because your front-end designers will understand it. The big downfall is that it needs to be compiled to view the results, and believe me, this can be a cumbersome task.
I have been using it in the scenario where we get all the html and css from the designer, along with the jquery to add some effects. It wasn't easy porting the whole (working!) design to something usable by GWT. But, in the end we got the GWT to generate exactly the same markup.
All in all, there's no such thing as a free lunch.
Also, You can now use GWT Designer, an Eclipse plugin that lets you build UIs graphically.
On the other hand, if you are a familiar with html and css layouts, this all might seem like a big mess, and too much work to do something simple. And you will not like the generated code (many many tables, often).
That's why they created GWT's UIBinder. You can use a html-like code to design the UI. This is much easier than making all the panel.add(widget) stuff in code. And it is a nice compromise, because your front-end designers will understand it. The big downfall is that it needs to be compiled to view the results, and believe me, this can be a cumbersome task.
I have been using it in the scenario where we get all the html and css from the designer, along with the jquery to add some effects. It wasn't easy porting the whole (working!) design to something usable by GWT. But, in the end we got the GWT to generate exactly the same markup.
All in all, there's no such thing as a free lunch.
...it seems like it would be very difficult to layout and design a web front-end from within Java code alone.t seems like it would be very difficult to layout and design a web front-end from within Java code alone.
You don't have to, and you're not necessarily even supposed to. You work with DOM elements and CSS styles just as you would anyway. Every Widget in GWT inherits from the UIObject class. Each instance corresponds to exactly one tag in your DOM, and has methods for getting/setting styles. Your java code would just handle putting the element where you want it in the DOM, and setting the style(s). The layout is in your CSS, just as usual.
You don't have to, and you're not necessarily even supposed to. You work with DOM elements and CSS styles just as you would anyway. Every Widget in GWT inherits from the UIObject class. Each instance corresponds to exactly one tag in your DOM, and has methods for getting/setting styles. Your java code would just handle putting the element where you want it in the DOM, and setting the style(s). The layout is in your CSS, just as usual.
Not much different than building an iPhone interface programmatically. They recently bundled the GWT Designer, which is a WYSIWYG layout tool. UiBinder is another option that let's you build interfaces in XML.
Of course, that leaves open a larger question: Do you, personally, want to write web apps in Java? If not, then you'll find GWT to be a clever solution to a problem that you didn't want solved.