Skip to main content

Laszlo: An Open Source Framework for Rich Internet Applications

March 22, 2005

{cs.r.title}









Contents
Rich Internet Applications
An Overview of Laszlo
   Why Flash?
   Laszlo on the Web
A Very Simple Application, Built Using Laszlo
   The First Login Screen
   Adding Behavior to the Login Screen
   Adding a Personal Information Screen
   Turning the Crank with Live Data
Evaluating Laszlo
   Should You Use a Rich Internet Application Framework?
   Should You Use Laszlo?

Being a Java programmer sometimes feels like being in the movie
Groundhog Day. In the movie, Bill Murray is stuck in a loop: every morning when he wakes up it's the same day (Groundhog Day). He relives the day over and over again, seemingly without reason. But the days are subtly different: each time he relives the same event, he learns a little bit more about how to be a better person. And, at the end of the movie, Bill Murray finally gets to move on and live the rest of his life.

Similarly, every year, without fail, Java developers get to see new programming frameworks and container models. And, in much the same way that Bill Murray gradually addresses his problems and becomes a better person, the frameworks are getting better, and helping us to become better programmers (or, at least, deliver higher quality applications in shorter time frames). But, in the same way that Bill Murray keeps seeing the same things happening over and over again, we keep getting presented with frameworks that keep solving the same problems over and over again. While JavaServer Faces looks much better than Struts, it doesn't enable anything new: it's just a better way of creating the same old HTML-over-HTTP web applications.

But just as Bill Murray eventually got to experience all of the days that come after Groundhog Day, we may be on the verge of changing how we build web applications. There's a growing restlessness in the air, and a growing movement towards rich internet applications. In this article, I'm going to give you a quick overview of Laszlo, an open source rich internet application development platform. First I'll give a high level overview of what Laszlo is, and how it works. Then I'll give you a quick tour through some of the basic features of Laszlo, and talk about what's involved in building an application in Laszlo. And, after that, I'll talk about where it works best, and when it makes sense to use Laszlo.

Rich Internet Applications

The phrase "rich internet application framework" is a lot like the word pornography: easy to identify (the old "I know it when I see it" standard) but hard to define. Generally speaking, when people say "rich internet application," they usually mean something that meets the following criteria:

  • The application is launched from (or even contained within) a web page.
  • The application provides immediate feedback to users when they interact with the application (instead of a two-to-four-second delay while a response is fetched from a server somewhere). And it eliminates the "white screen while we refresh the page" aspects of existing web applications.
  • The application uses modern user interface controls, such as tree controls or tabbed panels, instead of living with what was current at the time HTML 4.0 was drafted.
  • The application allows users to perform common "fat client" operations like drag and drop, or using keyboard navigation in a way that feels natural to them.
  • The application has the same the ease of deployment and almost universal reach of existing web applications.
  • The application does all of the above without requiring large amounts of platform- or browser-dependent JavaScript.

You'll note that the above list of criteria doesn't include a lot of technological guidance. That's because the field of rich internet applications is wide open, and there are a lot of frameworks and environments out there. Some of the leading contenders include:

However, while they use vastly different technologies, platforms for rich internet architectures have some interesting commonalities. Among them are:

  • They all use a client-side container model (see the sidebar The Client Side Container Environment). They achieve at least part of their performance boost by minimizing the amount of server communication--instead of loading an entire HTML page each time the user clicks, these frameworks either handle the click locally (without involving the server) or request data from the server, which they then process. This means that there really is a client-side application with state and a user interaction model--the client is a lot more than a web page generated on a server.
  • Most of them leverage web browsers for deployment. Web browsers are everywhere, and it makes sense to take advantage of this. Some frameworks are actually built in JavaScript (and thus stay completely inside of the browser), while others use browser extensions such as Flash to define their client applications.
  • Most of them use some form of XML-based language for defining user interfaces. HTML is, by far, the world's most popular way to define user interfaces. Almost all of the rich internet application platforms either use HTML, or use an XML language that resembles HTML, in order to take advantage of this familiarity.

