Sidebar: The Client Side Container Environment

Even though it seems fairly innocuous at first glance ("All I'm doing is replacing HTML with Flash and making things a little more responsive") Laszlo presents some very interesting design challenges, and requires a substantial change in the way we think about web applications.

Consider how a typical Java-based web application is built these days. In layers, we have:

  1. At the very bottom, there's a relational database. It's not particularly well-suited for what we do these days, but it's a darn fine place to store rows of data.
  2. Then there's some sort of object-relational mapping layer.
  3. Then there's some sort of container that holds the business logic.
  4. Then there's some sort of presentation layer that knows how to ask the business logic layer the right questions, and how to render the answers it gets in the chosen display format.
  5. The presentation layer is supported by a servlet container and a presentation layer like struts.
  6. And, of course, there are servlet filters to handle things like security and logging.

When you think about Laszlo, and rich internet applications in general, you end up wanting to move the entire presentation layer, and a good part of both the database layer and business logic, to the client. Put simply: the only way to get highly responsive applications is to eliminate "every user action requires a query to the server." Server interactions have to either be asynchronous (and done in the background), or relatively infrequent.

This becomes even more true once the Laszlo Presentation server is removed from the deployment picture (see David Temkin's October 8 post for more details).

All the java frameworks that support web application development, for accomplishing everything Java programmers do, are server-oriented. They don't really help all that much in Laszlo. You can use Spring and Tapestry to generate your XML datasets, and to manage some of your session and persistence logic, but there's a lot of client side support that's just missing right now. There's no XML-LZX mapping layer to handle your datasets, and there's no equivalent of Tapestry (or Struts or JSF) on the client side to simplify user interface transitions.

Personally, I find this tremendously exciting. We've learned an awful lot about frameworks in the past 10 years, and this is an opportunity to take everything we've learned and apply it in a slightly different context, with very different constraints-- even with broadband, we're probably not going to be allowed to generate huge flash movies that contain all the supporting libraries for an entire application framework. Which means we're either going to need to slim things down, or the LZX compiler is going to have to learn how to optimize for size.

Oliver Steele's weblog contains an detailed discussion of the architectural implications of Laszlo.