Archives

photo credit: Amateugrapher

We recently finished a first release of a data visualization application. The application was written in Flex and needed to draw curves with up to 250,000 points total between them. To do this in less than a half a second took quite a bit of optimization, to the point where we could have written a 3D real-time video game with our rendering code.

I was curious to see what the performance would be on other browsers with HTML5 Canvas. I put together a simple GWT program to run each browser through it’s paces. The target on the Macbook Pro I was using: 400 milliseconds, which is what the Flex app could do for 250,000 points. The results?

• Opera 10.53 – 160 milliseconds.
• Safari 5.0 – 180 milliseconds.
• Firefox 3.6.4 – 180 milliseconds.
• Chrome 5.0 – 200 milliseconds.
• iPad – 2500 milliseconds.
• IE ? – Blech. Don’t ask. Minutes. It likely has something to do with the GWT implementation.

For a long time if you suggested using web technologies for complex graphical operations, you would have been laughed out of the room. When the tools and libraries catch up to Flex/Flash, however, these days nobody will be chuckling at HTML5.

photo credit: bienvu

I’ve been working on a GWT application that makes use of HTML5 local storage to persist state between loads. The target for right now is the iPad and the two webkit browsers — Chrome and Safari.

I wasn’t all that happy with the speed of the local hash storage, so I decided to test out the db versus hash performance. First off was writing. After coding up a quick benchmark and storing 20,000 key-value pairs in both the hash and a db table, I had some really odd numbers:

• Mobile Webkit (on the iPad): 0.96 seconds for the hash, 1.24 seconds for the database
• Chrome 5.0 (Mac): 18.39 (!!) seconds for the hash, 0.31 seconds for the database
• Safari 5.0 (Mac): 0.05 seconds for the hash, 0.17 seconds for the database

What stands out here is the slow performance of Chrome. I’m going to try and do this in vanilla JavaScript, just to take GWT out of the equation. I hope that’s what it is, otherwise this looks like a Chrome bug.

photo credit: vieux bandit

Thanks to some code contributions, I’ve released a new version of JSONWrapper for GWT. New are the addition of Boolean and Integer accessor methods. I’ve been making quite a bit of use of this library recently, lots of it in relation to efficiently storing data as JSON in HTML5 storage. Very handy to have and saves a ton of time. Enjoy.

Well, GWT 2.0 RC1 (yes!) is out. I was going to wait for a while with some of my new projects until switching them over to GWT 2.0, but given the pace of the GWT 2.0 project, I may just switch them over now rather than going through a painful migration.

I’m especially eager to use UiBinder to do declarative UI creation. Just specify how your interface should look in XML:

I used to scratch my head at the name for the JavaScript library qooxdoo. That’s until I ran into the developers of the library at an Ajax Experience event in Boston a few years ago and they pronounced it “Kucks Du” as in “Was kucks du” or German for “what are you looking at?” Beyond the basics, qooxdoo is a mature collection of JavaScript widgets, despite the authors’ conservative versioning policy (they’re still only at 0.8.3).

It’s taken them long enough, but they’ve finally released a wrapper for GWT, named QxWT. Best of all, they have a commercial-friendly open source license. If you’re put off by GXT and it’s license, you owe yourself a look.

Never get involved in a land war in Asia.

– Vizzini, The Princess Bride

.

Also, never get involved in a religious war about statically versus dynamically typed languages. Well, maybe just this once.

Periodically, an angry Javascript developer will let loose and flame GWT as a misbegotten spawn of evil. Then all the GWT developers point and chuckle and move on to developing more cool applications. Every so often, though, someone will make a thoughtful comment about GWT, and then we have a fruitful discussion that helps clarify what GWT is and what it does and doesn’t do well.

William Shields has either posted such a thoughtful comment or a very high end version of a flame, entitled Lost in Translation or Why GWT Isn’t the Future of Web Development. It is well worth reading, along with Google’s Joel’s somewhat heated response.

It’s been out a few weeks, but I thought I’d point out that’s it’s been pushed. Mostly some changes to the LayoutPanel.

On seeing that someone had developed a Grails Plugin for Vaadin (the former ITMill Toolkit, based on GWT as a front end technology), I immediately grabbed it and started exploring. One of the first things I do when developing things that look like GUI’s is apply PureMVC to it. It’s sort of like a big MVC switchboard that lets you hook together the smaller MVC’s of whatever framework you’re using. Overkill for really simple applications. Crucial for big ones.

Building a PureMVC app was pretty quick, but I ran into a small problem. Since PureMVC Multicore uses a Multiton pattern (essentially a map of Singletons), when Grails recompiles and restarts on code changes, the application barfs with a “Facade already constructed” runtime error. The solution is simple. In your subclassed org.puremvc.java.multicore.patterns.facade.Facade, change the following:

  public static ApplicationFacade getInstance() {
    if (instance == null) {
      instance = new ApplicationFacade(CORE)
    }
    return instance
  }

to this:

  public static ApplicationFacade getInstance() {
    if (instance == null) {
      // nuke the multiton so we can do the grails recompile
      if (ApplicationFacade.hasCore(CORE)) {
        ApplicationFacade.removeCore(CORE)
      }
      instance = new ApplicationFacade(CORE)
    }
    return instance
  }

And voila, your app now recompiles and runs without a hitch, just like a Grails app should. (CORE is a string constant to name your core.)

Related Services: Java Application Development, Custom Software Development

Florian Mounier has spent the last six months developing GWT UML, a slick little UML diagramming tool written in, obviously, GWT. It’s smooth, good looking, supports class, object and sequence diagrams. You can save your diagram as a url or export it to an SVG. You wouldn’t try to do model driven development with it, but for embedding in a development wiki, this thing could rock.

You can find more information at the google code project and check out a demo here.

Some interesting posts from around the blogosphere:

• The GWT Plugin for Grails has been stuck in version 1.4.x of GWT for forever. Michael Galping has published a two part (one and two) series at IBM Developerworks on integrating Grails and GWT 1.5.3. Extensive, well illustrated with full source code available for download.
• InfoQ has published an interesting conversation about Ajax and COMET versus HTML Web Sockets, i.e. hacky COMET versus real bi-directional communication mechanisms between the server and browser.
• UXDesign.com has a concise summary of an Alan Cooper Interview video from 2008. User Experience Design, baby!
• David Hamill has some provocative musing on the difference between usability and user experience design. Not sure I agree with everything he has to say, but it’s a question that comes up often and is worth thinking about.
• A bit older, but I just came across it: the original ScrumMaster, Jeff Sutherland, has an interesting article about ROI and incremental development. The conclusion? Incremental is better. But seriously, we don’t have enough rigorous thinking and writing about how good design and process reduces the cost of software in the long term (while perhaps increasing it in the short term).

These were some of the posts that I found valuable over the last week. Please share yours in the comments.