Andy and I kicked around the idea of how to approach the miserable state of UIs today. One of the things we kept coming back to is that if you have to pick b/w browser and desktop, it's probably a better bet to make browsers a top priority. And that keeps coming back to that the only "platform" you can count on in HTML/JavaScript/DOM/CSS. Hopefully with SVG and Canvas up and coming inclusions into the "platform".

So we started thinking about outputing Fan as JavaScript in addition to bytecode and IL. If we can make a clean JavaScript implementation of the sys library, it would give us tremendous flexibilty for using Fan as a unverisal language and treat the browser/js engine as just another "VM platform".

I kind of think of it along two lines:

C became a universal systems language because you can output machine code for all sorts of platforms (well probably just about every processor architure). C was "portable" to processors. I'm starting to think of Fan as "portable" across the next level of abstractions: platforms like JVM, CLR, browsers, (others...). I think good open source tools that let me plug in C compiler back-ends - same approach we should take with Fan.

Another way to look at it is that the world is this big ugly mess of incompatible technologies. On the server side you tend to have Java / .NET / LAMP / etc. On the client you have Swing / Win32 / Browser / etc. But we can make Fan a clean slate that elegantly hides all these messy details, but lets you leverage all this existing infrastructure.

Could just be a pipe dream, but we could pull it off - Andy is going to test the waters.

I've been thinking about how fan can target multiple platforms. I'm not sure where we currently stand with aliasing, but the last email I could find on that subject had the jalias and nalias stuff in the code.

That's going to have to move out of the source code and into a platform definition. I'm thinking we could also include fixed parameters in the aliasing to handle cases where a single "platform" method handles multiple methods in fan. I'm not sure if there are any real use cases for that though.

Each module would have it's own platform definition mapping classes and methods in fan to "native" platform classes and methods.

Here's a simplified string example. I'm not sure how this applies to the "web" platform yet.

native class Str
{
  native int size();
  native Str upper();
  native Str lower();

  Str reverse()
  {
    Str rev = ...
    return rev;
  }
}

--- platform definition for Java ---

<platform id="jre" module="fan.sys">
  <class fan="Str" alias="java.lang.String">
    <method name="size" alias="size"/>
    <method name="upper" alias="toUpperCase"/>
    <method name="lower" alias="toLowerCase"/>
  </class>
</platform>

--- platform definition for .Net ---

<platform id="clr" module="fan.sys">
  <class fan="Str" alias="System.String">
    <method name="size" alias="Length"/>
    <method name="upper" alias="ToUpper"/>
    <method name="lower" alias="ToLower"/>
  </class>
</platform>

I think it is a necessary long term thing to approach platform specific aliasing in outside files, but not a short term issue - just because only we will be doing platform bindings and it is far easier to have it all co-located in a single file. I hate the separation that is forced upon right now as it is. Plus if we did move it outside the source file, then I think it would still be Fan code (using XML is just something we Java guys use because Java code itself is so difficult to represent config data in). I'm still not sure you can ever fully separate the platform aliasing from the compiler, so it might not ever be as clean as we would like. Plus remember that most things probably aren't really aliased as much as just using a separate implementation. We'll figure it out as we go I think.

I've got some really basic stuff compiling from Fan and being emitted as JavaScript. I think this looks feasible - but I won't really know until I get more into it.