An Overview of Laszlo

Laszlo Systems was founded in 2000 to "advance the web experience." In the early years of the company, "advancing the web experience" meant building and selling a Flash-based rich internet application framework to large enterprises. But in mid-2004, Laszlo went open source, and Laszlo is now a mature and powerful framework for rich internet applications that also happens to be free. And that's pretty compelling.

The Laszlo platform consists of two pieces: a declarative XML-based language called LZX that is used to write client applications, and an application server (and LZX compiler) called the presentation server.

The presentation server plays two different roles in a production Laszlo system. The first is that it compiles LZX applications into Flash movies when the applications are requested by a browser. In Laszlo, client-side deployment is the standard web model: to launch an application, the user loads a web page. The web page contains an object tag, which launches the Flash movie. The presentation server also maintains a cache of the compiled LZX programs (it only recompiles LZX programs when they have changed).

The presentation server also brokers data requests from client applications (basically, it forwards the requests to your server-side code). This was originally part of the architecture because of security restrictions inherent in Flash movies when Laszlo was originally architected, and will probably be removed in a future version of Laszlo.

LZX, the language that Laszlo programs are written in, is a hybrid language that looks a lot like XHTML. LZX has an XML tag syntax to define pages and user interface constructs, and uses JavaScript for procedural logic and state variables. This has two significant benefits:

  • It's easy to read. Laszlo programs often look like very clean HTML programs.
  • JavaScript is a very well-known programming language, with a loosely typed interpretation model. It works very well for defining client applications.

In a nutshell, developers write applications in a combination of LZX (for the client application) and some server-side code. The presentation server takes the LZX and compiles it into Flash movies, which are sent to the web browser.

Why Flash?

The choice of Flash as a delivery vehicle for rich internet applications is an interesting one. Many people think of Flash as either eye candy for the Web or as the delivery mechanism for silly, yet addictive, games. What's more, a sizable portion of the Web's most influential people think of it as actively bad. But Flash, especially Flash 5 (which Laszlo uses), has some very strong advantages.

  • Flash is designed for visually rich applications.
  • Flash is everywhere. In September of 2004, 97.3 percent of all web browsers already had a player installed that could play Flash 5 movies. This is even more impressive when you compare it to other technologies: Java is present in 87.9 percent of the browsers out there, and PDF is in 80 percent. Macromedia has done an amazing job of making Flash ubiquitous.
  • Flash is the same everywhere. The Flash player for Firefox behaves exactly the same as the Flash player for Internet Explorer. This stands in stark contrast to Java (different versions of the JVM behave very differently) and DHTML (which is implemented differently in every major browser).
Laszlo on the Web

Actually finding Laszlo on the Web can be somewhat confusing; there are a lot of sites out there, each of which contains a small part of the big picture. Here are some of the websites you should visit if you want to learn more:

Major Sites:

  • Laszlo main site: This is the website for Laszlo-the-company (as opposed to Laszlo-the-product). Up until October, they sold Laszlo as an enterprise platform for rich internet applications; now they're turning into a professional services and development company based on Laszlo applications and expertise.
  • Open Laszlo: As the site says, If you're interested in actively shaping the future of the Laszlo platform, and taking part in one of the coolest open source projects on the internet, this is where you belong.. It's still a bit bare-bones (Laszlo's only been open-source for a couple of months at this point) but it's worth watching.
  • IBM's Eclipse Plugin: This is a set of Eclipse plugins that help you to write Laszlo applications.

Relevant Weblogs:

  • David Temkin's weblog: David Temkin is the CTO, and one of the founders, of Laszlo. He's not a very prolific blogger, but a lot of what he has posted is interesting.
  • Oliver Steele's Weblog. Oliver Steele is the chief software architect at Laszlo, and a prolific blogger (though most of his blog entries aren't about Laszlo).
  • Sarah Allen's Weblog: Sarah Allen works at Laszlo. In particular, she's one of the people working on Laszlo mail.

