Slashdot Mirror

Relax NG has a compact non-XML syntax. But C++/Java is a horrible syntax to use if you want a language to be readable and easy to understand. Since when was 17 levels of operator precedence easy to understand? Of course any good programmer always uses parenthesis to avoid ambiguity, so why should a language have 17 levels of built-in ambiguity just to make it that much easier to make hard to find mistakes?

-Don

From my blog: Relax NG Compact Syntax: no to operator precedence, yes to annotations!

James Clark is a fucking genius! Hes the guy who wrote the Expat XML parser, works on Relax NG, and does tons of other important stuff. Relax NG is an ingeniously designed, elegant XML schema language based on regular expressions, which also has a compact, convenient non-xml syntax.

I totally respect the way he throws down the gauntlet on operator precedence (take that you Perl and C++ weenies!):

There is no notion of operator precedence. It is an error for patterns to combine the |, &, , and - operators without using parentheses to make the grouping explicit. For example, foo | bar, baz is not allowed; instead, either (foo | bar), baz or foo | (bar, baz) must be used. A similar restriction applies to name classes and the use of the | and - operators. These restrictions are not expressed in the above EBNF but they are made explicit in the BNF in Section 1.

You can translate back and forth between Relax NG's XML and compact syntaxes with full fidelity, without losing any important information. Relax NG supports annotating the grammar with standard and custom namespaces, so you can add standard extensions and extra user defined meta-data to the grammar. That's useful for many applications like user interface generators, programming tools, editors, compilers, data binding, serialization, documentation, etc.

Here's an interesting example of a complex Relax NG application: OpenLaszlo is an XML/JavaScript based programming language, which the Laszlo compiler translates into SWF files for the Flash player. The Laszlo compiler and programming tools use this lzx.rnc Relax NG schema for the OpenLaszlo XML language. This schema contains annotations used by the Laslzo compiler to define the syntax and semantics of the XML based programming language.

The schema starts out by defining a few namespaces:

default namespace = "http://www.laszlosystems.com/2003/05/lzx"
namespace rng = "http://relaxng.org/ns/structure/1.0"
namespace a = "http://relaxng.org/ns/compatibility/annotations/1 .0"
datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes"
namespace lza = "http://www.laszlosystems.com/annotations/1.0"

The a: namespace defines some standard annotations like a:defaultValue, and the lza: namespace defines some custom annotations private to the Laszlo compiler like lza:visibility and lza:modifiers. Thanks to the ability to annotate the grammar, much of the syntax and semantics of the Laszlo programming language are defined directly in the Relax NG schema in the compact syntax, so any other tool can read the exact same definition the compiler is using!

To show how truly simple and elegant it is, here is the snake eating its tail: The Relax NG XML syntax, written in the Relax NG compact syntax:

# RELAX NG XML syntax specified in compact syntax.

default namespace rng = "http://relaxng.org/ns/structure/1.0"
namespace loc

That's not misleading at all -- you're just misunderstanding. OpenLaszlo applications certainly are "AJAX". AJAX stands for: "Asynchronous JavaScript and XML". That's exactly what OpenLaszlo is, whether it's running on Flash or the web browser. OpenLaszlo was "AJAX" long before the term was coined.

Before AJAX (Asynchronous JavaScript and XML) had a name, there was Laszlo Systems, a software tools developer using AJAX-like methods along with with Macromedia's Flash player to deliver richer Web experiences. David Temkin tells us why he chose the Flash player as a platform. Laszlo went open source and chose IBM's Common Public License as it was flexible enough to fit their needs without curbing commercial use.

Now can you find anything at all misleading about the announcement, once you understand the standard definition of the terms? You told me privately that you were misled into believing that 1) there was a new production ready product available and 2) there were new demos ready now. I can find nothing in the announcement or web pages that states or implies any of that, so you're just making it up, and reacting to your own straw man misunderstandings. Don't blame other people for your own poor reading comprehension.

Who are you to say that I am not entitled to post an announcement about an open source project on Slashdot? Who else shares your unique "school of thought" that nobody should announce anything until beta?

Let's get back to your original argument that open source projects should not post announcements before they're in beta. Why not? Says who? What are the positive advantages of that? How do they outweight the horrible negative consequences of stifling development and supressing community participation?

What do you have against Linux and every other open source project? You don't seem to understand the first and most important thing about open source software development, and that's colaboration and communication. Operating in secret until beta, as you suggest, is totally against those principles.

-Don

