Posts Tagged gwt
Google IO 2010 day 2
Plenty more fun on day 2! There was lots of general iPhone and iPad killing with Android 2.2 demos during the keynote, along with the announcement of Google TV. The keynote is up here.
More on GWT from the sessions:
Widgets
There is lots of client-side performance improvement to be had using LayoutPanels, UIBinder, and ClientBundle. Another great workaround, which does have some risk and complexity for “maximum performance”, is innerHtml. The new components in 2.1+ help abstract that out so as consumers we don’t have to dip into innerHtml directly as often to get the benefits. There are also some good organization and code clarity benefits to UIBinder, like declarative views and replacing the monolithic app css file with bite-sized package files where possible.
Testing
This session made me happy because the testing best practices at Google seem to align really well with what my team is already doing. They stressed heavily using MVP to create unit-testable code and then test in a JVM as much as possible, keeping views so simple that there is very little which can break. They also use Selenium/WebDriver for high-level integration tests that walk through the app as a sanity check. There was a little bit of discussion about GWT unit tests (the compiled ones), by for the most part everyone agreed that they are too slow for the value they provide so it’s an intermediary step for special cases where not a whole lot of testing occurs. Most importantly teams should just acknowledge up front that there are multiple scopes of GWT tests and try to use them all correctly. Another good idea out of this was developing UI test harnesses for complex UI views, especially anything browser-specific or with performance constraints, so that it’s possible to write “Selenium unit tests” that bring up just the harness page with the widget and hit them really hard in a tightly controlled scenario rather than in the larger application (even a mock application).
GWT in Production Applications
This was Ray Ryan’s (of the infamous 2009 MVP session) architecture talk this year. The overall theme around MVP was the same, with some focus on broader topics like supporting bookmarkable/crawlable pages. However it was interesting to learn that GWT core is finally going to bring in some version of GWTLog that implements the Java logging API. The main tool used for demoing these was Spring Roo with GWT which in a nutshell is “Grails for GWT” – really cool to run a few commands and auto-generate your whole project, JPA entities, service endpoints, etc. but not something I’ll use on an existing, well-established product. For brand new products or teams just learning GWT it could be cool, and for the community overall certainly lowers the barrier of entry to get a full-stack Java/GWT project running quickly. Finally, in addition to logging there’s some new support in 2.1 for manipulating headers and some SafeHtml utils for using innerHtml in a way that doesn’t introduce security holes.
Google IO 2010 day 1
What a great way to kick off the conference! There was lots of GWT focus even starting during the keynote, which I honestly didn’t expect; HTML5 and browser video was big but GWT was right there behind it. Real backing from SpringSource/VMware was good to see and the SpeedTracer and 2.1 widget demos were impressive. The keynote is up on YouTube already, with sessions to follow in June.
My big takeaways the first day relating to GWT are:
Widgets
GWT 2.1 is just around the corner and is heavily performance-focused with more general purpose widgets that will let us display data quickly. Specifically they seem focused on high performance grids and layout strategies, which really started taking off in 2.0.
SpeedTracer
SpeedTracer has some really powerful new features like being able to add arbitrary benchmark points in code that show up in its UI, and ability to link back to the actual line of Java code for a GWT project (not just the obfuscated JS), along with the server-side integration via Spring from the keynote; while I haven’t tried yet it’s all in the latest milestone and should essentially be available now.
GWT Compiler
There are a lot of undocumented compiler options to further reduce code size and some other JVM options you might not have expected can help too (like -server and a 64-bit JVM), but using code splitting really makes the biggest difference (yay!), as well as some other things I’ve suspected like avoiding singletons and other static initializers at all cost.
GWT Linker
Linkers are really easy to build and are a powerful way to handle the final creation of an app with far more metadata available than, say, manipulating files with ant. Unfortunately something like static linking – an idea many of us have thought about to reduce the coupling between different GWT modules that inherit each other – needs heavy interaction between both the compiler and linker, and even though it’s open the core compiler is far less documented/outside developer friendly right now. However, there is really cool work being done to support distributed compiles that’s separating the work out in a way which might be divided not only among a cluster of machines across permutations, but used to save artifacts and re-use them if the underlying module hasn’t changed. I chatted with some people after the session and there is just a lot of work to be done in that smart splitting/change detection that puts it in at least the 2.2+ timeframe.
Architecting for Performance
Most of these best practices were things my team is already familiar with like putting serious thought into how the application is bootstrapped, how many RPCs we’re making, and what the payload is, specifically the importance of having UI-focused meta-services that return exactly what a UI function expects rather than simple generic services with heavy lifting in the client, plus more “use code splitting!”. However some new ideas are using UIBinder to separate out (and obfuscate, in production) css, using LazyPanel to defer rendering as late as possible without affecting the contract of widgets to their consumers, and designing UI’s with more optimism when an RPC takes place (assume it will work and begin the “success” case immediately, finishing as the data arrives, but potentially more work to handle failure).
A theme here was orders of magnitude, and the idea that performance is just a characteristic of usability:
- 100ms = “instant” to users, almost everything should be faster than this – I related to this to anything that’s purely client that I expect to be unnoticeable
- 1,000ms = “keeps focus”, this is a pretty big deal but things above this can be managed with explicit feedback – I related this to anything requiring a potentially slow RPC load and putting up some kind of “Searching…” or “Waiting…” dialog
- 10,000ms = “upper limit”, the longest you can possibly ever take before a user has surely alt-tabbed, gotten up from their desk, force-killed your app, etc.!
HTML5
There’s a ton of buzz around this right now, but the short story for the moment is that any app forced to stay seriously in the IE7-8 world (which, sadly, mine does), is going to be crippled. To take advantage of what, as they like to say, “all modern browsers” are capable of, apps are going to need a user base comfortable running Chrome, Safari, and Firefox (and I guess Opera), else they’ll be left in the dust.
GWT 2.0 rocks
GWT 2.0 was just released ushering in some much-awaited changes like development mode in a real browser, code splitting, declarative UI, resource bundles, and HtmlUnit-based testing. My team just upgraded from 1.7.1 and the process couldn’t have been easier.
Unlike the massive type and project config changes in 1.6 there is very little that requires tweaking for 2.0. We simply swapped in the new gwt-user, gwt-servlet, and gwt-dev jars (just a config change since we finally use ivy), tweaked our Eclipse run configurations to add some new parameters for dev mode, and were off in running in IE 8, Firefox, and Chrome. Dev mode is a relief and way faster than the old IE-6-based hosted mode (best experienced in Chrome or Firefox but still an improvement in IE 8), and Speed Tracer provides an easy way to figure out what’s going on in the UI similar to Firebug Net mode. It’s also convenient to have everything the compiler needs on any OS wrapped into the single gwt-dev jar now, so no more gwt-dev-${os}.jar parameters in our build across different environments. We haven’t had a chance to play with the declarative UI but I can’t wait to see what it’s capable of.
But all the great new features aside, the most surprising aspect of the upgrade was that our entire codebase was already 100% compatible. Not only did this make “upgrading” the project a non-event, but the project can now go forward building on both GWT 2.0 and GWT 1.7. This includes not only our massive amounts of homegrown GWT code but also GWT incubator, GWT math, GXT, and a handful of other libraries we’re using. This is extremely powerful for us because we also export a client source jar with a limited set of widgets used by other projects, and they’re now free to upgrade GWT at their leisure. Even better, a GWT 1.7-compiled client can perform RPC calls seamlessly with a GWT 2.0 server using the existing 1.7 serialization policies, so all sorts of combinations of legacy clients hitting our latest and greatest server are possible. Long-term I’m sure everyone will want to be on 2.0 but it sure makes getting there easier!
Hats of to the team at Google for all their hard work and such a solid delivery.
Stacking GWT 1.6 workers with ant parallel for super-fast builds
Having just built a new machine around a Core i7 950 enthusiastically overclocked to 4.2gz, I couldn’t help but explore the possibilities of a lightning-fast GWT compile. I regularly build a project that involves a core services war that’s pure Java along with a GWT 1.6 war consisting of two modules that requires 3 permutations each, all wrapped into an ear at the end.
Historically this took about 3 minutes running serially on a reasonable Core 2 Duo. It would run the core services war build, then the GWT build one module at a time, each using GWT 1.6′s -localWorkers 2 to at least make use of both cores.
The potential of 8 concurrent threads across the i7′s four cores and the presence of two GWT modules plus another build compelled me to resurect some old-school Ant parallelization to stack as much work as possible during the build. With a bit of tweaking it’s easy to have ant running multiple targets – some GWT and some non-GWT – at the same time, so that entire modules, not just permutations, are built in parallel. For example, something like
<target name="gwt"> <java classname="com.google.gwt.dev.Compiler" fork="true" failonerror="false"> <arg value="module1" /> <arg value="-localWorkers" /> <arg value="1" /> </java> <java classname="com.google.gwt.dev.Compiler" fork="true" failonerror="false"> <arg value="module2" /> <arg value="-localWorkers" /> <arg value="1" /> </java> </target>
becomes
<target name="gwt"> <parallel threadsperprocessor="1"> <java classname="com.google.gwt.dev.Compiler" fork="true" failonerror="false"> <arg value="module1" /> <arg value="-localWorkers" /> <arg value="4" /> </java> <java classname="com.google.gwt.dev.Compiler" fork="true" failonerror="false"> <arg value="module2" /> <arg value="-localWorkers" /> <arg value="4" /> </java> </parallel> </target>
The result was phenomenal. My 3 minute build now takes only 40 seconds! If you have lots of cores available be sure to consider stacking ant parallel with GWT workers for a big improvement. Keep in mind that running many modules in parallel may also require ridiculous amounts of memory (around 600mb per module in my case), but on an i7 system you should have at least 6gb anyway right? 
Spring4gwt, or Spring’s harmony for GWT
I’ve had an idea itching at me for awhile now, which started shortly after building a complex enterprise application using GWT connected to Spring services on the server. There are countless blogs out there describing various ways to wire up Spring with GWT, and Google’s own Gin is quite adequate for client-only dependency injection. But what I’d really like is something that ties this all together, and in the true spirit of GWT, makes it easy for a seasoned Java developer to apply proven, consistent DI practices in both the client and server using the Spring knowledge they likely already have.
My vision is basically this:
@Component
public class SomeGWTComponent {
// Some other client-side component
@Autowired
private MyWidget widget;
// A remote service proxy to a server-side Spring service
@Autowired
private MyService service;
public void doSomething() {
widget.doClientStuff();
...
service.doServerStuff("data", new AsyncCallback<String>() {
public void onFailure(Throwable caught) {
...
}
public void onSuccess(String result) {
...
}
});
}
}
}
It’s important that MyService is a vanilla Spring service on the server – no extension of RemoteServlet required – and that MyWidget is any other GWT component. Injection should occur when the component is created, potentially with varying scopes just like on the server, and potentially also with @PostConstruct support for code to be executed after injection, leaving the constructor available for any pre-injection initialization. And finally, as much work as possible should be done during GWT compile minimize the run-time cost.
The approaches to GWT lookup/injection I’ve seen out there have at least one the following gaps:
- They’re client-only (Gin)
- They’re largely run-time, and slow (MVC helpers in component libraries like GXT)
- They involve SpringMVC or other unnecessary server-side complexity (most blog guides)
So I’m going to try to bring this altogether in one simple library with the following goals:
- Simplicity: Access Spring services from the client through a generic exporter; no service-specific mappings in web.xml, forced type hierarchy (services should be existing Spring POJO’s), or dependency on SpringMVC. In other words, when a new Spring service is added to the server it should require zero configuration changes to be accessible in the client if desired.
- Consistency: Client-side dependency injection with native Spring look and feel; freedom to inject private members, via constructor, or via getters/setters with same Spring annotations and conventions that are already familiar.
- Performance: Do all the heavy lifting with GWT generators to keep the client lean.
Behold, spring4gwt where I’ll do my best to make this a reality! The initial version captures objective #1, bringing together a generic servlet for exposing Spring services without turning each into its own RemoteServlet mapped in web.xml. Up next: accessing those services with Spring DI in the client!
GWT 1.6 and GXT 2.0-M1 upgrade experience
This past weekend I had a chance to upgrade a GWT/GXT project earlier than expected. We’ve had considerable pain on the current version of GXT and hoped this might lessen it; sadly, the grass was not much greener on the other side.
GWT for its part was a fairly straightforward process, even with all the significant “breaking” API changes like a new war-based project layout, new eventing model, new compiler, and revamped hosted mode (see the complete list here). The steps involved were essentially:
- Bring in the new jars
- Move resource directories and web.xml into the new preferred war location
- Fix compile errors (mostly new event/listener type and getters/setters replacing public members)
- Change the compiler and hosted mode classes to the new ones, with the new args
- Toy with the hosted mode and build classpaths so that Selenium is in the classpath first for unit tests, but GWT is first for hosted mode (because our project uses Selenium for UI tests and both Selenium and GWT are nice enough to bundle Jetty – and different versions, no less – as dependencies; Selenium, please move to Jetty 6 already!)
Additionally, each developer on the project had to disable/re-enable their GWT profile in Eclipse to have it detect 1.6 mode and re-create any run targets (not a big deal really, since the GWT Eclipse plugin makes this much easier than before!).
We have run into one intermittent problem worth noting: When attempting to run our client with a mock services stack (simple web.xml with local servlets that return test data), hosted mode will occaisonally freeze on startup. Debugging has revealed that our RPC calls are initiated but never returned. Base on the randomness and timing of the freeze it almost looks like a race condition where the mock services aren’t deployed as fast as the client, and hosted mode gets stuck in a loop waiting for the return on a call that was never received. Since our application has a rather custom setup where we run RPC against a different context in production (separate services war inside the same container), and this is also something we’ve attempted to mock, it’s not bad as a single issue; our workaround is to simply run the mock service stack externally on Jetty via an ant task and use hosted mode solely for deploying the client.
GXT on the other hand was a nightmare. GXT issues were the main driver behind our early upgrade – since the 2.0 release date keeps moving we decided to bite the bullet now and try M1 in hopes that it would fix more than it breaks. The obvious breaking changes were minimal – just some type changes, event differences, and slight re-arrangement of classes. But in terms of functionality the visual layout of the application was immediately wrecked on upgrade due to a number of blatant bugs (or very questionable behavior changes). Note that after our initial run-through we downloaded the very latest 2.0 snapshot from svn (as of 4/26/2009) and built that with similar results:
Percentage/pixel sizing problems
On components using a CardLayout (like TabPanel), height and width percentages get changed into raw pixels. In other words, calling setHeight(“100%”) results in HTML with height=100px embedded in it. This is incredibly annoying and I can’t overstate how thoroughly it breaks an application. Since our application sizes very dynamically and we intentionally avoid fixed size like the plague, it immediately became a mangled cluster of 100×100 boxes. Entertaining yes, but difficult to fix. We’ve ended up implementing a mixture of fixed heights/widths on the affected components and trying to delegate more explicitly to parent sizes until there’s a permanent fix.
Tighter coupling
Components seem less designed for extension, or at least more tightly coupled to each other and the DOM; for instance, several components that we’d extended and overridden onRender() for specific functionality blew up spectacularly, requiring that we override and assuage other methods to make them content again. The changes aren’t bad, but a framework doesn’t feel well thought-out when I’m forced to hack things one way in release x, then hack them a different way in release y.
CSS changes
To the GXT team’s credit the CSS tags used by objects are largely unchanged, however the css behavior and default values of many components are different; this was mostly an impact where we’d intentionally hacked things in CSS to make them look correct cross-browser and the hack was no longer necessary (or worse, now causing an issue). Our bad for hacking, but again, it sucks when a framework forces you into this, then keeps changing it.
New features incomplete
Any of the big “new” features we tried like HBoxLayout and VBoxLayout seem incredibly incomplete or broken. For example, attempting to use a VBoxLayout resulted in a panel rendering partially in the correct spot with its children lined up at the bottom of the screen, below the rest of the application; source inspection revealed some serious div madness going on. Based on this state of fail we’re not planning to dive further into any new features until it’s GA.
All in all the net change in GXT 2.0 as of M1 seems to be slightly better performance and a mild set of new features, yet with most of those new features broken and some very serious and annoying core bugs such as the percentage/pixel issue. I really hope they’re hard at working fixing these, as the pushed release date may suggest, and that the final release has some honest documentation on ALL breaking API changes and known issues, especially since documentation is something GXT has always lacked. I would highly recommend against anyone taking 2.0-M1 unless pain is something you enjoy, considering the serious issues and the fact that none of the new features feel usable yet.
GWT 1.6 by contrast is a no-brainer; if you’re lucky enough to be building an app with core GWT and homegrown components and/or another library this will probably make your life much easier. The war layout makes for even tighter integration with Java and is great for projects that are a mix of GWT and static content or other UI technologies. And the new configurability of the compiler makes parallel compilation or even disabling some browser permutations as easy as a few compiler args or lines in your .gwt.xml.
To the Ext guys: I really hope you have something better in store for us by 2.0 GA! The team I work on has many developers who’re new to GWT development and have backgrounds in custom AJAX, Flash, or C# UI’s. GXT 2.0 is continuing to build their impression that this technology is a hack that brings the “worst of both worlds”: they see a complex framework that’s lacking many features, yet is difficult or impossible to extend in a way that will be a) consistent cross-browser and b) not break completely on upgrade. Combined with the lengthy build/deploy time to test small changes in real browsers, it’s feeling like a net loss vs. straight AJAX (in JavaScript) or, better yet, another RIA technology completely such as Flash or Silverlight.
It’s worth noting that none of the pain points I’m belaboring, especially when it comes to CSS weirdness and cross-browser testing, are anything unexpected for traditional web application development. But they should not be the norm for GWT: a library on top of GWT that experiences all these pitfalls with regularity seems to miss the point. We expect something in return for long compile times and difficult-to-debug generated code; certainly more than just the convenience and familiarity of Java versus JavaScript.
But as someone heavily vested in a GXT project, here’s hoping even more that it shapes up a bit by 2.0 GA!
GXT is cool, but painful
Let me start by saying I’m completely on board the thin-client bandwagon. I think lightweight web applications are the future of everything from simple apps to enterprise software, and loved the premise of the Google Web Toolkit (GWT) from the start. So naturally when I had a chance to use GXT – Ext-JS’s framework that bridges their sexy JavaScript library with the promise of GWT development – I had high hopes. So far, I still feel the potential but can’t bring myself to love it quite as much as I want to.
The whole point of GWT is to take fragile and tedious web 2.0 development and make it feel like you’re actually building software: write one set of code that’s reusable and browser-agnostic, add handy modern language features like generic types and annotations, support a (relatively) fast change and deploy model, and best of all, at the end of the day still build good-old-fashioned HTML and JavaScript that runs in any browser: no Flash, Applet, Silverlight, or hardcore server-centric architecture required.
The core GWT guys get this and have made huge strides. The biggest beefs like IDE integration, richer hosted mode, and faster compile are all getting addressed. Integration with standards like Spring and Hibernate are already there and work amazingly well, if not quite out-of-the-box. For example, check out Giving GWT a Spring in its Step and Gilead.
By itself Ext-JS is also a great JavaScript library, with some of the best looking and most functional components out there. But so far their take on GWT misses the mark. The framework’s architecture – and more importantly, day-to-day use of it in real application code – screams JavaScript at every turn. Yes, I know this code will be used to build more code that runs in a browser at some point but it’s not supposed to constantly remind me of it! I don’t like switching between strongly typed objects and BeanModels full of string properties, having to bury myself in ten levels of CSS to make any slight component change look good in both Firefox and IE, or find their generic contortions that entertaining. It’s like the Ext guys are so lost in JavaScript that they missed the point of GWT.
The irony is that they’ve built a lot of tools that solve these problems individually quite well: there’s a BeanModelTag that will assemble reflection-like metadata when beans are sent to the UI and provide it on-demand using a factory from the bean, allowing you to switch between their models and the original beans as needed. The css for the components themselves is incredibly specific, well-organized, and for the most part consistent. The event framework, while not totally complete, is easily extended. These pieces just need to be put together with some level of configuration and convention so that day-to-day application code can focus on the look and feel instead of boilerplate MVC connectivity. In short they need to focus on how Java developers build applications, rather than how web developers can write the same kind of client code in Java. I’d love to be able to populate data in a UI component by doing the following:
- Write the server-side Java service
- Expose the service with simple annotation-based name and/or URL
- Create a client component that takes a data store and assign that store to the service endpoint
Ironically, this is the kind of thing that JSF components via Seam and Flash via Flex with BlazeDS do really well. The Ext components look way better than any JSF component library and are easily on par with their Flex counterparts, and that eye-candy appeal wins them a lot of ground (especially from those non-technical decision makers!). Architecturally, not depending on Flash or a heavy Java server puts them ahead of the curve: just put some implementation-level polish on it please!
I still have high hopes for GXT 2.0 which is currently in preview. The project I’m working on is standing by on 1.2.3 for now but we’ll switch over eventually and see how it goes.
Recent Comments