Interesting Additional Components and Code:

  • Blogbox. These are small applications that fit within a website or weblog. There are quite a few of these, and the source code is provided. They also seem to have their own weblogs. For example, Soundblox also has a Blogger weblog. I really like the idea of weblogs (and RSS feeds) for widgets and documentation.
  • My Laszlo. This is, apparently, a place where people can post small applications and demo code. Right now, it only has four applications.







A Very Simple Application, Built Using Laszlo

LZX is a whole new language, and the architecture of a typical Laszlo application is very different from the architecture of a typical web application. It's impossible for me to take you through all of Laszlo, and explain how it fits together in detail. But by walking through part of a simple application, I can give you a good feel for how the language holds together, and what it's capable of (see the sidebar Getting Started Quickly (on Windows)).

The application I'll use is called Oranges. It does the following:

  • It presents the user with a login window.
  • It validates the user's login, and either returns an error screen or logs the user in.
  • Validated users are shown a screen telling them how many oranges they've eaten in the past year.

This isn't a complicated application. But it does have three screens (the login screen, the failure screen, and the data screen), some screen transition logic, and some user-specific data. Which means it's a fine way to demonstrate some of Laszlo's capabilities.

The First Login Screen

We'll start by designing our login page. Login screens have several properties: they're centered in the screen, they ask for a name and password, and they can't be closed or circumvented. Here's the Flash generated by the LZX compiler for a simple login screen:

This is a very simple screen, but it already illustrates some fairly important points about Laszlo. For example, if you type in your name and then hit Tab, you'll see an animation visually guide you to the next field. That's part of what Laszlo CTO David Temkin refers to as a cinematic user experience--users get visual cues and prompts that help them know what to do next.

Another important point is that you can click on the title bar and drag the window around. We've all become used to things like clicking and dragging in our desktop applications; an important part of rich internet applications is that they enable the same types of user interface actions in our web applications.

I also want to point out that I'm not showing you screenshots in this article; all of the examples in this article are actual applications compiled from LZX and embedded in this article using the object tag. In fact, here's how I embedded the login screen above:

	<object type="application/x-shockwave-Flash" data="example_one.swf" width="800" height="400">
<param name="movie" value="example_one.swf" />
</object>

The login screen above was pretty easy to write. In order to create it in in LZX, I simply used LZX's modaldialog class and added some text fields. Here's the complete LZX program for the first login screen:

	<canvas bgcolor="#335577"> 
<modaldialog name = "login_dialog" width="300" height = "200" title = "Please Login">
<form>
<view width="200">
<reverselayout axis="x" spacing="10"/>
<edittext></edittext>
<text>Name:</text>
</view>
<view width="200">
<reverselayout axis="x" spacing="10"/>
<edittext password="true"></edittext>
<text>Password:</text>
</view>
<button text="Login" onclick="login()"/>
</form>
</modaldialog>
<script>
login_dialog.open();
function login() {
// we'll implement this later
}
</script>
</canvas>

The most important point about this code is that it's at least as readable as HTML. LZX is a very readable programming language, and it's designed to look as much like HTML as possible (the button even has an onclick method). UI design in Laszlo is a lot like XHTML with a richer set of user interface controls and no cascading style sheets.

But even though the code is very readable, there's a lot going on in it. For example:

  • There's a single canvas node. LZX programs are XML documents, and hence they have to have a single root node, which in LZX is the canvas node. The fact that LZX programs are well-formed XML has several obvious advantages. But it's also a little problematic, in that the entire LZX program executes inside a single canvas. You can have multiple "window" objects, but they're all constrained to live in one canvas (and, hence, inside of a single browser window).
  • We included a script that executed when the program was loaded and opened the modal dialog. If we didn't do that, the screen would have been blank. Unlike Java, LZX doesn't define a main function; instead, any "top-level" scripts (scripts that are direct children of the canvas node) are executed when the program loads.
  • We used a form to hold several views. An LZX Form is a lot like an HTML form, and is used in similar situations.
  • Each view inside the form used a reverselayout to organize its fields. Like Java, LZX uses layout managers to arrange components.
