Posts Tagged ‘chrome’

Some good discussion about Chrome OS

Tuesday, July 14th, 2009

Google’s recent announcement of Chrome OS generated a lot of press, not surprisingly. As usual with the tech press, a lot it consisted of mindless hype or knee-jerk contrarianism, but several blog posts I read seemed to have a thoughtful, skeptical (in a good way) outlook.

Putting What Little We Actually Know About Chrome OS Into Context
Discussing the relative failure of iphone web apps to native apps”:

Mediati was right that not just developers but users wanted native third party apps for the iPhone. The difference from what Google is promising with Chrome, however, is that web apps will be the native apps on the system. Presumably all of the default applications from Google itself will themselves be the Google web apps we already know. It’s an eating-your-own-dog-food issue. What irked about Apple’s endorsement of iPhone-optimized web apps as a “really sweet solution” was that, of course, none of the iPhone’s built-in apps were web apps. They were all written in Objective-C with Cocoa Touch. Apple’s own iPhone apps set a high bar for user experience — a height that could not (and still can’t) be reached with web apps running in MobileSafari.

and countering the “oh, it’s another linux distro” meme:

Whatever Chrome OS turns out to be, it isn’t going to be that kind of “Linux”. They’re using the Linux kernel, yes, but they’re building something new and original on top of that. Linux is to Chrome OS what BSD is to Apple’s iPhone OS — which is to say something that users will never see, smell, or notice.

Google’s Microsoft Moment
On Google’s public perception:

when Google evokes Apple or Microsoft or Oracle in its style of communicating ideas, and when cell phone ads on TV say “Powered by Google”, an average consumer’s conception of Google essentially shifts to seeing this company not as “those guys who do the search engine” but instead as another consumer electronics company, like Samsung or Sony, but a little more hip.
This would be okay, except that I doubt Google’s internal self-image as an organization has changed to reflect this new reality. “We’re not like some giant company with flashy TV ads — we’re just a bunch of geeks in Mountain View!” And while that might be true for the vast number of engineers who define the company’s internal culture, the external impression of Google being just another tech titan like Microsoft will gain footing, making the audience for Google’s messages less tolerant of ambiguity and less forgiving of mistakes.

On taking criticism:

Worse, because most of the dedicated detractors of Google have been either competing companies or nutjobs, it’s been hard for Googlers to take criticisms seriously. That makes it easy to have defensiveness or dismissal of criticisms become a default response.

Why Googlers should read Anil Dash’s post
Matt discusses Anil’s post (above), and how our internal concept of Google can differ drastically from how people see us from the outside:

Many Googlers, especially old-timers, still think of Google from early days, when we were the underdogs in search. But many people outside the company perceive Google as a huge company with an outsized shadow. We can scare people, even when we’re trying not to.

Lots of good advice there, and some of the comments on that post are worth reading.

Why it doesn’t matter that you can’t run Photoshop on ChromeOS today
Abe counters the surprisingly common argument I saw in some of the crappier articles on the subject:

“I’m not interested in ChromeOS, since it won’t be able to handle heavy-duty programs like Photoshop.”
That might be true today, but it won’t be true forever (or even for long).

I read one article that said that nobody would use ChromeOS because it can’t run Office (can’t find the link right now). Then just last week, Microsoft announces plans to extend Office to the browser. Heh!

Browser update

Monday, June 15th, 2009

For a couple of days last week, I decided to try using Chrome as my browser, to see how it was. I’m using a build of Chromium on linux (my mac doesn’t have leopard, so I can’t run Chrome). I typically run the latest full release of firefox on my desktop, and the latest beta of firefox 3.5 on my laptop. Anyway, Chrome performed well. Complex pages (Gmail, Google Wave, and a bunch of OCR analysis pages I use) felt more responsive than in firefox on the same machine. The browser crashed once, but recovered gracefully. At one point, the gmail tab I had open stopped responding to my key presses. Chrome popped up a window saying that the page was unresponsive and gave me the option of closing it down. I waited and the tab recovered without intervention. It was cool that this was caught, though it really shouldn’t be happening in the first place. It’s still prerelease software, so it’s OK if that happens.

