[pecg]

This looks good, I think that it would be worth giving it a shot. My main problem is XML, it is always incredibly slow to parse, and there is not an accepted defined way to express the content, s-expressions would do a much better job, perhaps a combination between C parsing scheme definitions of UIs could work.

[flukus]

> My main problem is XML, it is always incredibly slow to parse

They could always add an option to compile it, much like xaml, it may even be as simple as a xslt transform.

[stuaxo]

Woa, XSLT to create an executable.. it's so twisted I hope someone does this.

[zbentley]

For most UI toolkits, isn't XML parsing happening pretty infrequently (and mostly at startup)?

Speeding up start times is a laudable goal, but this comment makes it sound as if the performance implications are more significant than that.

[jbreiding]

I think this depends of the levels of nesting and complexity, but a libsax based parser is not "incredibly" slow.

A Dom based parser could be, but also depends of number of nodes and nesting.

[learc83]

I'm not sure why the OP thinks that parsing XML is any slower than any other data representation method that allows arbitrary nesting.

Love sax by the way. I just switched over one of our sites to use a sax based parser because the default rails .to_hash was choking on 100MB+ XML files.

[baybal2]

>XML, it is always incredibly slow to parse

I don't see libxml2 being slower than any other markup language parser. In comparison to how slow some JSON (an easier to parse language) parsers are, libXML2 is actually quite fast.