Funny
you should say that. Informal observation has just about convinced me that the most efficient way to ship a Java program is as source code, as the classfiles seem to be large than their sources. Maybe old news to some, but I catch on slow.
Working with a lot of different GUIs over the years, my experience is that declarative GUI definition has two advantages: 1) the declarations typically are physically smaller than programmatic code. 2) because the declaration syntax is usually simplistic, it requires less labor to get results and it's easier to define automated validators.
The presumed advantages of programmatic GUI over declarative are that you potentially have more flexibility and would presumably be more effcient, since you'd only invoke services as needed rather than by rote. Java Swing's performance does make me pretty cynical on that, though.
XML is declarative, but not the world's tersest notation. It also requires a fairly heavy-duty decoder if you want to interpret the XML GUI at each execution (as opposed to generating code). Size isn't that much of an issue. Most XML has a lot of redundancy in it and thus will compress well.
Compressed XML is becoming quite a popular way to go on open-source projects. Compare the size of a Star Office document file (zipped XML) vs. the same document in Microsoft Office format and you'll be amazed at how much smaller the StarOffice
doc is, despite being expandable to human-readable text.
What about the extra overhead for compression? Good question. Quite a few years back the company I worked for ran some benchmarks and discovered that there was actually less CPU overhead involved when their system worked with compressed records than when it had to shuffer around full-sized buffers. Actual mileage may vary, of course. Both CPUs and I/O hardware are a lot different now, so I'd benchmark before betting the farm. It may have gotten worse. Or better.