To address the question "Is OpenLaszlo AJAX?", here's something I wrote a while ago (before OpenLaszlo's DHTML support was announced): OpenLaszlo Makes Full Blown AJAX Apps on Flash :

The fact that Flash is commonly used for ads, and that those ads annoy everyone and cause many people to hate Flash, doesn't detract from the high quality user interfaces that you can build with it, if you use it for good instead of evil.

Since usability guru Jakob Nielson wrote Flash: 99% Bad in 2000, a lot has changed about Flash. He worked with Macromedia to improve Flash's usability, and he sells a report with 117 design guidelines for Flash usability. So yes, it is possible to develop usable applications in Flash.

OpenLaszlo is an open source language and set of tools for developing full fledged rich web applications, which are compiled into SWF files that run on the Flash player. Laszlo/Flash is presently much more capable of implementing high quality cross platform user interfaces than dynamic AJAX/HTML/SVG currently is.

Laszlo is a high level XML and JavaScript based programming language. It's independent of Flash in the same way that GCC is independent of the Intel instruction set and Windows runtime, because they both compile a higher level language, and can target other runtimes and instruction sets.

Currently Flash is the most practical, so that's what Laszlo supports initially, but it can be retargeted to other runtimes like SVG, XUL, Java or Avalon, once they grow up and mature. But right now Flash is the best way to go, because of i

"SimFaux is an interactive Faux News TV simulation, which I just published on the Huffingtonpost Contagious Festival. It's written entirely in OpenLaszlo, and features simulated characters (Dick Cheney, George W Bush, Arianna Huffington, Bill O'Reilly, and more to come), streaming video, sound bites, talking points, slanted surveys, meaningless graphs, dynamic keywords, pie menus, and several channels with different split screen layouts. All the content is tagged with keywords, which it uses to decide what to play next. There's an "About" channel that explains more.

Technically, it's an open-ended data-driven AJAXian web application written in OpenLaszlo (JavaScript + XML that runs in Flash), so it's easy to add more content and plug in new behaviors. (I plan to add some mini-games like Tick-Tack-Faux and Hangman!) I'm regularly adding more characters, video, talking points, sound bites, surveys, etc. So please check back again later for the latest breaking news and propoganda!

-Don

NeWS used PostScript throughout, as the imaging model (like DHTML), the scripting language (like JavaScript) and the data model (like XML). It was like AJAX in that it sent asynchronous messages over the network and used a dynamic scripting language on the client side (called the NeWS server), so it could implement local graphical user input feedback, and efficient application specific network protocols (using a binary encoding for PS data).

NeWS was much more consistent and better designed than AJAX's amalgamation of accidental technologies (DHTML, JavaScript, XML). NeWS also has many other advantages over AJAX, such an excellent imaging model, wysiwyg printer compatibility, shared modules, multithreading, synchronization, a programmable event distribution system, a fully developed Open Look gui toolkit, and graphical interface builder (HyperLook).

Writing NeWS PostScript is a lot like directly programming byte code for the Java or Flash virtual machines, which are both object oriented stack machines a lot like PostScript and Forth. At the time, we were well aware that many people had a hard time programming in PostScript directly (although I love it), so several interesting compilers were developed. Rehmi Post wrote a back-end to the Amsterdam Compiler Kit (CScript: C for yourself, PostScript for NeWS), Arthur van Hoff (who later wrote the Java compiler in Java) wrote PdB (Pretty darn Brilliant), a compiler that translated object oriented C into PostScript , which supported subclassing PostScript NeWS toolkit classes. Dave Singer at Schlumberger wrote LispScript, a Lisp to PostScript compiler, which allowed you to take full advantage of Common Lisp macros to develop PostScript programs!

OpenLaszlo is a high level XML/JavaScript based programming language, which compiles into Flash byte code that runs in the Flash player, and works exactly the same across all platform. The inner loops and hot-spots of Laszlo are hand written in "flasm" (Flash Assembler), as hand optimized alternatives to the compiled JavaScript code. (Laszlo is a JavaScript compiler that currently outputs SWF code, but will support other virtual machines in the future.) Flasm looks a lot like NeWS PostScript code, with all the stack comments. Laszlo is open source, so you can grab a copy of the LPS sources and look at "LaszloView.as" to see what I mean.

-Don

The harsh reality of AJAX (besides the obvious fact that it has sucky graphics) is that it's extremely difficult to write code that runs the same in all browsers, and you have to relentlessly test against each different browser on every different platform that you plan to support. Flash has no such problem, because it's identical across all platforms.

