> 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