Netscape 4.X does not use JavaScript to render (except pages that use JavaScript, but I tend to avoid them and run with JavaScript turned off). Mozilla, however, uses XML internally to define everything, including menus, dialogs and rendering, and it's annoyingly much slower than Netscape. More flexible, yes, but it should take almost a second to render an ASCII page from memory cache. If Netscape 4.X vs. Mozilla is any comparision, then I shall veto this proposal (under the powers vested to me by Eris:).
I wasn't suggesting that the 4.X series of Netscape browsers used JavaScript for rendering, simply that it used the DOM APIs. The Mozilla browser is mostly *written* in XML and JavaScript, running on top of a the XPCOM component libraries. It also supports 'skins', declarative templates for UI widgets, access to the full internal APIs from Python and Java, and a host of other features which (while technologically interesting) are fairly unimportant to making a fast web browser. Yeah, it's slow; it could probably be made an order of magnitude faster by rewriting the front-end in C++, but Mozilla group has chosen flexibility over performance. There's no reason that every application using the DOM has to go this route, though.
In any case, this is such a major restructuring that we have better things to do first.
Do any of those "more important things" have to do with standardizing the internal views of object properties, by any chance? Or with updating the core to be fully Unicode-aware? How about interoperability with other applications? If none of those are priorities, then I understand why the DOM doesn't appeal. If they are, though, then perhaps you'll see where I'm coming from.
Lennon Day-Reynolds