Firefox final releases.

These are the builds that show up on the main page on mozilla.com.  The current build is Firefox 3.0.5 and users who previously have downloaded and installed Firefox 3 are automatically updated to builds as we release them.  They are generally done on a 6 week schedule, or as security or bug fixes require.

Firefox 3.1 does not have a final release yet and as such it’s not on this page yet.

Firefox beta builds.

There is a link on mozilla.com to download released betas.  If you’ve downloaded and installed one of these betas you will also be offered betas as we release them.  Once we move from beta to release candidate, you will be offered upgrades to the release candidates and eventually to Firefox 3.1 final when it’s released.

Firefox beta nightly builds.

As of the writing of this entry, Firefox 3.1 development has branched and our beta, release candidate and 3.1 final work is being done on a separate branch.  We generate builds every day for people to test beta functionality.  You can find the built nightlies on our download server in the latest-1.9.1 directory.  (In addition, have a look at our mozilla QA project (QMO) for information about how to get involved!)  If you’re following this set of builds you will get the opportunity to update one or more times a day with new builds.  As of Beta 2, these builds are pretty stable and these are what I’m currently running for all my day to day work.  You can tell these are the beta builds because they are named “Shiretoko.”

Firefox trunk nightly builds.

This is the rawest of the raw (although still not too bad!)  This will eventually become Firefox 3.2 or Firefox 4 or whatever we end up calling it.  Fixes that are set to land in the Firefox 3.1 branch land here first, so it’s a place to test out fixes before they make it to the beta channel.  You can find these builds in our latest-trunk directory.  You will likely see more instability and bugs here.  Updates are done daily, or sometimes more than once a day.  If you’re running these you definitely want to be involved in our QMO effort.  You can tell these are trunk builds since they are named “Minefield.”

Hope this helps – enjoy!

“I think that the next 18 months we’re going to see a 100 to 1,000 fold speed increase in JavaScript as Google and the guys at Mozilla are going to kick us all in the arse and make our JavaScript jittered,” Microsoft senior program manager Scott Hanselman told the audience, days after Google released its Chrome browser, which features faster JavaScript technology.

[...]

“It’s going to be hard to tell if it’s going to be Silverlight or JavaScript we’re going to use for our applications,” he said. “I think in the end JavaScript is going to be a bigger competitor to Silverlight than Flash is.”

Hell yes, we’re making the web kick ass.

In terms of claims some members of the V8 team have been bragging a little bit about how V8 is “many times faster” than TraceMonkey. In fact, some guarantees may have been made.

Based on the data above, we’re running about 20% faster than V8 on SunSpider. While I’m sure there will be changes to each of the engines in the coming months I think that the claim that “many times faster” is ludicrous on its face and should be tempered by actual data. [ Note that the Google test is recursion heavy, something we're adding to TraceMonkey right now. This explains the gap on that one type of test. See Brendan's post above or John's post below for more details. ]

It’s also important to realize another fact. Google has had a small army of people working on the V8 engine for two whole earth years. We’re about 60 days into TraceMonkey and we’re already starting to match the performance characteristics of V8. As Brendan put it:

What spectators have to realize is that this contest is not a playoff where each contending VM is eliminated at any given hype-event point. We believe that Franz&Gal-style tracing has more “headroom” than less aggressively speculative approaches, due to its ability to specialize code, making variables constant and eliminating dead code and conditions at runtime, based on the latent types inherent in almost all JavaScript programs. If we are right, we’ll find out over the next weeks and months, and so will you all.

If you want data across browsers you should look at this post from John Resig that contains some graphics that give relative performance of various browsers including Safari, Firefox 3.0.1, IE, etc. His overview is great and gives a much wider view of relative browser performance.

Also as a side note because I have your attention. There are some bizarre and incorrect claims made in the comic about garbage collection. Brendan puts things right as a comment in John’s post:

@Ben: Chrome has a nice GC: exact rooting, generational with copying. Single-threaded, too (not an option for SpiderMonkey, which is used in AT&T 1-800-555-1212 and 411 AVR massively multi-threaded services built by tellme.com, now owned by Microsoft!). It definitely helps cut down on pauses and keep memory use flatter.

The Chrome comic book did have one piece of misinformation, though: it said other browsers’ engines use conservative GC, and have false positive problems because they can’t distinguish random integers from pointers into the heap. This is not true of Firefox, IE, or Opera.

We do live in interesting times.

I love what google chrome represents. The work that we’ve been doing inside of the Mozilla project over the last ten years has really paid off. The fact that Google believes that they can launch a browser based on new technology means that the market is alive.

Apple is making releases, Mozilla is making releases, even big slow Microsoft is making releases. The rate of browser releases is getting faster, not slower. Google’s browser beta is a sign of health. JavaScript is evolving and being seen as a general purpose language. People are already embedding SpiderMonkey into a lot of other apps. The work that Mozilla has been doing on JavaScript performance with TraceMonkey and Google has been doing with V8 means that it can reach more and more use cases.

It’s also great to see the end user features flowing from browser to browser. The malware/phishing stuff mentioned in the comic is already shipping in Firefox 3. JS performance is something that everyone is working on. Inside of Mozilla we’ve been talking about the multi-process model that they have decided to use in order to get proper rights mgmt on the mac and windows. IE is including some of these random features in IE8 and we’ll be including a lot of them as well in Firefox 3.x. Two items that come to mind are worker threads and geolocation, features that are already undergoing testing as part of the Firefox 3.1 work. The fact that everyone is sharing ideas and moving along the same lines is great for users and great for the web. It’s starting to feel like a healthy economy of ideas.

We haven’t seen the browser itself yet. So I’ll wait until they actually get code and downloads up to comment on any of that. Given some of the features that are featured in the comic book, it will be interesting to see what the role of data and privacy will be in the product. But more on that once they actually put up something for people to play with.

As a side note, the comic is a great piece of storytelling and outbound marketing. Tells you everything you need to know to re-tell the Google Chrome story to other people without any of the drudgery of a spec or product sheet. For those of us who are interested in how things are sold and marketed, it’s a great piece of work.