OpenLaszlo 4 “Legals”: A Train Wreck in Slow Motion?
December 28th, 2006 by Robert Yeager
Cooqy is developed with OpenLaszlo, a wonderful open-source tool for developing Rich Internet Applications (RIA’s). OpenLaszlo v3.3.1 has proven to be a very stable and productive tool. I consider it to be the finest development tool I have used in my 20+ years of software development.
OpenLaszlo has truly made software development fun for me again. I was really getting burned out by the tedious JSP/.NET approaches to static website development. AJAX tools are just an incremental improvement, suitable for enterprises with an existing investment in legacy technologies. For the first time, with OpenLaszlo I could develop applications that worked well on multiple platforms and browsers with little trouble. So much of web development is just tedious…OpenLaszlo effectively hides all the complexities of web-based development, allowing developers to focus almost exclusively on building the value-add functionality. This is a tremendous productivity boost!
OpenLaszlo 4 (aka “Legals”) was announced with great fanfare earlier this year, with the promise of offering a DHTML runtime. OpenLaszlo from the beginning was intended to emit multiple runtimes, besides just Flash. The selection of DHTML (and later Java Micro Edition) should have been building upon the already solid Flash runtime foundation. But alas, the OpenLaszlo development team has made decisions that I feel are leading to potential disaster.
The OL4 development team decided to totally rewrite the runtime compiler from the ground-up. This means that the Flash runtime generator was gutted and replaced. So instead of taking a very stable foundation and carefully snapping in DHTML support, the OL4 team decided to throw out the baby with the bath water and start from scratch.
All-or-nothing decisions in software development are almost never made…the risk is just too high to accept, especially with a compiler-based product like OpenLaszlo with lots of existing projects already in the field. The trouble with compiler-based products is that although you may be able to write enough test cases to cover the syntactic differences between the new vs. old versions of the compiler, you will *never* be able to weed out the semantic differences (the behaviors of code interacting together at runtime).
Throughout the year, I have been downloading the OL4 preview releases, in addition to the first beta release made just before Christmas. Every time, none of my existing code has worked with the Flash runtime, due to the rewritten Flash runtime compiler. I end up having to delete my existing code and stitching it back together line-by-line to find what isn’t compatible with the OL4 release. It has been improving with each release, but still none of my code is entirely working in the Flash mode. I fear that all OL3 legacy code will experience similar trouble, as confirmed by this thread tonight. DHTML runtime generation is even worse. I finally got fed up and posted this thread on the OpenLaszlo forum, which received the attention of OpenLaszlo’s Founder & CTO David Temkin.
I expected the DHTML runtime to be problematic for some time, but the loss of the stable Flash runtime is an expected red flag. They might as well call it a new product, because I feel that the likelihood of legacy OL3 code ever running on OL4 is slim to none.
DHTML is an interesting beast itself. A huge issue is that when runtime errors occur, you get the normal browser popup box displaying the error. Problem is, the error relates to a compiler-generated source file. So when it gives the line number with the error, you have no hope of finding the cause of the problem, unless you are lucky and can identify the little snippet of Javascript code displayed in the popup. I tried the Firebug extension for Firefox as recommended, but never could find a way to troubleshoot Javascript runtime errors with the DHTML output. Maybe someone who knows how can inform me.
I know that OL4 will continue to improve…but at what cost? How do you measure the cost of new developers who download OL4 expecting Flash/DHTML panacea, only to find that legacy components don’t function? How do you measure the impact to existing developers who expected to have a rock-solid Flash foundation that has benefited from years of development? I predict that OL3 will flourish and that OL4 will be stagnant for a long time to come…until robustness in the Flash runtime is proven again.
With OL4, I feel I have been watching a train wreck in slow motion all year long. Or maybe it’s more like watching someone you love do something stupid with their life.
Looks like I will have to develop a traditional HTML website for Cooqy in the weeks ahead, instead of my plan to convert the existing Flash website to DHTML…darn it.
8 Responses to “OpenLaszlo 4 “Legals”: A Train Wreck in Slow Motion?”
Leave a Reply
You must be logged in to post a comment.
The current OpenLaszlo 4.0 version is a beta release candidate. There are still about three month left before the release of the 4.0 version. Based on the quality of the previous releases of the OpenLaszlo server I don’t have any doubt that the 4.0 version will have reach the same quality level.
Everyone using the 4.0 version right now should be aware of the fact that this is the first platform on the planet to generate Flash and DHTML/AJAX output from the same code base. I’m not the architect of the server but I know that the support of multiple runtimes requires a different architecture. With the new architecture it should be a lot easier to implement yet another runtime target for OpenLaszlo (like Java Micro Edition, WPF/e, etc.).
I’m actually not so happy with the post title “A Train Wreck in Slow Motion?” you have chosen. People who haven’t been working with the OpenLaszlo technology can easily be kept from using this very fine piece of open source software if they only read the title of your post.
The Cooqy application you created looks very nice. If you had the success with the OpenLaszlo 3.x version, let’s all (the community) make sure that OpenLaszlo 4.0 will be an even bigger success. This is an open source project. So anyone willing to do some more testing and debugging is more than welcome.
I obviously don’t share your thoughts that just a few months of testing will improve OL4 to the point where it will be ready for full-scale development w/ Flash and DHTML. I feel a fatal mistake was made in choosing to rewrite the Flash compiler from the ground up…the ramifications of which will never entirely be resolved.
It’s like Humpty Dumpty at this point…I’ve given up hope that OL4 will be a quality product any time soon, no matter how much the community helps, because of the fatal decision made early on to throw out the stable Flash runtime generator.
Nothing would thrill me more than to be proven wrong!
Hi,
I just wanted to clear up some misnomers about the changes between OpenLaszlo 3 and 4. We haven’t rewritten the compiler, but we have changed the SWF runtime architecture significantly. So please, don’t be alarmed - the changes just aren’t that huge. However, I have to agree with you about SWF instability being an issue now - we’ve put a lot of emphasis on getting DHTML (and other runtimes) working well. We’ve tried hard to keep SWF compilation stable, but clearly there are issues. As an open source project, we rely on community members to help us out by reporting bugs, giving us sample code, and helping us identify and fix bugs.
Remember, 4.0 is still pre-beta. At this point (4.0 Beta 1 PR1) all of the built-in components and demos work well. We welcome any sample applications or test cases that you’re having issues with - you’ve been a great supporter of the community, and we want to make sure Cooqy continues to be successful with 4.0. Please send me any sample code you’re having problems with! Let’s work together to make sure all your issues are resolved by 4.0 final.
Regards,
Max Carlson
OpenLaszlo.org
Thanks for the clarification re: the compiler rewrite, Max. When David Temkin said in his message (http://forum.openlaszlo.org/showthread.php?t=7654) that “OL4 is in fact built on an all-new foundation”, it sounded like a total rewrite from the ground-up. Certainly the loss of SWF functionality, strange runtime errors, and weird compiler errors made it feel all-new, as David said.
I remain a huge advocate for OL3, and OL in general.
Each preview release of OL4 has indeed shown steady improvements…the support for many more core components in the latest Beta 1 candidate is impressive…but by my estimation it is going to be a long time before OL4 will be robust enough for serious application development.
I will certainly try to do my part to contribute defect reports, but for now I have to focus on my real-world projects and stay on the OL3 path…which will be the case for many existing OL developers, I believe….yet another reason why OL4 will not improve anytime soon IMO, because I have clients who need solid RIA solutions today. I surely can’t recommend that my clients choose to use an unstable/unproven platform, when I can’t even get my own code converted and functioning.
PMG! Reading your blog makes me realize just how little I know. Thank god for Graphic User Interfaces, which let me survive without knowing all this stuff… LOL.
Hi,
I found your blog via google by accident and have to admit that youve a really interesting blog :-)
Just saved your feed in my reader, have a nice day :)
[…] will be around October. Still, OpenLaszlo’s DHTML support has come a long way since I wrote this post. I’ll share my recent experiences with nightly builds of OpenLaszlo in a forthcoming […]
[…] will be around October. Still, OpenLaszlo’s DHTML support has come a long way since I wrote this post. I’ll share my recent experiences with nightly builds of OpenLaszlo in a forthcoming post. […]