A lot of people have been asking me lately how Laszlo compares to Ruby on Rails. RoR has done an excellent job of catching the Ajax wave, even though most of the renowned Ajax examples are written in Java and C. In spirit, Rails and Laszlo are kin: both fashion themselves as lightweight, novel ways to quickly create web-based applications. Both are kinds of responses to the options of heavier-weight Java on the one side, and the wild-west of PHP and Perl on the other.

Of course, there are some huge differences too. Rails focuses heavily on the server side of application building. It can generate a complete and functioning web app from a database schema. That probably won't be anything you'll want to ship, but it sure is an interesting way to get developers started. RoR addresses the client mostly as a renderer, much the way non-Ajax apps do. Of course, RoR does include some ballyhooed features that make it easier to deliver HTML snippets without reloading the page, but this is Ajax-defined-as a dash of MSG to liven up an old-school web app stew.

Now for whatever weaknesses RoR may have addressing the client, Laszlo has similar holes on the server side. But that's changing. Laszlo Mail of course has a substantial server component, and increasingly, our Studios customers are asking us to build middleware and do back-end integrations as parts of our projects for them.

Moreover, we've come to realize that the middleware for our apps, while often simple, is nearly always a custom bit of work that has its own idiosyncrasies. As an example of this, we've tended to shy away from implementations which rely on SOAP. This is only partly because SOAP is a bloated ugly mess; it's also because the thinking behind SOAP interfaces tends to come from the perspective of a class designer. The fact is that in most cases, networks still have observable latencies, and it's important to think about the server API in terms of the client's need for it, rather than in abstract domain terms. Some work has to go into crafting a fairly coarse interface that supports the client directly.

Now this is rarely rocket science, but there are a few gotchas. What if your dataset is too big to be efficiently transmitted to the client in one go? Well then the server can send it in pages, and the client can represent the dataset as a sparse array. Ok no problem, but then what happens when the user changes the sort order? Back to the server and the APIs to allow the client to pass in a sort order when it requests a data page. Sounds good, but now what happens when the user makes a selection and then changes the sort order? The user-friendly thing to do would be keep the selected record in view, even though it's at an unknowable point in the newly sorted result set. But that requires a different server API and some fairly substantial database trickery. We're all about user friendly here at Laszlo, but you can bet that we didn't get this one right in our 1.0 of Laszlo Mail. (It's fixed now.)

There's something worse, though, about having to develop the middleware for an active-client app (and here I'm drawing a distinction with server-side apps that just do tricks like loading a new div into an existing page.) When I've had to do this, the thing that has bothered me most is the replicated code that I've had to write for both the client and the server. The crux of this is validation. If I have a simple domain element like an address, I end up wanting to encode a bunch of information about what's in an address on the client. By this I mean complex information beyond the simple data type stuff that Rails will do. Given a country code, do I have a valid postal code, if one is even needed? Given a partial phone number associated with this address, how should this number be dialed depending on my location?

I may also want higher-level domain operations. I may want to tie a contact in my personal address book to a user in the system in a complex and active way, so that I can seamlessly integrate my data about a contact with the data that she publishes about herself.

If you've read any of my previous articles, you can probably guess where I'm going with this. The solution, to my mind, is to allow developers to express a single domain concept in a single, portable language that can run on both the client and the server: JavaScript. Now Ruby has that ruby-to-JavaScript thing, and Google released that bizarre bit of I-like-to-type webtoolkit but these are both cases where the client is still addressed a renderer -- a renderer of very simple domain logic, but not an active entity with its own notion of application state.

We've become so used to centering our applications around the server that David Temkin asserts that it's nothing short of a Copernican revolution to consider the client as the core of a given application. To me, it's funny to think of this as revolutionary. Having built a bunch of these apps, it's clear that the server-side is just a part of the app development equation. It's also clear to me that the Web 2.0 fad is all about user interface, and that the extent to which the client app, the part closest to the user, is in control of the experience is the extent to which it will succeed as a user experience.

The standard story around this kind of integration is that you use a popular MVC framework like JSF or struts to present your XML API, and that you write your Laszlo client to consume the XML data that results from your requests. I'm guilty of touting this myself. But without exception, the server-side frameworks are all much too heavy to justify the cost of integrating them. There's no need for complex rendering paths in XML APIs. No the truth is that the best way to implement a Laszlo middle-tier is to make it as abstract as possible. You don't want to be tied to a particular framework, or even a particular transport. The strategy is to build a network of simple objects, related in simple ways, that can be run in a single thread to provide stateless responses to an incoming request.

Truth is, most of the server-side frameworks are really about supporting the increasingly elaborate and idiosyncratic needs of the browsers. When the client is doing more of the heavy lifting, the server part becomes an exercise in almost pure class-design. (Of course, such exercises are exactly how you end up making absolutely everything an object (beware transactionEnvironmentHandoffMediator.)) The rendering of an object as XML is trivial, and it certainly doesn't require any elaborate view-templating system.

So you can imagine that we're working on extending Laszlo to the server. Thanks to our partnership with Dojo, we already have the makings of a Rhino runtime. Rhino is powerful stuff. It allows full reflection over regular Java objects and compiles into fairly efficient Java byte code. As a language, JavaScript isn't nearly as obtuse as Ruby, but its flexibility makes it easy to configure classes at runtime, which is exactly what you need when you're auto-generating models from database schemas, but you want to avoid icky code generation.

To draw another distinction with Flex, the folks at Macrobe seem to be working hard at at perfecting the Ptolemaic System: ever more numerous data integration points, with ever more complicated and enterprise-y plumbing. They're tuning their equants and epicycles, all to better wedge their apps into Web 1.0 architecture, while here at Laszlo we're eccentric like my man Jo Kepler.