An amazing feature of OpenLaszlo is the backward compatibility of the platform for old OpenLaszlo applications. Take the weather widget, for example. Here is a version of the app running on an old Laszlo Presentation Server version 2.1.2 (released in 2004).
If you want to test the developer console, this is the link to the LZX file. Now here is the same application running on an OpenLaszlo 4.4, in this case utilizing the SWF9 runtime.
And again, if you want to test the other runtimes (SWF8 and Ajax/DHTML) for this app, here is the link. It’s not like you don’t have to adjust your LZX source code with the next major release, but the platform never underwent a change that made it impossible to migrate your applications to the next major release.
Tucker from the OpenLaszlo team posted a good description of the backward compatibility approach in the OpenLaszlo mailing list:
I’d like to restate/clarify our backward-compatibility policy for both our users and developers, since there appears to have been some confusion lately.
Our rule of thumb is, when deprecating a feature, we support it for one whole release along with the replacement feature so that client code has a release to adapt. More explicitly:
- Release N-1: Feature X exists.
- Release N: Deprecate feature X, introduce replacement feature Y.
- Release N+1: Remove feature X.
In release N, client code will get a warning when using feature X, and they can change to using feature Y to silence that warning. When release N+1 comes out, if they have no warnings in release N, their code will continue to work.
For the Flex folks who have been working with Flex since the 1.0 or 1.5 versions this might sound incredible. What a trouble was it for many people when Adobe silently changed the underlying language for Flex 2 from ActionScript 2 to ActionScript3. Silverlight/WPF developers can tell you the same thing about the changes within Silverlight from version 1.0 up to the 3.0 beta. For most RIA frameworks utilizing proprietary browser plugins moving to the next version has been a huge problem.
Upgrading your application to the next OpenLaszlo version can still mean a lot of work, if you upgrade from a version like 4.1 to 4.4, where the compiler had to suppport a completely new language – ActionScript 3 for the SWF9/SWF10 runtime. But it’s possible to migrate even large and very large applications to newer versions of the OpenLaszlo server. Take for example g.ho.st or Laszlo Webtop, both very large and complex apps with probably more than 100,000 lines of client-side LZX code. g.ho.st was the first large application that had been ported to OpenLaszlo 4.2, running as a Flash9/SWF9 application.
The fact that OpenLaszlo 4.4 supports DHTML (JavaScript 1.5), ActionScript 3 and Flash7/Flash8 bytecode as an output format can be taken as a proof, that the addition of another runtime will be relatively easy, meaning: if you build OpenLaszlo applications now, you can expect them to run on future runtimes like Silverlight as well, with only relatively small changes to the code base.
