BlackBox

Last night I presented part 2 of a 2-part series looking at Flex and OpenLaszlo at the Tucson JUG. Here are my final thoughts on the two (given a brief introduction to each):

• Both are good platforms for RIA
• I really like the fact that you can compile Flex apps in either XML or in ActionScript
• I like OpenLaszlo’s xpath notation for connecting to XML datasources
• I feel that Flex has really gained the mind-share of the Open-Source community. I found many more tools available to me in Flex-land than in OpenLaszlo
  • See BlazeDS, GraniteDS for some excellent Open-Source data and messaging providers for Flex
  • Maven and Ant(included with the Flex SDK) tools for Flex
  • Unfortunately the Eclipse plugin for OpenLaszlo appears to be gone, gone, gone.
  • Both have Unit testing frameworks available - ASUnit, FlexUnit, and LzUnit
• I like the fact that OpenLaszlo supports additional run-times through the new “legals” initiative (DHTML and others are in the pipeline through a partnership with Sun)
• I couldn’t find an easy way to setup a project for OpenLaszlo through Ant or Maven. I’m sure they exist but nothing turned up in a cursory search
  • I take it back, I finally found this on the OpenLaszlo wiki for ant tasks included with the source. But not packaged up all nice and clean like the ones for Flex. Blech.
• I also like how easy it is to create and modify components for Laszlo. I don’t know how easy it is to do this in Flex.
• The docs for OpenLaszlo are somewhat scattered and some are sorely out of date. Several examples on their own site didn’t work at all with 4.0.12

Overall I think I will be focusing my future efforts on Flex/ActionScript 3.0 and unfortunately leaving Laszlo behind. I have been a fan of it for quite a while but I don’t think it has kept up at all with Flex and is starting to lose mind-share amongst the Open-Source community.

Periodically I will do small consulting gigs and recently had a client who wanted to know if there was a way that they could improve their development experience with Tapestry 4. Their specific problem lied in the fact that when they initially pulled up any Tapestry page it was incredibly slow to render that first time. They were not using the property org.apache.tapestry.disable-caching so that definitely wasn’t the issue.

The solutions that I came up with after doing some research and looking at their code were these:

• Use Jetty for development
• Convert as much of their pages (and components) to be “spec-less” as possible

Two primary reasons to use Jetty are that it allows you to more easily reload HTML changes and in general is a much more lightweight container than Tomcat, therefore getting an overall faster startup time and increasing development time. One of their own developers was already using Jetty and was seeing speed increases.

The primary reason to convert your HTML pages to be ”spec-less” (in other words no *.page file to bother with) is that reduces the overhead that Tapestry 4 puts into place to parse the XML file and figure out how all the components are wired together. Instead it puts this in either the HTML template, which it is already parsing, or in the Java class as an Annotation.

This also has the side benefit of prepping your code for converting up to Tapestry 5 as it uses no *.page files whatsoever.