MozillaZine

Shock as MozillaZine Readers Turn to Slashdot for Accurate Information

Thursday October 31st, 2002

For our last poll, we asked you where else you go to get Mozilla news. 848 of you answered with Slashdot getting 30% of the vote, almost twice as much as its nearest rival, MozillaNews, with 17%. The third-placed 'None of the above' option was favoured by 16% of you, which frankly tells us very little. FUD specialist MozillaQuest came in fifth with 8% of the vote, which concerns us slightly. 5% of you rely on mainstream tech news sites such as CNET's News.com or eWeek while 4% of you prefer the weblog style of Blogzilla. Newcomers Planet Mozilla and MozFan didn't do so well with 1% and 0% of the vote respectively. NewsForge, with 1%, also did surprisingly badly, especially considering the amount of news we steal from them. Finally, 14% of you just go wherever telnet to port 80 will take you.

For our next poll, we'd like to know what your favourite Phoenix theme is. The options are taken from the lists at the mozdev Themes project and David Tenser's Phoenix Help so don't blame us if your favourite theme isn't listed. Go and vote now or just sit on the fence and watch the latest results.


#79 Re: Thanks for the clarifications

by asa <asa@mozilla.org>

Sunday November 3rd, 2002 10:33 AM

You are replying to this message

HJ, perhaps you're an expert. If not an expert then maybe an advanced XUL developer. If you've even been thinking about which parts of XUL and XBL are faster and which parts are slower and how one can gain performance without sacrificing functionality by optimizing JS, finding alternatives to overlays (things like writing a XUL preprocessor so that slow platform overlays can be avoided), cleaning up XBL and even DTD collapsing and other methods then you're a leap ahead of most of the people that have been hacking on Mozilla's frontend.

Also, it may be no surprise to you but looking at the changes that have been made to Phoenix for performance improvements _was_ a surprise to many of the Mozilla developers who have taken a look at it.

Not only that, but no one was doing it. Until mozilla/broser there simply wasn't anyone chopping with broad strokes to demonstrate these kinds of performance and size optimizations. No one was demonstrating that it was possible to add functionality while improving speed and performance. Performance enhancing changes made to Phoenix are already filtering into Mozilla so it's no secret how to make things faster but until the people that know best how this stuff works took a swipe at it nothing was being done.

(Not to mention that Mozilla today is a hell of a lot more performant when it comes to FE than it was say 2 or 3 years ago and the overwhelming majority of those gains were made by this same group of people. I don't think it was a random hacker that took on implementing XUL and JS fastload, or collapsing rdf files, or preventing style resolution on nsXULElement, or created XBL for better and more performant widget building, or implementing image region specifiying, creating outliner to replace tree in certain cases and then upgrading all of those cases, re-writing the mozilla style system, implemented XBL methods brutal sharing, or almost all of the skin cleanup to improve Modern and Classic, or any other of the major FE performance innovations and implementations over the last few years. Experts or not, the ones that have actually created real and testable gains in UI performance and responsiveness are the ones working on Phoenix today.)

And why start a mozdev project? If you think you can find additional performance wins why not contribute those to Phoenix or Mozilla (or Beonex)? What additional gains are you investigating? Are there bugs filed? Patches? Are all of the right people seeing those bugs?

--Asa