Google Frame Benchmarks 9x Faster than IE8

ChiefMonkeyGrinder writes "Early tests with Google's Chrome Frame found IE8 runs 9.6 times faster than usual. The testers ran the SunSpider JavaScript benchmark suite." The other question is what is the performance hit of using the Frame plug-in instead of running the browser natively.

Comments

Re:Whats the point...

[GooberToo]

Likewise, I've seen javascript which manipulates large datasets, which takes the lion share of time to run; somewhere in the 30-60 second range. Recent javascript performance boosts have allows such manipulation of large datasets to become feasible and even practical.

The truth is, more and more people are attempting to use a browser as a general purpose user interface for many applications which were previously considered unattainable with older browser technology and I only see additional momentum building in this direction.

Fast rendering and javascript is a make or break for most of these types of applications.

Re:benchmarks always forget the user experience

[Anonymous Coward]

Aside from the retrieval of a page, rendering said (static) page will be instant in almost all cases, regardless the browser. If it doesn't, either the page is way way way too complicated or you are using an antiquated machine.

Welcome to the world wide web, TheRealMindChild. Out here pages are "way way way too complicated". You can close your eyes and go "lalalala" but that doesn't mean those pages aren't there.

Re:EEE

[99BottlesOfBeerInMyF]

quote>Looks like Google are going to try and beat Microsoft at their own game: Embrace, Extend, Extinguish.

I've seen several people mention this in the last mention of Google's plug-in as well. I don't understand and I have to wonder if the people saying this know what the strategy they're referring to is. The concept of "embrace, extend, extinguish" is to comply with a standard interoperably until you are popular. Then extend the standard in a non-interoperable way, counting on your popularity and the new functionality to drive adoption. Then, extinguish the competition by utilizing the standard ubiquitously and in a non-interoperable fashion so that anyone who does not have access to the proprietary extensions you added, is removed from the market.

So for IE the strategy was to implement HTML and other technologies interoperably until IE was very popular, then extend HTML with nonstandard elements and rendering and add ActiveX for more functionality no one else could use. Then extinguish competition by building lots of tools and that rely upon the proprietary version and relying on Web developers to target IE's broken version of HTML instead of the actual standard.

So I'm trying to understand how people think Google is employing this strategy. They are embracing IE, sort of by implementing Web standards within it. How do people think Google is going to extend those Web standards in a proprietary way? Do they mean by building proprietary Web applications that use the standards? Do people actually think Google's strategy is to make Google apps really popular and then break compatibility with non-chrome browsers by making them no longer use Web standards? Won't that be hard while maintaining backwards compatibility especially since they're using an OSS browser? I suppose this is possible, but I don't see why people would assume it is Google's strategy.

So basically, while I see that Google is extending IE to use Web standards, I don't see this as a likely part of an "embrace, extend, extinguish" strategy. Nothing stops Microsoft from creating a better implementation of Web standards in IE's rendering engine and out competing Google's plug-in and they have a lot of advantages if they do decide to compete. Rather, this is Google managing to chip away at MS's anti-competitive use of IE and make MS actually compete fairly a little more, pretty much the opposite of Google trying to kill fair competition which is what the EEE strategy is all about.

Re:Whats the point...

[mcrbids]

The truth is, more and more people are attempting to use a browser as a general purpose user interface for many applications which were previously considered unattainable with older browser technology and I only see additional momentum building in this direction.

We are doing *exactly* this. We provide a hosted, vertical software system, and for years we've done everything in our servers.

However, recent builds of the FireFox JS engine are fast enough that we can start moving the processing out from our hosted application server cluster into the user's browser. The users love the results - applications that load in a few seconds, and run from their computer at near-native speeds, accessible anywhere.

But, rather than spend inordinate amounts of time trying to get stuff to work in IE, we simply require Firefox. That way, we can support Windows, Macintosh, Linux, and any other platform that runs FF 3.0+. It's not been hard for us to make this requirement, basically only minor complaining from techs.

Our customers are more interested in "Cross Platform" meaning "Can I get it to run on MY computer" than "Can I get it to run in MY browser".

The evolution of javascript performance is an industry changer - it's what makes hosted applications actually WORK, despite all its warts.