The lowest-common-denominator graphics AJAX can support across all browsers are crude and clumsy. Google maps has to bend over backwards and depend on the server to draw a diagonal line with transparent PNGs on Firefox, but it can't use transparent PNGs on Internet Explorer, so it has to use non-standard VML instead. It can't simply do everything in terms of SVG or PNG or VML: it actually has to support BOTH PNG and VML, but can't take advantage of vastly superior SVG since it's not commonly deployed nor well supported! All that rube-goldberg technology, just to draw a stupid line.

AJAX applications require a huge amount of extra work to develop, and even more to maintain, because of the necessity of dealing with evolving browser incompatibilities. And the end result simply isn't worth all the effort, since the lowest-common-denominator graphics and the resulting user interfaces are so crude and limited.

For example, Pie menus should pop up in round and arbitrarily shaped windows, but it's impossible to even draw a circle with DHTML, let alone a spokes and speech bubbles!

AJAX practices must balance on a randomly swerving rasor's edge: the intersection of what works on all browsers at the time of implementation. But all the browsers are constantly evolving in different directions, so today's hacks and kludges you're forced to use to work around bugs in today's various browsers will make your application fragile, complex and hard to maintain, and it will probably break in future browsers. AJAX forces you to artificially limit yourself and refrain from using technologies like SVG, VML and PNG, or else you have to actually implement simple things like diagonal lines with several different technologies at once, sniff the browser, adapt at run-time, and fall back to server side rendering!

Maybe Google has the resources to develop and matintain several different ways of drawing a diagonal line over a map, but most companies and independent developers don't have as much human and computer resources to flush down the toilet on such a simple problem of drawing lines. Flash already solves that problem quite nicely thank you, and it's the most ubiquitous RIA platform that exists today, with open source development tools like OpenLaszlo.

-Don

Don't take this as anti-AJAX. That kind of architecture is great, but it's the notion that the new AJAX buzzword describes new ideas that annoys me.

Of course Microsoft has been supporting it since the 90's, but it goes back a lot further than that.

For a long time, I've been evangelizing and more importantly implementing interactive applications that run efficiently over thin wire (dial-up modems, ISDN, early internet before it was fast, etc), which are locally interactive and efficient because there's a programming language on each side of the connection that implements custom application specific protocols and provides immediate feedback without requiring network round trips.

Before he made Java, James Gosling wrote the NeWS Window System.

I did a lot of work with NeWS, as a user interface researcher, commercial product developer, and a gui toolkit engineer for Sun, implementing distributed applications as well as user interface widgets and gui construction tools.

I've programmed NeWS to implement many user interface widgets (pie menus, tabbed windows, terminal emulators, graphics editors), gui toolkits (Suns TNT Open Look Toolkit, Arthur van Hoff's HyperLook user interface construction tool), and applications (UniPress and Gnu Emacs text editor interfaces, Ben Shneiderman's HyperTIES hypermedia browser, PSIBER visual PostScript programming and debugging environment, PizzaTool for customizing and ordering pizza via FAX, a cellular automata lab, a port of Maxis's SimCity), and lots of other stuff.

Now I develop distributed applications with OpenLaszlo, which embodies all the great qualities of AJAX without the horrible compatibility problems and shitty graphics. Macromedia though OpenLaszlo was such a great idea that they made a proprietary knock-off called Flex, for which they charge $12,000 per CPU. The future of Laszlo is secure since it's free software with an open source license, but Flex is in Flux since Adobe is buying Macromedia.

I'm quite happy to have found OpenLaszlo, since it's got all the advantages of NeWS, it runs beautifully and consistently on all platforms, the people developing it really understand what they're doing, and most importantly it's open source. NeWS was a technological success, but a commercial failure, because Sun refused to release it like X11. But OpenLaszlo applications really do run everywhere consistently, support XML standards and rich dynamic graphics vastly superior to anything you can do in DTHML, and they're great fun to develop.

Here's a message I wrote on the news-makers mailing list (a mailing list about NeWS that I started and maintained during the Window System Wars of the 80's), discussing the difference between Adobe's approach to Display PostScript, X11's inherent deficiencies, and Sun's approach to NeWS.

To avoid confusion:

Flex was inspired by Laszlo (in spite of the fact that Tim O'Reilly is confused and mistakenly thinks it's the other way around).

OpenLaszlo is an excellent open source web programming language based on XML and JavaScript. Your class declarations, object instantiations and configuration constraints are all defined in XML, with JavaScript expressions in attributes and JavaScript methods in text content.

