I use the browser at work and I don't really like it. It looks children and it's a little condensing to a power user. Firefox puts this browser to shame.

For my needs on Windows, I will stick with Firefox. For my needs on a Mac, I will stick with Safari.

A question for Mikey:

Is there any kind of development roadblocks in the way of making Chrome a reality on Leopard? Any difficulties you can think of?

I'm sort of thinking that that might be the reason it isn't released for the Mac yet. However, I don't think I'm right.

uh oh

you're only gonna get steered down a bad path here

You're probably right, actually. They have to get around the roadblock I discuss below, as well as change some Win32-centric code to something that'll work on Mac OS X.

Now for the roadblock. Real quick, to recap, remember that each tab in Chrome is actually a separate child process--it's a totally separate application in memory.

I don't know how or if it's different in Windows than in Mac OS X, but in Mac OS X you cannot draw directly into another application's window. You can't insert your views into another app's windows, you can't add one of your windows to another app's window list, you can't obtain the graphics context of a view from another application into which you can draw, and you can't just hack around it all and write bitmap data straight into some app's graphics data buffer. (It's for your own good. Well, the greater good.)

In Leopard, you can obtain information about windows belonging to other applications, via CGWindow, but that doesn't get you anywhere. You can get an image representation of another app's window, its name, and some other data, but you can't get anything you can use to draw web pages from Child Process X into Parent Process Y's window.

One of the options you're left with is to keep the tab UI within the browser application itself (no choice here), and spawn a child process for each new tab that is responsible for the network transactions (page fetches, POSTs, ajax requests, etc), JavaScript execution of individual pages, and rendering the page to an off-screen context (basically, drawing the page into an invisible image buffer). This rendered data can be shared between the parent browser process and the UI-less child tab process. The browser obtains the data from the child process and draws it into the tab.

Looking over the Chromium site, it looks like that's what they're going to do:

http://dev.chromium.org/developers/m...etailed-status

While it still requires the tab UI elements and actual rendering views to be part of the main browser application, it accomplishes the goal of moving as much as possible to easily terminable child processes.

I'm just glad they fixed the EULA, the way that it was first written kinda freaked me out. I personally would never have used the browser if that was true. For those who missed it, go visit tlarkins blog...

Chrome is BLOODY FAST. I'm using it to post this.

I think I'm actually going to switch to Chrome.

We've been checking it out at work, and I can't say the performance has blown me away after having used recent WebKit nightlies. Memory consumption was also higher, if I remember correctly. But it at least felt faster than Firefox 3 and was comparable to WebKit nightlies, both in very informal comparisons, and that was pretty cool. We're really only scratching the surface of how fast web browsers can be.

Unlike John Siracusa, I'm not crapping my pants over Chrome, but I can see it becoming a very compelling browser for people who aren't hypernerds. The interface is very simple and spartan, which is great, but it has a ways to go before it's an HI masterpiece.

I can't stray away from firefox there are some add ons that I must have now. Firebug, mouse gestures, adblock, web developer, measure it, so on and so forth.

I could care less if it renders a webpage 1 second faster than another browser, I want my add-ons!

How fast a page can render once is not the metric browsers will be judged on going forward. See also: SquirrelFish, TraceMonkey, and V8.

Well, if the mac version is going to look like the windows version, they can keep it. Yes, it's really that bad.

I disliked the UI to chrome, yes. But if Google takes the firefox approach and makes the program's UI resemble that of the platform it's being used on, I couldn't see a reason not to add it to my browser collection.

I use Safari and Firefox at the same time sometimes, because Firefox does some things better than Safari, and vice versa.