>Really, did you measure it? Since we are, scientists and everything? Where are the numbers?
This remark should (also) have been directed at his parent comment, who made the contrary claim without any measurement either.
> Second, if you think the "parsing a XML UI declaration" is in any meaningful way more expensive that imperatively calling a bunch of UI functions directly, you have a distorted idea of what makes a UI slow, or of the time needed to parse an XML file and initialized controls based on it...
The numbers?
I'm not a scientist, so I did not measure it, however my empirical analysis suggests that this is indeed the case. Non-native UIs are noticeably slow. They don't have a monopoly on being slow, but they are slow across the board.
You might want to read this ode to fast software: https://craigmod.com/essays/fast_software.
Really, did you measure it? Since we are, scientists and everything? Where are the numbers?
And how do any differences you've found compare (timing wise) with human initiated action and perception latencies -- like those required to click an on-screen button and see it being depressed?
>as seen in Mozilla's XUL or typical web apps
You see button being pressed time/action as a problem in "XUL or typical web apps"?
(Memory consumption when the drawing is done with DOM, or slow rendering of large scene graphs, I'd buy -- but this is not the model we're talking here, where JS calls a native control directly, and doesn't render through DOM/web rendering).
>I can't even imagine why you'd think that reading and parsing XML and constructing a UI would be cheaper than any other way of building UIs.
Actually that's the way tons of native apps work, from games, to Gnome, to Windows and so on.
Second, if you think the "parsing a XML UI declaration" is in any meaningful way more expensive that imperatively calling a bunch of UI functions directly, you have a distorted idea of what makes a UI slow, or of the time needed to parse an XML file and initialized controls based on it...