Ars Technica Reviews Mozilla

Aglassis writes "This Ars Technica review gives mozilla 1.0 an overall score of 7/10 (9 for Gecko and 6 for the browser). The major detractor was the user interface, since it didn't feel like a Windows application. This was probably due to a poor understanding by the authors of XUL. Overall they say that mozilla would make a good substitute for IE 6 but there is no major reason to switch over."

Comments

Re:x-platform

[ttfkam]

*sigh*

Repeat a lie enough and it will become truth I guess.

The real skinny on XUL: It is not as slow as people make it out to be. It is not the reason for Mozilla having any speed problems. It *is* compiled into native instructions when your browser is up and running. This functionality made it into the tree some time ago. Too many people were howling about the slowness of XUL two years ago to notice apparently.

Don't believe me? Try running a profiler on Mozilla sometime and report back the hotspots. What's that? Even though the source is available and people have access to profilers, not one of the XUL naysayers here even tried? But that would mean that they pulled XUL performance stats out of their asses. (To be fair, a couple of years ago, XUL had some major redrawing and rendering issues -- not the case today. Maybe it's just a case of stale info that desperately needs to be thrown away) In addition, projects like Galeon are not faster because of native widgets (although it may have been the case a couple of years ago). IF you look at feature-to-feature, Mozilla does more than Galeon. Just look at the JavaScript engines, the DOM handling (the DOM debugger, the DOM inspector,
etc.), the fact that Galeon only runs on one platform(!), etc. Galeon is not Mozilla + native widgets. Galeon is Mozilla-- + native widgets.

Does XUL intrinsically look exactly like native widgets? No. Does the classic theme look very much like native widgets. Absolutely. Does the modern theme look like native widgets? No. Was it planned to look "native"? No! Modern theme looks the same no matter what platform you are on. If you want consistency of browser UI when using multiple operating systems (as I do), then use Modern. If you want something more akin to a native feel, use classic. If you absolutely want native widgets, use Galeon, K-Meleon, or Chimera. That's what these projects are there for!

As a side note, XUL is rendered by Gecko. You can't say that one is slow while the other is fast. They are different limbs of the same beast.

As was pointed out on the Mozilla performance newsgroup, there is no magic "native" flag that makes video cards paint faster. Whether a widget is linked from a shared library, compiled from C, or read from an XML file (and later translated to machine instructions), they all paint to the same canvas: the system graphics library. If MFC has some innate advantage here, I'm sure that the folks who write Qt and WxWindows would love to hear about it as well as they would no longer be "native" either.

The reason that Mozilla developers can handle the large number of platforms that Mozilla runs on is because of XUL. The code is amazing in its cross-platform purity. Fix a mail client bug here and it's fixed everywhere. Fix a UI bug there and its fixed everywhere. Contrast this with fixing a UI bug in the Windows code and it must be fixed in Mac (OS 9- and OS 10+), X (Xlib, GTK+ and Qt ports), BeOS, OS/2, OpenVMS(!), Amiga, etc.

I'm not saying that XUL didn't take a long time. I'm not saying that it saved a whole lot of development time until recently. What I am asserting is that all new bugfixes and enhancements can now happen much faster (and have been for the last year or so) than would be possible with native libraries and widgets. And it's not like Mozilla isn't modular and reusable; how do you think Galeon and K-Meleon were able to be released so quickly? They whipped up a barebones UI up on the infrastructure written by Mozilla developers. If you like Galeon, K-Meleon, and Chimera, it probably has more to do with liking barebones UIs than an inherent deficiency in Mozilla's UI. That said, if that's your preference, more power to you. Just don't shit on someone else's meal when your food comes from the same kitchen.

What the Mozilla developers have done is akin to shunning assembly language for C. Back in the day, C was slow and bloated as compared to hand-crafted assembly. Then people noticed that they wrote more and with fewer bugs with C. Then the compilers got better. Then assembly didn't make much sense except in small niches. Imagine! Writing your UI in a simple text file and handling UI events in a simple scripting language. Don't like the UI colors? Just edit CSS files instead of editing .c files and waiting for the recompile. Your program UI can be as simple as editing a web page!

But I can hear it now. "But it's not as fast as compiled UIs." "It uses more memory." In a couple of years, advances in the rendering engine and the XUL processor (think 'compiler') will narrow the gap so far as to make the gap imperceptible. It's assembly versus C all over again. Which side do you want to be on? Personally, I think life is too short for recompiles.

If you want to get down and dirty, recompiling at every step, write an operating system or help out on the Gecko renderer and XUL processor. For everything else, there's XUL, scripting, and CSS.