My main problem with Chrome is the same thing that bothered me when I first tried it out on Windows: the address bar. It just doesn’t rank things the way I expect and it’s harder to visually scan than the firefox awesomebar (which I thought was somewhat hard to scan to begin with, but improved a lot since the first time it was in beta). It also makes it somewhat tricky to go to websites that look like http://somehostname/ (without .com, common for intranet URLs).

Firefox is still my favorite browser in linux, though I’m glad to have more options. Since my browsing at work biases more toward very javascript-heavy sites and pages with huge tables and complicated layouts, chrome is more useful than it would be for a typical user. As of this week, I’m using both.

Chrome Shorts

Thursday, April 30th, 2009

Chrome Shorts is a series of short videos about Google Chrome (sorta). This is my favorite because of its use of color, music, and animation.. it’s really quite beautiful:

My second favorite:

You can see the whole series here

Chrome Experiments, IE8 and browser speed

Saturday, March 21st, 2009

(This post consists of biased personal opinions, as always)

Chrome Experiments has some pretty cool stuff. The idea of the site was to create some javascript demos to show off Chrome‘s speed. Some of them also run in firefox (and maybe safari), though I wasn’t able to find any that ran in IE, mostly because IE doesn’t support <canvas>.

I’m running beta 3 of firefox 3.1 on all my computers now. Its javascript execution is definitely faster than 3.0. It didn’t perform too well on a some of the chrome experiments, though. Unlike IE, it could typically run them, it just wouldn’t be as smooth as Chrome (for example, 3D rendering). My favorite experiments are all among the top-rated, so try some of those out if you have a chance. Some of them are really clever.

I installed IE8 on my windows partition tonight. I haven’t used it enough to do a full review or anything. I don’t expect IE to return to the Mac any time soon, so I don’t really have incentive to try it. I stumbled upon this video on Microsoft’s site regarding browser speed. The video consists of a lot of flashes and text flying around to techno music, so I’ll save you some time and summarize:

Everyone talking about browser speed seems to think that micro-benchmarks are important, but those benchmarks are just made up and regular people have never heard of them anyway. The real way to test is in the load times of popular websites.

They then show load times from IE8, Firefox 3.05 and Chrome 1.0 on popular sites. As you might expect, IE8 did pretty well. They conclude that “IE8 is fast just like other browsers”

The type of speed Microsoft is talking about here is important, but it’s not what most of the browser speed discussion has been about. Their analysis is on the top 25 most visited sites, e.g. To time the rendering of has a high ratio of time spent rendering HTML to time spent running javascript. The same is true for most of the top 25: these aren’t javascript applications, they’re web pages. Rendering these quickly definitely has value, and I’m glad that the IE team has worked on rendering speed, but the claims of this video are a bit simplistic. Although IE does well on these simple pages, it can’t keep up on the javascript-heavy applications used on the web (e.g. Yahoo Mail, Gmail, Google Docs, etc). When the ratio of HTML rendering time to javascript execution time goes down, javascript benchmarks become more important.

I ran Firefox 3.1b3, Chrome 1.0 and IE 8 through the Sunspider javascript benchmark test. From the description:

This test mostly avoids microbenchmarks, and tries to focus on the kinds of actual problems developers solve with JavaScript today, and the problems they may want to tackle in the future as the language gets faster. This includes tests to generate a tagcloud from JSON input, a 3D raytracer, cryptography tests, code decompression, and many more examples. There are a few microbenchmarkish things, but they mostly represent real performance problems that developers have encountered.

I’m not asserting that this is a perfect test (it doesn’t test DOM manipulation, for example), but it’s not a bad way to get a rough idea about how a javascript engine is performing. Here are my results on an Intel 2.33GHz quad-core with 8GB RAM:
Chrome: 1193ms
Firefox: 2033ms
Internet Explorer: 5753ms
(click the links for a more detailed breakdown)

This speed difference doesn’t make mainstream web apps unusable today, but I worry that it inhibits the web apps of the future. Chrome Experiments is a good showcase for the types of things that are doable in javascript with a fast interpreter. If you showed me these a year or two ago, I’d think that they were implemented in Flash. Speeding up javascript and enhancing multimedia APIs (canvas, video, SVG) will expand the range of things possible in web applications, and I’m really looking forward to this faster generation of browsers becoming mainstream.