Adding Behavior to the Login Screen

The next step in building Oranges is adding behavior to the login page. Remember that, as much as possible, we want the program to execute on the client side, without sending a large number of messages to the server. This means that instead of having the entire browser reload the page every time the application needs to show a new page, I'm going to define all of the pages inside of a single LZX application (which will be sent to the client as a single Flash movie) and write code to perform the page transitions myself.

I'm going to do this in stages. The first stage is simply adding event handlers to our form, and having it check whether the login is valid. As part of doing this, I'm going to turn both our login form and our login dialog into classes, and add methods to them. In the next version of Oranges, if you type secure as the password, you get one message. If you use any other password, something else happens.

Before I show you the code, though, here's the Flash generated by Laszlo for our new login panel:

The code for this version is very similar to the code for the first version. But, since we're exploring LZX, I've refactored it to take advantage of LZX's support for object-oriented programming. Rather than start by discussing the LZX object model, I'm going to show you the class definitions for the new login form and login panel, which I'm storing in a separate file named loginpanel.lzx. Here they are:

<library> 
<class name ="loginform" extends="form">
<view width="200" name="idview">
<reverselayout axis="x" spacing="10"/>
<edittext name="name"></edittext>
<text>Name:</text>
</view>
<view width="200" name="passwordview">
<reverselayout axis="x" spacing="10"/>
<edittext name="password" password="true"></edittext>
<text>Password:</text>
</view>
<button text="Login">
<method event="onclick">
var name = this.parent.idview.name.getText();
var password = this.parent.passwordview.password.getText();
login(name, password);
</method>
</button>
<method name="clear">
idview.name.setText("");
passwordview.password.setText("");
</method>
</class>

<class name="logindialog" extends="modaldialog"
width = "300"
height = "200"
title = "Please Login"
x = "50"
y = "50">

<simplelayout axis="y" spacing ="10"/>
<text name="failureMessage" fgcolor="red" width="280"> </text>
<loginform name="loginform"/>
<method name="setMessage" args="message">
failureMessage.setText(message);
</method>
</class>
</library>

In this code, instead of using canvas as the top-level tag, I used the library tag. The library contains two classes: loginform and logindialog. As before, LZX is very readable; most programmers can read the code and get a good idea of what's going on. loginform is a subclass of form that contains a pair of views (named idview and passwordview) and a button that doesn't have a name, but does have an onclick method.

The definition of logindialog is equally transparent: it's a modal dialog that contains a text field for messages and a login form. It also encapsulates how messages are displayed by defining a setMessages method.

As this example shows, defining classes in LZX is simply a matter of using the class tag. Most of the things you'd expect to be true are true: classes can extend other classes (including classes provided by Laszlo Systems), can contain embedded components and methods, and so on.

However, what LZX means by "class" is subtly different from most programming languages. LZX uses a prototype-style object model, where instances are (basically) created as copies of the class definition. To see what that means, consider the following two instances of logindialog:

	<logindialog name = "standard_login_dialog" />

<logindialog name = "dysfunctional_login_dialog">
<method name="setMessage" args="message" />
</logindialog>

Both login_dialog and dysfunctional_login_dialog are instances of logindialog (when we defined the logindialog class, we implicitly defined the logindialog tag as well). But dysfunctional_login_dialog overrides the definition of setMessage defined in logindialog. When we override a method definition on an instance, we're not deleting the old method definition, or even changing the behavior of any other instance. We're simply changing the behavior of a single instance. This is something that's not possible in more traditional languages like Java.

