Can XUL meet the goals of stdgui?

Can XUL meet the primary goals of stdgui?


1. Programming language independent?
No.  UI is written in XML and Javascript.  Must use XPCOM to call out to C/C++.  But if Javascript is your language of choice, you're set.

2. Native rendering?
Yes.  "The main backends are Linux GTK2, Mac, and Windows" (src).  Qt seems to be supported too.  I even saw some Windows 8/Metro stuff in the source which is promising.

3. Rapid Development?
Probably.  After the learning curve I sense that it would be good for RAD as long as your logic can be accomplished with provided Javascript APIs.  The XUL Explorer tool sounds very similar to my stdgui previewer idea.

Summary
XUL really does a lot of things right in my opinon:

• The UI definition is language-neutral by using XML and stylesheets.
• Their box layout model is powerful without being overly complex.
• Native rendering
• Overlays allow reuse of XML snippets and facilitate extensions which tweak the original UI.
• Templates (aka databinding) is a really powerful concept.
• Their widget-set has exactly what you would want.

That said, I have some reservations:

1) Requires bindings to develop a non Javascript application.

2) Is XUL development subordinate to FireFox development?  Will XUL maintain backwards compatibility in the long run?

3) Unfortunately it appears that XUL has some pretty significant memory overhead.  For example, the XULPeriodicTable example, which demos all widgets and layout features of XUL occupies 65MiB of RAM on my machine.  That's more than GIMP with no images open!  And the barebones helloWorld takes 41MiB.

In my opinion, this limits it's uses to "big applications".  People will accept high memory usage for a big application but for little utility programs it's kind of embarrassing.  Since I'm targeting stdgui towards the later, this rules out XUL.

Fork It?
Since XUL is a lot closer to my goals that any other toolkit, should I fork it and try to make it work?  I would make changes such as:

• No Javascript interpreter.  GUI events would be exposed to the host language by simple string IDs.
• Create a minimal C API allowing the host language to communicate with XUL.
• Remove the Gecko rendering engine if possible.  Otherwise try to trim it down and reduce it's memory overhead.
• Simplify the Templates (databinding) approach.
• Generally remove features and APIs not directly benefiting small GUI programs.
• Make some parts of the XUL markup more terse? (eg <li> instead of <listitem>)

Doing this would create a rather divergent project.  Probably little of this work would ever be merged back into official XUL.  I guess it then comes down to this.  Would this approach save time?  More exploration is needed to answer that.