Power of Thought

Most of today’s web sites and web applications are built using the JavaScript scripting language. Some may say that a trend towards the fine-tuning of JavaScript interpreters in modern browsers was just a matter of time since any such optimization translates into performance gains. Mozilla recently launched the browser speed race with Firefox 3, which delivers more speed than any other previous Firefox version. Apple answered with Safari 4, claiming the browser’s JavaScript engine has been accelerated by 53%. Welcome to the browser speed race.

Safari 4 has just been seeded to the developers at Apple’s developer conference. The manufacturer claims that the software has a 53% faster JavaScript engine than the preceding and current version 3.1 (based on the SunSpider JavaScript Performance test conducted on iMac with an Intel Core 2 Duo processor at 2.8 GHz, with 2 GB of RAM and running under Mac OS X Snow Leopard.) Although Firefox 3 RC3 was the first to deliver significant JavaScript performance improvement, Apple apparently is exceeding those gains with Safari 4.

Apple uses a new and improved JavaScript interpreter code-named SquirrelFish, which is provided on an open-source basis from the WebKit project, the same organization that makes the open-source engine used by Safari to render web pages. According to the WebKit project, the SquirrelFish engine is 1.6 times faster than the JavaScript engine in Safari 3.1.

SquirrelFish does its magic by turning JavaScript script into so-called bytecodes, an optimized code much more suitable for run-time execution than natural language-based JavaScript commands, which are longer and more complicated to interpret – and therefore are slower.

Why JavaScript performance matters
Most today’s web applications and web 2.0 sites rely on the JavaScript scripting language originally created by current Mozilla CTO Brendan Eich while he was employed by Netscape. JavaScript acts as glue that connects a user interface rendered in a web browser with a database and programming logic running in a web server. The browser’s JavaScript engine is solely responsible for interpreting and executing JavaScript commands embedded in HTML code. As a result, a browser’s JavaScript engine performance is directly related to the performance and responsiveness of a web application, contributing to an improved user experience.

The fact that many applications grow in size and become more bloated with each release means that a browser that can run web applications faster and make user interfaces more responsive on any computer is actually a big deal. You don’t have to have any specific market forecasting talent to predict that this trend may be impacting browser market shares: Speed can directly translate into more usability for most of us. Clearly, JavaScript handling is on its way to become a powerful weapon in the browser market.

SpiderMonkey, SquirrelFish, Tamarin and more
Mozilla was the first to introduce significant speed gains with Firefox 3 beta 5 (the final version is expected to ship by mid-June). Firefox has its Gecko engine to render web pages, which is generally considered to be slightly slower than Safari’s WebKit – which is largely responsible for the “fastest browser in the world” status Safari enjoys. Firefox’ JavaScript implementation is based on Mozilla’s own and decade old SpiderMonkey technology, which many considered to be the fastest JavaScript interpreter until SquirrelFish came out.

Although in beta, Firefox 3 scored with many reviewers who are praising the browser’s performance improvements, with WSJ’s Walt Mossberg declaring the browser a “winner.” But now that the SquirrelFish/Safari combination appears to be offsetting the speed gains in Firefox 3 and may set a new benchmark, we can expect more direct competition between Mozilla and Apple. Mozilla has plans to expand SpiderMonkey with Adobe’s JavaScript engine called Tamarin, included in Flash 9, which has a so-called “tracing” feature designed to enable faster code execution. However, the SunSpider JavaScript benchmark claims that SquirrelFish is at least 1.9 times faster than Tamarin.

Mozilla plans to wedge Tamarin into Firefox and match the API’s of both technologies “There are areas in which SpiderMonkey is faster than Tamarin and areas where it’s not. We’re looking to build hybrids that are best-of-breed for both worlds and we’re going to pull those into the Firefox release when ready,” Mozilla co-founder Mike Shaver recently said.

Can IE8 compete?
The big variable in this game is Microsoft’s Internet Explorer 8, currently in beta 1 phase. IE8 is expected to deliver speed gains in JavaScript performance as well. However, Microsoft is facing a tough task. The fact that the software giant is often criticized for delivering bloated and inefficient software certainly doesn’t help. In our tests, the first beta of IE8 shows no noticeable speed gains in running web applications.

