## Laszlo - So good, I had to change my underwear

Lazlo does was Java was supposed to do -- let you run desktop-app-like applications within a browser window. But Lazlo doesn't require any plugin on its own, or flaky, slow Java. Instead, the Lazlo compiler turns Lazlo code (which is written in very fast, flexible, human-readable XML) into Flash apps. - BoingBoing

Develop applications via a highly productive declarative programming approach [...] Laszlo applications are developed via a familiar object-oriented XML markup approach that reinforces todays development best practices - Laszlo Systems

LZX is an event-driven, object-oriented language for building dynamic, data-driven applications. Because it's an XML language, LZX integrates seamlessly with your existing IDE, source control, and team development systems. - Laszlo in 10 minutes

A reliable, free, Flash development tool is really good news for amateur web designers. This will probably be a huge success.

## Comment viewing options

### BoingBoing

is a non-technical site, so don't be too harsh.

### Eh?

Thought this was going to the front page. Sorry. But maybe it's better hidden away...

### Laszlo was at LL2

I think you can look at a presentation about LZX from a Real media video stream there.

### Ha!

Thought you meant LÃ¡szlÃ³ LovÃ¡sz for a moment. I mean he's good, but shit your pants? ;-)

### Today's development best practices

For better or worse, I'm going to be seeing quite a lot of Laszlo over the next few months. In a spirit of damage limitation, I'd like to construct an alternative syntax for its UI description language that can be munged into XML at the last minute. (I have no more considered rationale for wanting to do this than a general conviction that XML Languages are teh suck. But I'm encouraged by the rumour that some MS people write their schemas in Relax NG's compact syntax, and then have them automatically converted into XSD).

It should be possible to describe a tree of nested visual elements succinctly without having to represent that tree with a set of nested tags (or S-expressions, or what have you). I really want to get away from the idea that the language's concrete syntax should directly mirror the structure of the "object model"; particularly because in any reasonably complex UI there are relationships between visual elements that are not parent-child relationships, and the more such relationships there are the more of a pain it is to have to go on pretending that everything's a tree. So my first requirement is that it should be possible to describe nested structures succinctly, but not mandatory to use a nested syntax to do so.

My second requirement is that the scripting for behaviours and animations should be extradited from the structural markup - in the XML language, you have embedded javascript all over the place, and I can see that becoming a serious headache to maintain. Some more systematic and sensible way of connecting the declarative and imperative parts of the language would be helpful - ASP.Net's "code-behind" comes to mind.

Does anyone have any pointers to examples of other attempts to do similar things?

### Excellent point, Dominic

Hi, I work for Laszlo, on some compiler and runtime support. I had a company in the 1990's called Universal Access, with Brian Fox, and we made a server-side scripting language called Meta-HTML, which had a sort of hybrid lisp/HTML syntax, but was not object oriented.

But we had the same sort of issues as you point out in Laszlo, where the structure of the source code shadows the structure of the output (HTML in that case) and thus the programmer finds himself at odds between maintaining the structure of the output presentation and internal communication and procedural function of their program.

I agree with you that as an application gets to 'real-world' complexity, the original parent-child structure that may have seemed simple to begin with often becomes dwarfed by complex procedural interrelationships which are difficult to express in tree form. I have seen this happen before, and I have also wondered if there is a clean way to deal with it.

It's my impression that building the initial visual hierarchy of an application is only a small part of the life cycle of a program, and most of the work goes into maintenance and procedural coding to get the behaviors correct. So therefore I was actually not unhappy with the conventional procedural style like Java Swing where you declare your windows and other visual objects just like any other object, and add behaviors to them procedurally. It is verbose, yes, but you are not enslaved to the parent-child hierarchy, you can put your code whereever you want in your source files.

We have a couple of language artifacts and features that make things a little easier in terms of allowing different parts of the view hierarchy to reference each other: + You can name child views relative to their parents, and you can reference them with paths that are relative to the "classroot" of the class you are defining. So if you have a hierarchy like this, and one view wants to refer to a sibling, you can do it in a clean way:

<class name="myclass">
<somewidget>
<somechildwidget>
<method name="blah">


Another feature is that many widgets communicate via events and constraints, so you can easily make non-local connections that way

I'll post more about that in another comment when I have time...

So you can reference sibling elements using a relative path. It helps clean things up a little..

### Implementation language?

Anybody knows the implementation language of Laszlo? I tried openlaszlo.org, but it seems to be down...

### Java?

The Laszlo application server runs on Tomcat, I believe.

### Implementation language

On the server: Java, Jython, and XSLT. On the client: Laszlo (XML+JavaScript), JavaScript, and flasm (Flash bytecode assembly).

Laszlo consists of a server, a core runtime library which is linked into every Laszlo application, and a set of UI components which are linked into those applications that use them.

The server hosts a compiler, and servlet request responders that provide back-end support for running applications. The server is written mostly in Java, but parts of the compiler (in particular the JavaScript compiler) are written in Jython. The web front end to the compiler is written partly in XSLT.

The core runtime library is written in JavaScript, with some hand-coding in flasm. The standard UI components are written in the Laszlo language itself, which is an XML tag set with embedded JavaScript.