OpenLaszlo strikes an elegant balance between XML and JavaScript, so Laszlo code is quite clean and easy to read and maintain. IBM has developed an Eclipse IDE plug-in for creating Laszlo applications with drag-and-drop and XML outline editors.

You can see for yourself how easy it is to develop interactive graphical web applications in XML+JavaScript with OpenLaszlo: Laszlo in 10 minutes. You can actually see, modify and run Laszlo scripts over the web, to learn how it works.

If you like Laszlo and want to learn more, then you can download the entire Laszlo source code, documentation and examples for free, and start developing your own Laszlo applications, without paying any exhorbinant licensing fees like Flex requires (on the order of $12,000 per server).

-Don

http://www.laszlosystems.com/ http://www.openlaszlo.com/

XSLT is a weak, horrible programming language, which gives other XML based programming langauges a bad name. It's only useful for performing simple XML text transformations, but not for programming interactive networked XML data driven graphical user interfaces, which OpenLaszlo is great at.

OpenLaszlo is an excellent open source web programming language based on XML and JavaScript. Your class declarations, object instantiations and configuration constraints are all defined in XML, with JavaScript expressions in attributes and JavaScript methods in text content.

OpenLaszlo strikes an elegant balance between XML and JavaScript, so Laszlo code is quite clean and easy to read and maintain. IBM has developed an Eclipse IDE plug-in for creating Laszlo applications with drag-and-drop and XML outline editors.

You can see for yourself how easy it is to develop interactive graphical web applications in XML+JavaScript with OpenLaszlo: Laszlo in 10 minutes. You can actually see, modify and run Laszlo scripts over the web, to learn how it works.

-Don

Here's a simple example of a Laszlo gui for browsing and ordering stuff from Amazon via their web services API:

Blueprint Music

Here's the source code.

-Don

Flash is excellent for developing rich web applications, which are entirely different than home page "flash intros" that you want a button to skip, or flying hamburgers that pop up on top of yahoo's home page.

By "rich web application", I mean the entire interactive client side of the application runs in the Flash player. Well written Flash based applications are high quality, responsive, uniform across platforms, and much better than anything that is possible with html/ajax.

There are several different approaches to writing Flash based rich web applications. The worst proprietary way is using Macromedia's Flash tool. The most expensive and legally restricted way is using Macromedia's Flex server. The best and free way is using OpenLaszlo, which is open source, and IBM's Laszlo IDE for Eclipse, which is also open source.

It would be interesting to compare Macromedia/Adobe's Zorn Eclipse plug-in, with IBM's Laszlo Eclipse plug-in. I wonder who better understands how to write plug-in IDE's for Eclipse: IBM or Macromedia/Adobe? And who better understands Open Source software?

-Don

IBM already released an open source Eclipse plugin for developing Laszlo applications, on November 18, 2004. Laszlo is open source, and so is the Eclipse tool for developing Laszlo applications.

Does Macromedia actually think they're going to convince open source developers to use Flex, by throwing out an Eclipse plug-in, while still charging $20,000 per cpu for the Flex server software?

IBM and Laszlo are a lot more serious about Open Source and Eclipse than Macromedia/Adobe.

-Don

Laszlo used to cost about ten thousand dollars per license, but it is now fully open source and free. Flex costs more than ten thousand dollars per server license, and has restrictions on how you can modify and redistribute Flex components.

Macromedia has a spotty track record supporting their server software over the long haul, and now that Adobe's bought them, Flex is in Flux. Laszlo is here to stay because it's available now, free and open source, and you're not restricted in how you can modify and reuse Laszlo and its components.

Flex is a lot like Laszlo, because Flex is Macromedia's imitation of Laszlo, but Flex is intended to lock you into Flash instead of giving you independence from it.

The most important difference between Laszlo and Flex, is that Laszlo is not tied to Flash, it "just happens to" use it right now, because that's the most practical target platform at this point in history. Laszlo is a high level JavaScript/XML based language which currently targets the Flash player as its initial platform, with more to come.

Laszlo abstracts away Flash dependencies, so it will target other runtimes than Flash in the future, as they mature and shake out: Java (Rhino/Java2D), C# (CLR, GDI+, Avalon), C++ (SpiderMonkey, CGI+, Quartz, Cairo, AGL), SVG (Adobe, Batik, Firefox), DHTML (web browsers, JavaScript, AJAX).

But right now Flash rules, and Laszlo is the best way to develop rich web applications that run on Flash.