Quite the opposite is the case, actually. Websites and web applications run noticeably slower than in IE7. The whole browsing experience generally appears to be less responsive. Of course, IE8 is in an early development stage and you can bet Microsoft is going to tweak its performance. The only problem is that the software giant will have to work to raise the stakes in the browser race. If IE8 under-delivers, the market could respond with further market share erosion for IE. It is evident now that JavaScript engine performance has become a key metric in the newest race for the title of fastest browser.

The battle ahead is nicely summed by Mozilla co-founder Mike Shaver who said the following: “They [Apple] have dropped SquirrelFish in now and got a big speed up there. We’ve got more coming on our side. You’ll see this leapfrog pattern over and over. We’re not going to let anybody slack on that and the other browser vendors need to keep up, too.”

According to Net Applications, Firefox 3 captured almost one fifth (18.41%) of the browser market in May, followed by Safari 3.1 which hit 6.25%. Microsoft’s Internet Explorer continues on its pace of a slow but steady decline, ending up at 73.75% in May. Microsoft has scheduled second beta of IE8 for an August release, with a generally expected final release in the fourth quarter of this year.

Read more »

Mozilla aims to make Firefox 3 a record breaker. It wants the release of the next version of its flagship open source browser to be accompanied by a record for the most software downloads in a single 24-hour period*.

Download Day - as Mozilla dubs it - will begin the minute Firefox 3 is generally available and continue for 24 hours. Ahead of this release, expected in mid-to-late June, Mozilla has set up a website (spreadfirefox.com/worldrecord). This encourages people to organise Download Day parties, to run around collecting sign-up pledges at their university or place of work, and to place Download Day buttons on their websites.

Firefox 3 is based on Gecko 1.9, an updated layout engine. The browser features a cleaner layout, better bookmark handling and more stability. And it’s faster.

RC2
Mozilla decided to release a second release candidate for Firefox 3.0 at a meeting on Tuesday, in response to the discovery of 10 performance and stability bugs. The alternative would have been to patch these potential “showstoppers” after the browser shipped. But another round of testing is the safer option - not least from the standpoint of public relations. This will probably set back the official launch by five days or so.

Last November Mozilla hit back at claims that multiple bugs in its forthcoming Firefox 3 browser would be ignored in order to meet release schedules. At that point Mozilla was grappling with 700 bugs marked as “blockers” (i.e. a flaw serious enough to justify delaying a release, or at least merit a closer inspection).

Skip forward six months and we’re at the point where the browser is in fine-tuning to eliminate the last few high-priority bugs.

In a development list posting on Tuesday, Mozilla’s lead developer Mike Beltzner explained the strict patch acceptance policy for Firefox 3 RC2. “Just because we’ve decided to product another release candidate does not mean that we are accepting new patches - only those which fix issues that have been identified as required fixes for RC2 will be accepted, and even then your patch must come with a risk assessment and tests,” he writes. “Many of the issues to be fixed in RC2 have already been patched, reviewed, approved and landed.”

* Mozilla is trying for a record in a new category, according to a representative of the firm. That means it doesn’t have an existing mark to better. The open source browser outfit aims to secure over 1.6m downloads over 24 hours.

Firefox will be available from multiple locations. We must assume the bandwidth and server capacity will be in place to service the rush.

Read more »

Whatever happened to open-source projects being released according to development readiness, rather than an arbitrary release schedule? Mozilla seems to have forgotten this, with the New York Times reporting that the upcoming Firefox 3.0 set to ship with only 20% of its remaining 700 “blocker” (serious enough to justify postponing a release) bugs resolved before it ships.

Of course, Mozilla has already fixed over 11,000 bugs, according to Mozilla developer Asa Dotzler. Even so, that doesn’t answer the apparent fact that the Firefox development community is planning to ship a product before a wide range of known blocker bugs are resolved. (Firefox 3 meeting notes can be perused here.)

For now, the mountain to climb appears quite high, as the New York Times notes:

As Mozilla pushes to post Beta 1 of Firefox 3.0, it has asked developers to prioritize already-identified bugs so that the most important can be fixed. But according to notes of yesterday’s Firefox 3.0 status meeting, that will leave about eight in 10 [remaining] bugs untouched.

