Subscribe to
Posts
Comments

Qrowd was built using the nightly builds of OpenLaszlo’s 4.x releases. OpenLaszlo’s 4.x releases are where the DHTML runtime was first introduced over a year ago. The 4.0.x releases until recently were pretty much disasters, in the sense that not only was DHTML not a viable runtime for serious application development, but the Flash runtime support was also torpedoed in the process. Taken together, OpenLaszlo went through a year-long period of time in which serious development could only be done using the 3.x Flash-only runtime.

After a long year of suffering the bleeding edge nightly builds while DHTML support gestated and Flash support was stitched back together, I believe OpenLaszlo 4.0.x is getting ready to blossom into 4.1 this spring, the first release in which both SWF and DHTML runtimes should be ready for development of reasonably complex applications. Based on my experience with the latest nightly builds, DHTML support is still not quite ready for prime-time large-scale applications, though.

Qrowd’s visual wiring editor was developed to run with both Flash and DHTML runtimes, for no more reason than to see how far DHTML development could be pushed. While developing on nightly builds had its ups and downs, progress was steady up through October 2007. Especially on Firefox, at one point in October the DHTML runtime was performing even better than the SWF version on Firefox. IE support has always been very problematic, however. More often than not, IE DHTML simply doesn’t work. A DHTML runtime that doesn’t work with IE isn’t of much use. Sometime after October, performance of DHTML on Firefox tanked, which was really disheartening.

As of the more recent nightly builds, Qrowd’s wiring editor launches in DHTML with Firefox and Safari, but not IE due to issues I have reported in their issue tracking system. On Firefox and Safari, the look of the app is virtually identical to what appears in Flash, but the performance is too slow to be usable. (Anyone wanting to take the DHTML wiring editor for a test drive themselves can leave a comment or e-mail me.) I keep hoping that whatever has tanked performance since October will be fixed, but so far that hasn’t happened.

On the upside, less sophisticated apps like the widgets that can be created with Qrowd run rather well in DHTML with Firefox, Safari, and IE. The differences between the Flash runtime and the DHTML runtime are rather subtle. The download footprint sizes are roughly equal. DHTML provides a better fade effect of text. With Flash, text fading requires embedded fonts, which greatly increases the download footprint. Flash offers shadow and glow effects that aren’t available in the DHTML version. The biggest downside of the DHTML runtime as far as I am concerned is that although the “major” browsers can run the widgets, notable browsers like Opera cannot. Then again, it should be possible for the Safari browser on the iPhone to run the DHTML runtime, since the iPhone doesn’t currently have Flash support.

So, was DHTML support worth the wait? I believe yes, but only if all the IE gremlins are addressed. I am happy to have a DHTML runtime that supports the major browsers (IE, Firefox, Safari) that together comprise over 95% of the browser market. One huge advantage of the DHTML runtime is that it makes for better integration with HTML websites. Qrowd uses DHTML on its website here and here. In situations like this, Flash won’t work as well, primarily due to sizing of the canvas. Since the DHTML canvas is a DIV element, I was able to grow it as the list expands, which in turn expands the CSS border. Doing this in Flash is possible, but would be harder since the Flash app would need to invoke Javascript to stretch the dimensions of its container. Having DHTML offers better solutions for certain problems…another arrow in a developer’s quiver of tools. Looking ahead, the work Laszlo Systems invested in the 4.1 release should provide many future benefits, as the technical groundwork has reportedly been laid to more quickly add future runtime options to OpenLaszlo. Silverlight may be a compelling choice, after it matures and penetrates enough of the market.

Unlike Javascript DHTML (AJAX) toolkits, OpenLaszlo provides an easy-to-use application stack that makes writing cross-browser web apps palatable. As with any higher-level abstraction, the benefits of less effort and shorter development times come at a cost of bulk in the form of the runtime library and some loss of fine-level control. For me, the benefits of an open-source, cross-platform multi-runtime web app software tool are clear…I only hope that the delay of OpenLaszlo 4.1 hasn’t caused a lost market opportunity. I have experienced many times when a superior technology loses out to an inferior technology’s marketing nimbleness…anyone recall OS/2 Warp vs. NT when it was Not There?

del.icio.us:OpenLaszlo 4.1 DHTML:  Worth the Wait? digg:OpenLaszlo 4.1 DHTML:  Worth the Wait? spurl:OpenLaszlo 4.1 DHTML:  Worth the Wait? wists:OpenLaszlo 4.1 DHTML:  Worth the Wait? simpy:OpenLaszlo 4.1 DHTML:  Worth the Wait? newsvine:OpenLaszlo 4.1 DHTML:  Worth the Wait? blinklist:OpenLaszlo 4.1 DHTML:  Worth the Wait? furl:OpenLaszlo 4.1 DHTML:  Worth the Wait? reddit:OpenLaszlo 4.1 DHTML:  Worth the Wait? fark:OpenLaszlo 4.1 DHTML:  Worth the Wait? blogmarks:OpenLaszlo 4.1 DHTML:  Worth the Wait? Y!:OpenLaszlo 4.1 DHTML:  Worth the Wait? magnolia:OpenLaszlo 4.1 DHTML:  Worth the Wait?

One Response to “OpenLaszlo 4.1 DHTML: Worth the Wait?”

  1. […] conjunction with the rollout, I’ve written a post describing my experiences with OpenLaszlo’s 4.x DHTML runtime. Will be of interest to any technical folks out there wondering about OpenLaszlo’s DHTML […]

Leave a Reply

You must be logged in to post a comment.