Hacker News Reader

Comment by pecg | Hacker News Reader

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.

View on HN

> 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.

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

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.

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.

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.

>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.

Reply on news.ycombinator.com