For a lot of web apps, including the one I'm working on, the JS interpreter isn't the bottleneck, or even close. Basically, anything involving rendering or the DOM is orders of magnitude slower than pure JS computation. So what's the point of optimizing function call and loop overhead? For what real-world apps will this make a noticeable difference?
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.
> … what's the point of optimizing function call and loop overhead? For what real-world apps will this make a noticeable difference?
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.)
What you're saying is reasonable - for apps that don't need much UI. I wonder, though, how many real-world examples there are of apps that people have tried and failed to write in Javascript for this reason.
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?
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.
I have my beefs with Mozilla, but to say they aren't focusing on code is crazy. The stuff they're doing (especially with the native JS compilation) is very difficult stuff that honestly has a chance to change all browsers for good.
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.
I think he was using words loosely - I have the same problem. Namely, this isn't nerds working on something awesome anymore. It's marketing. Old Firefox wouldn't have done something stupid like break a world record: it didn't need to. It was all about finding a browser that you liked and using it.
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.
Is there anything wrong with marketing? Sure on one hand you could say they "sold out". But underneath all the open source and hackers they are a company... a for profit company at that. They are pushing a product that is superior to the current standard and are forcing inovation that might have taken significantly longer had they not become a serious threat. So if a few tactics like setting world records helps spread the word and make the internet better, I'm all for it.
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.
I'm glad you're not running Firefox. Google's money enables more programmers to work on it, marketing allows it to grow market share which puts pressure on IE and less directly to make the web more standard. The loss of your idea of some sort of purity is a nothing price to pay for turning Firefox into a force for the advancement of the web.
This is not my experience. Moving from FF2 to FF3 I saw noticeable improvements in the application responsiveness, especially in moving DOM objects around the window (ala draggable dialog boxes full of objects), mouse event handling, and in generation of new DOM children. While at the same time FF3 was using less memory.
Yeah whilst this does mean some computation expensive things can be pushed to the client more (without plugins) - I think you are right. Most real world disappointment with browser rendering performance is DOM related. Eg large grids in data intensive applications.
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.
This is nice, but the only upgrade firefox actually needs is multithreading and they won't do it (according to some blog I read, which I couldn't re-find).
They can optimize all they want, and it'll help, but Intel hit a wall with CPU performance, and multi-core is the future.
> according to some blog I read, which I couldn't re-find
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.
Yah, that's the one. And we'll see if he delivers, but I know one thing right now: when I sit and wait while one very slow site freezes the whole browser, I get quite annoyed.
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.
I think Eich is advocating against explicit thread support in JavaScript like e.g. Thread.run() in Java. Separate threads per tab is an unrealated issue as long as the tabs cannot communicate. Tabs might however be able to communicate if one tabs opens another through script. In that case it might introduce racing conditions if the tabs runs in different threads.
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.
>I think Eich is advocating against explicit thread support in JavaScript
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).
This is a huge achievement for the future of the web. While the basics of what we're doing now are very simple, the ability to have code be compiled on the fly is exactly is needed to get JavaScript near pre-compiled code boundaries. I do yearn for a world where our biggest successes are much bigger than forums that graduated into social sites.
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.
While I consider myself a WebKit man, it's good to see Firefox competing, The competition benefits everyone.
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.
I think its already here for the bleeding edge. I have seen some (small) apps where they give up on IE purely for performance reasons (their users are happy for that compromise) - buts its ONLY for performance reasons.
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/