HTML and CSS provide an extremely easy and flexible method to build highly stylized user interfaces - something like is lacking in Desktop GUI design (unless you embed a browser). However HTML falls very short when it comes to building complex UIs. We need to find the common ground, and make it applicable to all environments.

So I believe we should create a single Toolkit API that will work in both desktop applications and natively in the browser. I think HTML is what we base our design on, and in concept is quite similar to XUL - expect that the markup is processed at compile time producing a native widget tree for desktop apps, and pure HTML for browser apps.

This is pretty much what Microsoft is doing with XAML - expect they abandoned all existing infrastructure, requiring a plug-in, users to upgrade to Vista, or download the sizable .NET/WPF runtimes. Furthermore they reinvented the layout and style, so developers have no leverage of their existing HTML/CSS experience.

I would like to blur the line as much as possible b/w building a web interface and a desktop interface - at some level there should be no difference and code should be reusable. I should be able to define my GUI in an XML file for a desktop app - just like I can with HTML in a web app.

I like the concept of XBL used in XUL, though their implementation is a little awkward, the idea is pretty much the same, where this markup:

<fan:GridPane>
  <div>TextA</div>
  <div>TextB</div>
</fan:GridPane>

Gets converted to this HTML:

<table>
  <tr>
    <td><div>TextA</div></td>
    <td><div>TextB</div></td>
  </tr>
</table>

I think we'll have a DOM API as well, so I could produce that HTML markup programmatically with this code:

g = new GridPane()
g.add(new Div("TextA"))
g.add(new Div("TextB"))
document.body.appendChild(g);

Obviously to support an HTML model for the desktop we'll need a rendering engine. I considered trying to reuse something like Gecko - but I think the core renderer needs to be written by us so we have the flexibility we need. And I think we can get away with only supporting a subset of HTML - and requiring valid XHTML. For complex documents, we could look into embedding Trident or Gecko as an HtmlPane or something.

# Widget API details

I see our Widget API as purely modeling data and behavior of a widget, and not containing any rendering or eventing code. This gives us a lot of flexibility for how the display is rendered. For example, consider Button (not really sure what this looks like, so very rough - but the separation should be clear):

class Button extends Widget
{
  // Only knows he has a text property, and 
  // a single callback when pressed  
  Str text
  Void pressed() {}
}

class ButtonDesktopRenderer
{
  Void paint(Button b) { ... } // render code
  Void mousePressed(Button b, MouseEvent e)
  {
    ...
    b.pressed()
  }
}

class ButtonHtmlRenderer
{
  Void paint(Button b) { ... } // markup
  ...
}

This design coupled with XBL-style widget definitions gives a really clean way to model widgets however we see fit. For example, ButtonHtmlRenderer could potentially take the DesktopRenderer code and render an SWF or SVG version. Or maybe it produces a Canvas. It's open-ended. Anyways, these are some of my initial thoughts.

I agree that we should reuse HTML/CSS where appropiate. I really want to come up with a unified UI architecture for browser/rich clients - but we've tried for a decade now and it's extremely hard.

Our model should be like XAML - a clean unification of documentation style (HTML), vector graphics (SVG), and widgets. The trick has always been the code required to execute - if we can pull off Fan in JavaScript that opens up huge opportunities.

However, I don't ever want to use XML as a source language - rather Fan will be the language used to define everything including declarative stuff like widget layouts. A primary principle of Fan is the flexibility to define DSLs for stuff like this (and probably also for CSS like styling). What I want Fan to be known for is a universal language that doesn't require you to learn 10 different languages to get something done - one syntax, one type system, one "hub" for all tools and APIs. However it must be flexible enough to define DSLs for problems like this.

I don't see any big issues with the unified architecture - except full HTML support in the desktop to start with - which seems ok, given that we have support for richer widgets. Fan -> JavaScript is a pre-req here.

We still need to support HTML for web interfaces - and I think it would be interesting to apply that for desktop apps as well. And we'll need the XBL-style constructs I mentioned. But you are right, its only HTML or Fan - nothing else.

I spent some time this week looking into the state of the browser, and no matter how you spin it, HTML is a very poor technology to build a real UI on top of. So I have come around on this. I think we need to take the Microsoft approach and design something from scratch that really address the needs of widgets, styling, vector graphics, etc - all with the ease of use that HTML/CSS and the DOM allow. Lot more to say, but I'll postpone till I have more time to delve into things.