“We have 700 bugs currently marked as blockers,” the notes read. “That’s too many. We’re asking [requiring] component owners to set priorities on blockers, as a first pass of what bugs should be Beta 2 blockers. You want it to be about 10% of blockers, or what you can get done in four weeks.”

On the positive side (and I mean that sincerely), Firefox 3.0 continues to miss its stated deadlines. I think this is good. It means that, in fact, Mozilla is prepared to put quality of code before an arbitrary release schedule. My life will go on if I continue using Firefox 2.0. In fact, Firefox 2.0 works exceptionally well.

What I don’t want is to transition to a presumably “ready” Firefox 3.0 only to have it routinely die on me. Fix the bugs first, Mozilla. There’s just no need to hurry the release.

Read more »

The process of creating ECMAScript 4—the next-generation JavaScript dialect—has become increasingly acrimonious as major stakeholders argue about the future of web scripting. The latest feud is between JavaScript creator Brendan Eich and Microsoft representative Chris Wilson, who have differing views about the long-term viability of the ECMAScript standard.

The vast majority of web developers acknowledge that JavaScript in its current form is anachronistic compared to modern dynamic scripting languages. The ECMAScript 4 draft process hopes to resolve weaknesses with the language by adding additional syntax elements, many of which are heavily influenced by Java and Python. ECMAScript 4 is largely backwards compatible with conventional JavaScript, which means that it provides a clean glidepath for updating legacy code.

Critics like Microsoft and Yahoo argue that certain characteristics of the language (particularly the prototype-oriented object model) make it impossible to add modern language features to ECMAScript without dramatically increasing the complexity of the language, breaking existing code, and creating new interoperability problems. Such critics believe that the focus should be on improving interoperability between existing ECMAScript 3 implementations and that modern scripting capabilities would be best provided by using a completely different scripting language.

Although this approach could provide a cleaner language for web scripting, it would mean that all existing JavaScript code would be trapped forever in the ECMAScript 3 standard and would have to be completely rewritten in order to benefit from much-needed modern language features. There are also serious concerns that new alternative languages would be less standards-oriented than ECMAScript.

“[T]he ES4 proposal introduces a lot of new language functionality that essentially changes the character of the language,” wrote Wilson in a recent blog entry. “I don’t personally have a problem with that language as a language—but I think grafting that different-in-character-language together with a compatible-and-performant implementation of the Javascript of today is both super-hard (if even possible) to get right, and is ignoring the bigger problems of language-for-web, namely interoperating with all the script that is out there.”

The accusations fly
Wilson and other critics have complained that their concerns are being suppressed and ignored by Brendan Eich and others. Several participants in the ES4-discuss mailing list claim that Adobe and Mozilla are authoring the spec in a manner that best suits their interests without consensus and that other parties are simply shouted down or ignored.

“I think it’s a shame that dissenting opinion has been hidden from view, and not publicized,” said Wilson. “I also think it’s a shame that the response to any dissent has equated to shouting the dissenters down. The string of blog posts over the last week, and the immediate and somewhat incendiary comments from ES4 proponents, has been a good example of that.”

Eich and those who are satisfied with the current process and direction regard those allegations as FUD—baseless nontechnical criticisms that add nothing of value to the ECMASCript 4 process. In an open letter to Chris Wilson, Eich criticizes Wilson and accuses him of dishonesty.

“You seem to be repeating falsehoods in blogs since the Proposed ECMAScript 4th Edition Language Overview was published, claiming dissenters including Microsoft were ignored by me, or ’shouted down’ by the majority, in the ECMAScript standardization group. Assuming you didn’t know better, and someone was misinforming you, you (along with everyone reading this letter) know better now. So I’ll expect to see no more of these lies spread by you,” wrote Eich in his open letter to Wilson. “At best, we have a fundamental conflict of visions and technical values between the majority and the minority… There certainly was no shouting down of the dissenters—that’s a bold lie in view of the well-attended and friendly dinners sponsored by the face-to-face meeting hosts.”