Note also that we didn't name the button in loginform. Logically, this is a lot like defining an instance variable with no name, and that's something that you can't normally do in an object-oriented language.

Another interesting aspect of LZX is illustrated by the login button in loginform.

		<button text="Login">
<method event="onclick">
var name = this.parent.idview.name.getText();
var password = this.parent.passwordview.password.getText();
login(name, password);
</method>
</button>

The onclick function references a JavaScript function named login that isn't defined in the library at all. This simply becomes a call to a global function, defined in a <script> block inside of the main program. The presentation server will bind the call when it builds the Flash movie; until then, there's no way of knowing whether the function being referenced exists.

Now that we've defined our classes, it's time to look at the actual program. Here's the code:

	<canvas bgcolor="#335577"> 

<!-- Most of our custom objects are defined in library files -->

<include href="loginpanel.lzx"/>

<!-- Define some visual objects -->

<logindialog name = "login_dialog" />

<!-- Define the login function -->

<script>
<![CDATA[

function startApp() {
login_dialog.open();
}
function login(name, password) {
if (invalidLogin(name, password)) {
login_dialog.setMessage("Dude, That Was Both Lame <b>and</b> Bogus")
}
else {
login_dialog.setMessage("You logged in. <b>Awesome!</b>");
}
}
function invalidLogin(name, password) {
if (password=="secure") {
return false;
}
return true;
}
]]>
</script>


<!-- Let's get the party started -->

<script>
startApp();
</script>
</canvas>

This is really straightforward code: we include the library, we create an instance of logindialog, and we define the login function it requires. But somehow, out of that, we've got fairly rich behavior, in a browser-based application, using an object-oriented programming language. That's pretty neat.







Adding a Personal Information Screen

The next step in building Oranges is to add in a second screen, which tells the user how many oranges they've eaten. In order to do this, I'm going to take advantage of another one of LZX's features and use an XML dataset. In LZX, information is usually stored in datasets, and then accessed via XPath. In fact, datasets are important enough that there are two distinct ways to interact with them in LZX: either via Datapaths or Datapointers.

For starters, here's what an XML dataset looks like:

	<dataset name="people">
<people>
<person>
<loginid>dsteinberg</loginid>
<firstname>Daniel</firstname>
<lastname>Steinberg</lastname>
<numberoforanges>124</numberoforanges>
<password>secure</password>
</person>
<person>
<loginid>chromatic</loginid>
<firstname>chromatic</firstname>
<lastname>NA</lastname>
<numberoforanges>10089</numberoforanges>
<password>reallysecure</password>
</person>
</people>
</dataset>

Strictly speaking, this is a local dataset; it contains all of its information, instead of simply containing a reference to the information. The structure is simple, though: you use the dataset tag and then, within it, store data in XML format.

At this point, if you're an experienced DHTML programmer, you might be thinking, "Why aren't we using JavaScript arrays and variables to hold information? After all, we are building web applications, and in DHTML applications, client-side application state is usually stored in JavaScript variables."

The answer is that datasets are simpler, cleaner, and more standardized. Using datasets involves deciding on a representation. (In the example above, loginid is stored in a subtag of person instead of as an attribute. Why? Because that's the way it's done in the example.) But everything except the particular choice of representation is done in a standard way. This is in stark contrast to DHTML and JavaScript, where it seems that every web application does things slightly differently.