One really interesting possible target platform for Laslo is an open source Flash player, that can easily be integrated into applications and games, and uses OpenGL with hardware accellerated rendering.

-Don

The problem with "AJAX", compared to NeWS or OpenLaszlo, is that imaging model sucks, because it's limited to the lowest common denominator of HTML across all browsers. NeWS uses the PostScript imaging model to render interactive user interface components (buttons, sliders, pie menus, tabbed window frames, etc). OpenLaszlo uses Flash graphics to render interactive user interface components (all the widgets you expect, including a full widget set skinnable with Frash graphics, supporting animation, transparency, color tinting, etc).

As a imaging model, Flash is nicer than PostScript in some ways, not as nice in other ways, but vastly superior to HTML. It's also interesting to compare Flash with SVG, which is also great for implenting "AJAXian" user interfaces, but doesn't have nearly the installed base. The best thing about Flash is that it's exactly the same across all platforms, and it's got a great installed base.

-Don

Newsgroups: comp.windows.news
From: don@BRILLIG.UMD.EDU (Don Hopkins)
Local: Sat, Feb 6 1988 5:38 am
Subject: Comparing Display PostScript and X11/NeWS

[...]

NeWS has extensions to the PostScript language that allow for programs (light weight processes), running in the display server, to receive input events on behalf of NeWS clients (other programs running on the same computer, or at some remote site). They may process input locally (on the same machine and in the same process where the events are happening), without consuming any communications bandwidth. This is a big advantage, if you want fast, responsive graphical feedback.

NeWS processes can communicate with each other by manipulating shared data structures, and by sending messages through the event queue. They can receive low level input events ("The left mouse button was released at location (X,Y) in window W at time T"), and give graphical feedback ("erase the old slider, redraw it at its new position, and fill the border with bright red"). They can translate input from the user into high level, application specific events, which are sent to the client ("set the volume of the CD player to 100%"). NeWS processes can run autonomously in the server, without a connection to a client, providing "desk accessories" such as a calculator, event journaling, menus, and control panels.

According to the fellow from Adobe who talked at the PostScript BOF at the X conference, Adobe's Display PostScript provides output capabilities, but has no facilities for receiving input directly from of the X event queue. As I understand his explanation, the X server must send X events over the IPC link (network, shared memory, modem, or whatever) to the client, which must then translate the events into PostScript commands, and send them back over the link to be executed by Display PostScript. Because there is no way for PostScript programs to read events off of the X event queue, the client must process input events behalf of the display server. Messages must go on a round trip, from the X server, to the client, and back to the Display PostScript extension in the server, to produce any graphical output on the screen.

[...]

The NeWS "Lite" user interface toolkit is written entirely in PostScript. Menus, buttons, windows, sliders, scroll bars, and even terminal emulators, are implemented as device independent PostScript programs, in NeWS's object oriented PostScript programming environment. Since the toolkit can run in the server, clients can share the same code, and a copy of the toolkit does not have to be linked into each client. It's easy to mod

The problem with "AJAX", compared to NeWS or OpenLaszlo, is that imaging model sucks, because it's limited to the lowest common denominator of HTML across all browsers. NeWS uses the PostScript imaging model to render interactive user interface components (buttons, sliders, pie menus, tabbed window frames, etc). OpenLaszlo uses Flash graphics to render interactive user interface components (all the widgets you expect, including a full widget set skinnable with Frash graphics, supporting animation, transparency, color tinting, etc).

As a imaging model, Flash is nicer than PostScript in some ways, not as nice in other ways, but vastly superior to HTML. It's also interesting to compare Flash with SVG, which is also great for implenting "AJAXian" user interfaces, but doesn't have nearly the installed base. The best thing about Flash is that it's exactly the same across all platforms, and it's got a great installed base.

-Don

Newsgroups: comp.windows.news
From: don@BRILLIG.UMD.EDU (Don Hopkins)
Local: Sat, Feb 6 1988 5:38 am
Subject: Comparing Display PostScript and X11/NeWS

[...]

NeWS has extensions to the PostScript language that allow for programs (light weight processes), running in the display server, to receive input events on behalf of NeWS clients (other programs running on the same computer, or at some remote site). They may process input locally (on the same machine and in the same process where the events are happening), without consuming any communications bandwidth. This is a big advantage, if you want fast, responsive graphical feedback.