A way forward?
Although Microsoft representatives haven’t stated outright what they would propose for a new web scripting solution, the writing is pretty much on the wall. Microsoft’s Silverlight rich Internet application framework uses .NET and the Dynamic Language Runtime, which brings support for IronPython and IronRuby to web scripting. Using languages based on Python and Ruby for next-generation client-side scripting solutions makes a lot of sense on many different levels. A growing number of developers already have experience with those languages and many tools already exist to ease development with them. A single multilanguage runtime could be used in the browser to support JavaScript as well as more modern scripting languages.

Mozilla has already tacitly endorsed this approach with its own (prodigiously cool) IronMonkey project, which aims to build a bridge between Microsoft’s open-source Dynamic Language Runtime and Mozilla’s Tamarin virtual machine, which will be used to run ECMAScript 4 code. When we reported on IronMonkey back in July, more than a few Ars readers posted comments expressing a desire for a future in which client-side web scripting could be done entirely with Python and Ruby rather than with JavaScript.

As a developer with experience in Python, Ruby, and JavaScript myself, I know that I would definitely prefer Python and Ruby to a new dialect of JavaScript that liberally incorporates features of those languages. That said, it is worth noting that advancing JavaScript with the ECMAScript 4 standard as envisioned by Mozilla and Adobe doesn’t preclude the possibility of adopting multilanguage web scripting platforms.

The real question is whether or not it still makes sense to extend ECMAScript regardless of whether or not alternate languages are made available as well. Eich argues that ECMAScript 4 is important for furthering standards-based web scripting, but critics are still concerned that extending ECMAScript in the manner proposed by Eich will fail to address critical security and interoperability issues while putting backwards compatibility at risk. Eich still doesn’t believe that anybody has adequately articulated these problems in a way that shows real concern about the technical merits of ECMAScript 4.

Meanwhile, parties on both sides of the debate are becoming increasingly accusatory and have taken to publicly criticizing each other’s motives. Web scripting needs to move forward, and it’s unfortunate that the process has become mired in controversy.

Read more »

After a couple of experiences dipping a toe into the mobile market, Mozilla Corp. said it plans to get serious about developing a mobile browser.

Mozilla has recently hired two new developers to help work on the project and plans to release Mobile Firefox some time in the next year or two.

The iPhone, Apple Inc.’s popular new mobile phone, in part contributed to the renewed interest in mobile browsing at Mozilla. “The user demand for a full browsing experience on mobile devices is clear,” Mike Schroepfer, vice president of engineering at Mozilla Corp. wrote in his blog on Tuesday. “If you weren’t sure about this before, you should be after the launch of the iPhone.”

As Mozilla continues to develop Mozilla2, the second version of the platform on which Firefox is built, it will add mobile devices as a category. That means developers of Mozilla2, which is expected to be complete in early 2009, will keep mobile phones in mind as they build the new platform, Schroepfer wrote.

He didn’t get more specific on a release date for the mobile browser other than to say “not before 2008.” Schroepfer also said Mozilla hadn’t yet decided which mobile phones the browser would work on.

Depending on compatibility, Mozilla could face competition from companies such as Microsoft Corp. and Apple that include their own browsers in phones running their operating systems, as well as from third parties such as Opera Software ASA that have been fine-tuning their mobile browsers for years now.

The announcement comes after the release earlier this year of a new version of Minimo, a Mozilla-based mobile browser for Windows Mobile devices. A few months prior to the release, the lead developer of Minimo said he wouldn’t be spending much time on the project in the future. On Tuesday, Schroepfer said that there are no plans to further develop Minimo.

Mozilla also offers Joey, a project in development that lets users clip and save text, photos, videos and other content while using a PC and then access that content through a browser on a cell phone.

Mozilla is also involved with a group of companies including Arm Ltd. and MontaVista Software Inc. that is developing an open-source Linux-based platform for devices that are bigger than a cell phone but smaller than a laptop. Mozilla is developing a browser for the platform and has already built one for a similar device, the N800, from Nokia Corp.

The new Mozilla hires who will contribute to the mobile Firefox initiative are Christian Sejersen, who recently worked for Openwave Systems Inc., and Brad Lassey, who worked for France Telecom R&D, which has been very active in mobile Linux initiatives.

Read more »