Firefox to get massive JavaScript performance boost
arstechnica.com
arstechnica.com
When we ran our app in FF3 for the first time, we were dismayed to find that, after all the talk about browser performance improvements, it had actually gotten a lot slower (especially when scrolling) [~]. As far as I can tell, they're optimizing the wrong stuff. It's possible that our app is unique, but I doubt it. To judge by Google, many people appear to be experiencing the same thing.
[~] Safari 3, on the other hand, sped up our app considerably.
Edit: The only person I know of who's raised this issue is John Resig: http://ejohn.org/blog/javascript-performance-stack/
It will make a difference in real-world apps which are currently impossible because they would perform poorly. It will become reasonable to start putting real number-crunching into browser-side JavaScript code—things like crypto, physics calculations, etc. As one example, JavaScript games are going to get a whole lot better in the next couple of years.
(Not to say that they shouldn’t be optimizing DOM access, or scrolling speed, or whatever.)
For those of us working on things where the UI requirements are more intensive, little progress has been made. Perhaps the pure JS stuff is getting more effort because it's more glamorous?
funny you mention that, but I think a lot of things are driving by glamour or fashion.
Although in this case its clearly an engineering achievement, so kudos, and its great to have 2 competing and excellent open source browsers.
But still... glamour...
I'm sorry to say that Firefox has become more about the marketing and less about the code - they're too worried about looking good in the benchmarks and raising their mass-market appeal than about true good code and user experience.
From JS benchmarks to SSL certificates (http://royal.pingdom.com/?p=339) to false advertising of FF3's memory consumption (http://neosmart.net/blog/2008/firefox-3-is-still-a-memory-ho...) - it's all going downhill.
I have good friends on their *Monkey teams and can say without a doubt that there's a lot of impressive code going in there. Stuff that someone absolutely needs to be doing-- and it's all available for free.
I agree I'm also annoyed with FF memory consumption and some stability issues I've had lately, but I can't disagree more firmly on the quality of the code they have. Without much research, you can find code at Mozilla that's better than what major for-profit companies are producing out of their R&D-- and it works across a dozen platforms.
Then the fucking browser wars started, and all of us fucked away hours on it, and Firefox/Google took notice and started playing the game, which was a shit move.
So the coding is still good, no doubt, but Firefox has become a movement rather than a piece of software.
I would love to see Firefox become the industry standard. It will force other browsers to start playing by the rules, mainly living up to standards and working harder to make a better product. Competition is what creates better products. When you have a monopoly or are the only major player in an industry you aren't as innovative. You don't need to be. Look at the cell phone market pre iPhone... now everything is touch screen and has internet...
The thing that most pissed me off was their "Firefox vs. Safari" comparison chart, where Firefox got points in things like "encourages developing standards" and a ton of things that AREN'T web browsing. Their marketing has NOTHING to do with how good the browser is, EVERYTHING to do with pure glam. Same with setting a world record. That did nothing to prove anything, nothing to counter the criticism that Firefox was getting for things.
And, not to get all fanboyish, but Firefox is an inferior product. Opera is slimmer and faster, and yet can do far more out-of-the-box. On the Mac, as alluded to before, Safari is a godsend. Firefox looks wrong, it's too cluttered, it doesn't support two-finger scrolling well or three-finger navigation at all. And the team almost certainly knows this. Yet they've ignored constantly the fact that they're making an inferior product and continue to market their product as the best there is. Which, at least on OS X, it's not.
I think the thing that I like most about Steve Jobs is when, in a marketing interview, he said, "Apple TV might not work. Other people have tried and failed. There's every chance this will fail too. In which case we'll improve again." Apple is famous for marketing, but it's famous for marketing in a more honest way: they don't lie about their product. Firefox and its developers do. That's what's wrong with their marketing.
Edit: I realized my reference to Resig might be misleading. It's a post from Feb 2008 about browser optimization in general, not FF3. The point is that he talks about how browser optimization has to include rendering and DOM operations.
They can optimize all they want, and it'll help, but Intel hit a wall with CPU performance, and multi-core is the future.
I think this is the blog post by Brendan Eich you are referring to:
So my default answer to questions such as the one I got
at last May's Ajax Experience, "When will you add
threads to JavaScript?" is: "over your dead body!"
There are better ways. Clueful hackers keep rediscovering
Erlang. Then there is STM. One retro stylist I know
points to an old language-based solution, Hermes.
A requirement for JS3 (along with hygienic macros) is
to do something along these more implicit lines of
concurrency support. In all the fast yet maintainable
MT systems I've built or worked on, the key idea (which
Will Clinger stated clearly to me over lunch last fall)
is to separate the mutable unshared data from the
immutable shared data. Do that well, with language and
VM support, and threads become what they should be:
not an abstraction violator from hell, but a scaling
device that can be composed with existing abstractions.
So here's a promise about threads, one that I will
keep or else buy someone a trip to New Zealand and
Australia (or should I say, a trip here for those over
there): JS3 will be ready for the multicore desktop
workload.
in essence, he plans to take advantage of multicore processors not with threads but with better and/or more programmer friendly methods.
Does he not realize that the browser is basically the OS these days, and he's keeping it in Windows 3.0 territory?
It's time to make a thread for the UI, and a thread for each window, and each tab (child windows AKA popups, shall thread with their parent). JS can't cross those walls anyway, so his probably with concurrency are not as bad as he thinks.
Btw in HTML5 there is a proposal for cross-window communication http://www.w3.org/html/wg/html5/#crossDocumentMessages which is asynchronous. This would allow communication between different threads using message passing.
Oh! Well I sure read that wrong. I thought he was against threads in the browser. So I guess there is hope.
If one tag opens another, it's a child of the first, so they should thread together.
Javascript already has threads anyway (setTimer, and events), they are just serially scheduled - on a single core it's identical to regular threads. So you already have to deal with concurrency issues in javascript apps (although it's not as bad as full threading since I think a single function is allowed to run to completion before something else is scheduled).
As gruseom stated, interacting with the DOM and rendering as still significantly slower than iterating through an array. I believe tracing very well could be the key to unlocking advances in that area s well.
Unfortunately, IE is still quite slow. I think we'll soon reach the point where it's not the browser feature inconsistencies limiting what cross-browser JS apps can do, but the performance difference.