We chose Java, and J2EE, for ease of deployment of the server. I wrote the script compiler in Jython so that I could write it quickly; we're incrementally moving it to Java so that it will run faster.

The language choice for the runtime library was mandated by our choice of the Flash player as an execution environment. The Flash player contains a bytecode interpreter, and the bytecodes implement JavaScript semantics; another language compiled to Flash bytecode would run too slowly.

### Promoted

It seems people are interested in this thread, so I decided to promote it to the home page.

### WithStyle

WithStyle is also worth a look. It's 100% SmallTalk and doesn't use flash.

I think the abstract here gives a better overview than the official site does.

### uh?

"Laszlo applications are developed via a familiar object-oriented XML markup approach that reinforces todays development best practices"

Hilarious... the sad part is that are plenty of people that are so confused that will actually think that phrase makes sense.

### expand-marketing()

Sorry, that sentence is pretty marketing-heavy. On the other hand, it can be hard to summarize some things in a sentence or two. (You should have heard me try explaining Aardappel to our client runtime architect last year. Or maybe it's just as well you didn't…)

Here's what we meant:
* The syntax is XML with embedded JavaScript — like DHTML.
* There are abstraction mechanisms for extending the set of primitives (user-defined tags and classes), separating data and presentation (data binding), separating relations and control flow (constraints), and declaratively specifying static relations (the XML representation of the visual hierarchy, and the State mechanism).

We thought some of these features were novel, at least in a full-featured system. (I'm sure we'll find out whether they really were novel here. :-) Others features — such as defining your own tags and classes — may look like lowest-common-denominator features to this audience. We thought they were worth calling out anyway because many other tools for building client-side web interfaces are lacking them, believe it or not.

By the way, I recommend running the Laszlo Explorer for those of you who like to look at code. This is an expanded version of the set of examples I showed at LL2, with the further advantage that you can try out changes. (We recompile the changed code on our server, and push it back down to another browser frame so you can how the modified application runs.)

### Mixing...

Sure mixing code and ui design is definitly a wrong practice. Macromedia was doing that with ActionScript1, which you could be embedded into any entity (movieclip). Just trying to figure out the evaluation order was causing headaches... They're now moving away from it with ActionScript2 (Ã  la Java : one file one class), but their compiler is still very very slow. In my company we're heavily using flash, and I ended up writing my own OO language with type inference and that can directly target SWF bytecode.

### DSLs for Flash

I ended up writing my own OO language with type inference and that can directly target SWF bytecode

That's the kind of thing I'm thinking about (only targeting Laszlo's XML language, and letting it take care of the SWF/Xaml/whatever generation. It will be interesting to see how well the idea of a retargetable compiler for different presentation platforms works out in practice - I don't know how far along they are with other platforms yet). Is there anything publicly available I might have a look at?

### Retargetable compiler

Basicly we have a high level OO language which does not rely on a specific subsystem. It can be used for Flash - adding specific "native classes" headers - , and recently I've ported it to another lightweight VM so it can run standalone and inside a mod_* for Apache. Almost nothing public right now, although I'm thinking making a proper release later this year - the compiler is entirely written in OCaml. (You can contact me at ncannasse@motion-twin.com to get more informations).

### C# to Flash compiler

There is another Flash compiler that is being developped, that is quite interesting. It uses C# as the input syntax/language (you can use VS and intellisense for the coding).

http://blog.debreuil.com/archive/2004/08/18/376.aspx

### key features

I would expect language mavens to be most interested in the Laszlo's data binding, in the declarative syntax for specifying user interface states, and in the constraint mechanism.

Data binding is similar to (and inspired by) XSLT, except that it's a two-way binding and dynamically updates the UI when the data changes. You can click through the examples in the Data section of the explorer to see how it works.

The state tag allows you to specify mulitstate components, such as a window that sometimes contains a button and sometimes (perhaps orthogonally to this) contains some notification text. It moves a subset of UI programming that would otherwise be procedural into a declarative domain where it's easier to specify and to tool.

Constraints generalize the HTML syntax of <table width="50%">, so that you can embed an arbitrary JavaScript expression as the value of an attribute. The compiler generates code that registers the expression as an observer of its terms, in order to update the attribute value when the value of the expression changes. Beyond the obvious applications (in layout, and routing domain object values to the user interface), there's some surprising synergy between constraints and states. For example, the second-to-last example in the explorer contains a divider bar that drags horizontally when you click on it. This is implemented as a constraint within a state:
<state name="dragging">
<attribute name="x" value="\${parent.getMouse('x')}"/>
</state>

This constrains the x value of the enclosing element (the divider bar) to the x value of the mouse position when the state is applied. The divider contains event handlers that apply the constraint when the mouse button is pressed and remove it when the mouse is released.

A real-world example would pin the values, and might have other features too. (In fact there is a more feature-rich dragging library in the framework, so you don't have to figure out to write this kind of thing just to write an app that implements dragging.) The point is that a simple user interface action such as this is simple to express, so you can experiment with UI behaviors without as much plumbing as some other languages require.

There are a lot of other features, such as the user interface component set, and the client and server integration, that the platform documentation covers because they're necessary for writing real-world applications, but I think that the features above, along with user-defined tags, are the main abstraction tools in the platform.