The information inside of an XML dataset is manipulated via XPath (note that while it doesn't support all of XPath, LZX supports a fairly large subset of XPath). While a complete discussion of XPath is well outside of the scope of this article, it's fairly easy to use basic XPath expressions by following a few simple rules.

  • Pretend you're navigating the XML document by specifying a path.
  • Paths begin by specifying the dataset (followed by a :).
  • You navigate from the top node by giving tag types.
  • Numbers in square brackets let you choose the second (or third, and so on) of a particular type of tag.
  • @ stands for attribute.
  • text() means "give me the text associated to a node."

Thus, in the above dataset, we have:

  • people:person/loginid/text() returns dsteinberg.
  • people:person[1]/loginid/text() returns dsteinberg.
  • people:person[2]/loginid/text() returns chromatic.

Given a dataset, there are two basic ways to display it using LZX. The first way is to use implicit binding. The idea here is that you attach part of a path to a view (or other user interface component) as an datapath. LZX is smart enough to iterate over all of the nodes matching the datapath, and repeatedly render the component, binding the contents of the component to a different node each time. Thus, for example, the following Flash movie:

Was generated by the following LZX.

	<view name="table">
<simplelayout axis="y" spacing="10"/>
<view datapath="people:/people/person">
<simplelayout axis="x" spacing ="10"/>
<text datapath="loginid/text()" />
<text datapath="firstname/text()" />
<text datapath="lastname/text()" />
<text datapath="numberoforanges/text()" />
</view>
</view>

The way to read this is that LZX iterates over the view once for each top-level node matching the partial path people:/people/person. During each iteration, Laszlo inserts a number at the end of the partial datapath, and then the text nodes inside of the view complete the path. For example, on the first iteration, the view has the path people:/people/person, the LZX runtime inserts a [1], and then the first text node appends loginid/text(). The net result? On the first iteration, the first text node displays the value of people:/people/person[1]/loginid, which is dsteinberg.

The above code is therefore, visually, the same as the following code.

	<view name="table">
<simplelayout axis="y" spacing="10"/>
<view>
<simplelayout axis="x" spacing ="10"/>
<text>dsteinberg</text>
<text>Daniel</text>
<text>Steinberg</text>
<text>124</text>
</view>
<view>
<simplelayout axis="x" spacing ="10"/>
<text>chromatic</text>
<text>chromatic</text>
<text>NA</text>
<text>10089</text>
</view>
</view>

The fun part about this, however, is that you can change the dataset (and you can tell the view to automatically update itself).

The second way to manipulate datasets is via datapointers. A datapointer is, more or less, an object corresponding to a partial XPath expression (in much the same way that a view has a partial path). You define them using the datapointer tag, as in the following code snippet:

	<datapointer xpath="people:/">
</datapointer>

In order to use datapointers, you usually define methods on them (since datapointers are instances of a class, you can add instance-specific methods, just like every other Laszlo object). Here, for example, is a very inefficient way to query the dataset defined above.

	<datapointer name="database" xpath="people:/people" rerunxpath="true">
<method name="getNodeNumber" args="loginid">
<![CDATA[
for (i=0; i < this.getNodeCount(); i++) {
var path= "people:/people/person[" + (i+1) + "]";
setXPath(path);
if (this.xpathQuery("loginid/text()") == loginid) {
return i;
}
}
return -1;
]]>
</method>
<method name="isValidLoginID" args="loginid">
var nodeNumber = getNodeNumber(loginid);
return (-1 != nodeNumber );
</method>
<method name="getFirstName" args="loginid">
getNodeNumber(loginid);
return this.xpathQuery("firstname/text()");
</method>
<method name="getLastName" args="loginid">
getNodeNumber(loginid);
return this.xpathQuery("lastname/text()");
</method>
<method name="getNumberOfOranges" args="loginid">
getNodeNumber(loginid);
return this.xpathQuery("numberoforanges/text()");
</method>
<method name="getPassword" args="loginid">
getNodeNumber(loginid);
return this.xpathQuery("password/text()");
</method>
</datapointer>

This defines a datapointer and adds a few methods to it that are specific to the dataset it references. It's very inefficient, because it constantly resets the path of the data pointer in order to perform queries. (If we were worried about performance, or if the dataset were very large, we might wind up building secondary data structures and caching the results of commonly used XPath queries.)

Given our XML data set and our datapointer, we can now define our second screen and proceed to populate it. As usual, we start with the completed Flash. Here's the final version of the Oranges application.

With this version, if we enter "dsteinberg" with the password "secure," the screen changes entirely, to show us the number of oranges this particular user has eaten (and similarly for "chromatic" with password "reallysecure").

The code for this involves:

  • The dataset and datapointer logic defined above.
  • A new class named personalinformationwindow that displays information about a person.
  • New JavaScript code that handles successful logins.

None of this is particularly hard at this point; the most complex thing involved is probably the JavaScript for handling logins. Here's that code:

	<script>
<![CDATA[

function startApp() {
login_dialog.open();
}
function login(name, password) {
if (invalidLogin(name, password)) {
login_dialog.setMessage("Dude, That Was Both Lame <b> and </b> Bogus")
}
else {
successfulLogin(name);
}
}
function invalidLogin(loginid, password) {
if (database.isValidLoginId(loginid)) {
return password != database.getPassword(loginid);
}
return true;
}
function successfulLogin(loginid) {
login_dialog.close();
personal_information_window.display("ed", "zshau", "50");
var firstname = database.getFirstName(loginid);
var lastname = database.getLastName(loginid);
var numberoforanges = database.getNumberOfOranges(loginid);
personal_information_window.display(firstname, lastname, numberoforanges);
}
]]>
</script>

All this does is tie our original onclick, which calls login to our new datapointer and XML dataset.

Turning the Crank with Live Data

At this point, I've shown you an application that validates a login and then displays a second page. While it is, admittedly, a very simple application, it does illustrate many of the basic principles of LZX programming. The glaring exception is communicating with the server. No matter how rich and interactive our Flash movie is, it needs to occasionally fetch data from the server, and occasionally store data to the server.

In Laszlo, this is also done via XML datasets. Instead of actually inserting the data into the dataset directly, you can specify a URL and have Laszlo fetch the data while the application is running. Similarly, you can alter a dataset, and then send the altered data to the server (getting back a dataset as a return value).

In both cases, communication with the server is done by sending XML payloads over HTTP. In essence, Laszlo replaces the standard web application model, fetch the entire page in HTML, submit forms, and then get the entire page back, with get and put XML datasets that just contain the information that we need.. When you add in the fact that the server compresses the XML, this results in a remarkable savings in bandwidth.

The Laszlo manual contains three entire chapters on how to do this, and effectively writing a data-driven application is far too large a topic to include in this article. So I'll just close with a quick warning: done naively, using XML datasets instead of HTTP might not improve the user's perceived performance very much. The problem is: the application is still communicating with the server. Suppose, for example, that the login panel above was implemented as follows:

  1. The login panel gets the login ID and password.
  2. A dataset is populated with the ID and password and sent to the server.
  3. The server returns an XML dataset to the client.
  4. The resulting dataset is examined to see if the login was successful.

This sends less data over the wire (especially after compression), but it still makes as many server calls as a standard web application. Which means that, while it reduces screen flicker (no ugly "white screens" while the page is refreshing), and reduces the total amount of data transmitted, it doesn't significantly reduce application latency very much, unless the time it takes for the web browser to render the screen is significant.

Evaluating Laszlo

At this point, you've seen enough of Laszlo, and learned enough about both Laszlo and rich internet application frameworks in general, to start wondering whether it's an appropriate technology for you to use. There are really two questions involved, though, and it's best to separate them:

  • Should you use a rich internet application framework?
  • Should you use Laszlo?
Should You Use a Rich Internet Application Framework?

If you've read this far, and you're reading this section, then there are pretty good odds that you're intrigued by rich internet applications. But you're probably also a little bit skeptical. After all, these days, most new applications are built as web applications. For the most part, that means applications are built on the HTTP model: a stateless client that gets its entire user interface sent (as an HTML document) from the server each time the user does anything. And there have been numerous unsuccessful attempts to replace the HTML/HTTP-based Web over the years. (Speaking as someone who once owned a copy of Late Night VRML with Java, I can personally attest to this.)

To date, all of them have failed to gain significant traction because the HTML/HTTP-based Web has some very real advantages. Among them are:

  • The zero-deployment argument. Briefly put: everyone has a web browser, and things mostly work. This is one heck of a strong argument.
  • The flexibility and ease of programming. One of the best expressions of this is Adam Bosworth's amazingly coherent rant about sloppiness and flexibility.
  • We actually know how to build HTML applications that people can use without needing training or assistance. (If you don't know how, and you design web applications, you've got some reading to catch up on.)
  • Search engines have become extraordinarily adept at pulling semantics out of HTML; this is a relatively recent phenomenon, but it's important. Whether you're worried about whether Yahoo Search can understand your site, or whether you simply want to take advantage of Nutch for your internal search functionality, search engines work well on HTML these days.
  • More generally, the vast number of libraries and tools we have for building web applications these days all leverage HTML to some extent.

In short, HTML and HTTP are commonly used because they're amazingly useful. In order to find a better application development model, you need to have an application where the Web doesn't work so well. Typically, this sort of application will have the following positive characteristics:

  • Advanced manipulation techniques like keyboard shortcuts or drag-and-drop are useful.
  • Modern user interface controls and methods, such as tree controls or wizards, are useful.
  • The application has a large number of users to whom the application is important. Rich internet applications are different from standard web applications and the user is going to have to be willing to use something different (and put up with an initial learning curve).
  • The application has a large number of occasional users. Occasional users use the application often, but infrequently enough that they don't turn into power users. Occasional users are the sweet spot: they've learned a little bit, they know some of the keyboard shortcuts, but they're still helped out significantly by the visual prompting possible in a rich internet application.

and the following negative ones:

  • The application wouldn't benefit from being indexed, or having some of its pages indexed, in search engines.
  • The application doesn't need to scale to massive levels.
  • The application doesn't need to meet accessibility criteria. Most rich internet application frameworks offer a richer visual experience at the expense of accessibility.

Does your application meet these criteria? It's hard for me to say. I will say that web-based email and calendaring are pretty clearly in the sweet spot for rich internet applications, and that weblogs probably aren't.

Should You Use Laszlo?

Once you decide that a rich internet application framework is appropriate for your project, the question then becomes, "Should you use Laszlo?" I'm very fond of Laszlo. It has some impressive features in the current product (the 2.2 version) and some of the features coming in the 3.0 version are very nice (chief among them will be the ability to simply deploy the Flash, without needing a presentation server).

On the other hand, Laszlo also has some significant limitations. Many of them come from the fact that Laszlo currently only deploys via Flash. Flash is a nice platform, and using Flash makes Laszlo very easy to deploy, but it also means that the client side has some performance limitations. At the end of the day, the Flash virtual machine was designed for displaying movies. It's not about numerical calculations or large-scale data manipulations and I'm pretty sure Laszlo clients won't handle a XML dataset with 20,000 rows very well.

For similar reasons, Laszlo applications are single-threaded and tend to be event-driven. If your client application needs the ability to perform background computations, it's just not going to fit comfortably into the LZX application unless you can offload the computations to a server process.

The other major caution I'd give you is that LZX involves a new style of programming, and a fairly new programming language. The decision to use Laszlo is inherently a decision to be on the edge. There are very few libraries or frameworks for Laszlo at this point in time, not many people know how to use it, and the bookshelves are bare. If you're not an early adopter, this is not the time to adopt Laszlo.

All in all: should you adopt Laszlo? Maybe. What's very clear is that you should definitely download it and think hard about how rich internet applications will change the Web.

width="1" height="1" border="0" alt=" " />
William Grosso is the vice president of engineering for Echopass.
Related Topics >> Databases   |