NeWS processes can communicate with each other by manipulating shared data structures, and by sending messages through the event queue. They can receive low level input events ("The left mouse button was released at location (X,Y) in window W at time T"), and give graphical feedback ("erase the old slider, redraw it at its new position, and fill the border with bright red"). They can translate input from the user into high level, application specific events, which are sent to the client ("set the volume of the CD player to 100%"). NeWS processes can run autonomously in the server, without a connection to a client, providing "desk accessories" such as a calculator, event journaling, menus, and control panels.

According to the fellow from Adobe who talked at the PostScript BOF at the X conference, Adobe's Display PostScript provides output capabilities, but has no facilities for receiving input directly from of the X event queue. As I understand his explanation, the X server must send X events over the IPC link (network, shared memory, modem, or whatever) to the client, which must then translate the events into PostScript commands, and send them back over the link to be executed by Display PostScript. Because there is no way for PostScript programs to read events off of the X event queue, the client must process input events behalf of the display server. Messages must go on a round trip, from the X server, to the client, and back to the Display PostScript extension in the server, to produce any graphical output on the screen.

[...]

The NeWS "Lite" user interface toolkit is written entirely in PostScript. Menus, buttons, windows, sliders, scroll bars, and even terminal emulators, are implemented as device independent PostScript programs, in NeWS's object oriented PostScript programming environment. Since the toolkit can run in the server, clients can share the same code, and a copy of the toolkit does not have to be linked into each client. It's easy to mod

Since usability guru Jakob Nielson wrote Flash: 99% Bad in 2000, a lot has changed about Flash. He worked with Macromedia to improve Flash's usability, and he sells a report with 117 design guidelines for Flash usability. So yes, it is possible to develop usable applications in Flash.

OpenLaszlo is an open source language and set of tools for developing full fledged rich web applications, which are compiled into SWF files that run on the Flash player. Laszlo/Flash is presently much more capable of implementing high quality cross platform user interfaces than dynamic AJAX/HTML/SVG currently is.

Laszlo is a high level XML and JavaScript based programming language. It's independent of Flash in the same way that GCC is independent of the Intel instruction set and Windows runtime, because they both compile a higher level language, and can target other runtimes and instruction sets.

Currently Flash is the most practical, so that's what Laszlo supports initially, but it can be retargeted to other runtimes like SVG, XUL, Java or Avalon, once they grow up and mature. But right now Flash is the best way to go, because of its overwhelming installed base and consistency across multiple platforms.

The problem with SVG is that it's extremely spotty and inconsistent across the different browsers and plug-ins and cell phones that implement it. So the lowest common denominator is very very low indeed. Dynamic HTML has the same inconsistency problems but with much worse graphics, and it's that horrible inconsistency that forces cross-browser web applications to be so clumsy and hard to use -- because they must restrict themselves to the lowest common denominator. But Flash is consistent across all platforms, and it has high quality graphics.

I've written complex, rich interactive web based applications in both SVG and Laszlo, and I like them both. I've also used Microsoft's VML, which enabled animated vector graphics inline with html many years ago, and Dynamic HTML Behavior Controls, which work pretty well, but only in Explorer, so they're a dead end.

SVG is wonderful, but it's lost its steam: too little, too late. Adobe, once its main proponent, has totally forgotten about it, and they're quite unlikely to put any more effort into it, now that they've bought Macromedia. Batik development has been stalled, and it's slow because it's "100% Pure Java". SVG has some nice advantages over Flash, but it will never beat Flash's 98% penetration.

I'd love to see SVG get its shit together, but it's going to be a long time the way the companies that were once sponsoring it like Adobe, Canon and Kodak, have appearently given up and gone on to other things. I'd love for somebody to prove that I'm wrong, but Flash has kicked SVG's ass in the market.

Once there's a fast, stable, full featured, ubiquitious SVG renderer (like Firefox may someday support), it will make a lot of sense to target it with the Laszlo compiler. But SVG is a huge complex standard, and it will take a lot of work to completely implement it in Firefox.

But there's a much more interesting and efficient route than building everything including SVG and the kitchen sink into a web browser, and that's to factor out and develop a reusable open source Flash-compatible SWF player,

Doh. Sorry about that.

Laszlo is a platform for creating rich internet applications. It competes directly with (and pre-dates) Macromedia Flex. We open-sourced it last fall.

OpenLaszlo targets the Flash player as its runtime; that decision was made due to Flash's ubiquity. But there's nothing to stop it from being retargeted to Java, .NET, XUL, whatever.

More info here: http://www.openlaszlo.com/faq/

(note: I'm a Laszlo employee but these are my personal opinions)