google chrome, no love for OS X users
 

If you didn't know Google released their open source web browser called chrome a few days ago, and it is for Windows only. I have it downloaded but haven't had time to play with it. It looks pretty neat though.

http://www.google.com/chrome

Saw that in another article. Looks promising, I think. Supposedly it is laying the foundation for being able to better use applications on the web. So far, though, not near as fast as Safari or Firefox.

Makes you wonder about just how much the browsers are manipulating the users, as in directing their searches to preferred sites, etc.

But a Mac version is in the pipeline. It's also worth pointing out that Chrome is (currently) using Webkit for its rendering engine - i.e. the same as Safari.

So that's more market share for Webkit browsers - and more pressure on website operators to make their website Webkit compatiable - which ought to benefit Safari users.

Read the EULA, kind of scary in some regard. Actually it is on my blog if you click the link on my sig. Some of the things they mention are iffy.

Yes, but it is using an old version which is vulnerable to the carpet-bombing attack.


Mind you, I do like the fact that Chrome runs a separate thread for each tab, which means that a crash or resource problem with one tab does not affect any of the others. I wonder how long it will be before other browsers implement this...

Not long, I bet. And Firefox and Safari won't mine your websurfing for information that can be used for advertising and marketing purposes. Based on Tom's observations in the EULA, I suspect Google is going to mine all of your websurfing for information, not just the searches that go through their portal!

I actually trust Google, but that's just me.

Anyway, I ran the SunSpider javascript test on 5 different browsers my PC, and here's the results:
http://spreadsheets.google.com/pub?k...4LXArg7YBupeVw

IE wasn't graphed because the results were too large, but you can still see the results on another tab.

Chrome seems to do well in everything except "date" and "regexp".

Oh, and if anyone wants to, they can Digg it.

Chrome spawns separate processes for tabs. This has the benefit of easily-terminable tab instances, but comes with an IPC overhead and a substantial memory usage overhead.

Talking of multithreaded tab implementations, well, it's Really *****ing Hard. And the UI is still single-threaded by nature in Mac OS X, so it can't entirely eliminate issues anyway. But yeah, really hard.

edit: I actually censored myself this time and the forums STILL blotted me out :(

I'm not sure where you made the jump to multithreading, since you previously (and accurately) acknowledged that Chrome uses multiple processes - rather than multiple threads - to spawn new tabs. Where were you going with this?

Well, keep in mind that google does have a spread sheet, word doc, and presentation. This puts them right up to microsoft in terms of running and sharing business applications over the web.

I for one get tired of having to switch from firefox to internet explorer because of all the business applications targeted to run on internet explorer.

But companies are slow to move away from internet explorer from what I'm finding out.

I didn't make any kind of jump. I was only commenting on the difficulties of multithreading since the guy I responded to mentioned it.

Ah, sorry - I missed that! In that case, I do understand why you were referring to multithreading!

This may be so, but I don't see its relevance to the point I was making. Namely, more Chrome users is likely to give Safari users a better web experience.

I agree with your point entirely (I should have said this in my original reply). I was just trying to point out that it is not the *exact same* rendering engine as Safari uses, but an out-dated version (in case some people thought Chrome and Safari were equally secure). As you state though, more Chrome users means more WebKit users, which hopefully means a better Web experience for Safari users.


Yeah, my bad. I was under the impression that each tab was a separate thread, not a separate process. I now know the right answer...!

Google's Chrome is a key stroke logger!
Google's Omnibox could be Pandora's box
http://news.cnet.com/8301-13860_3-10...ml?tag=nl.e433

In addition to security concerns, I'm leery about a web browser or site that tries to remove any of my control or take over the UI from my system.

If a site wants to pop up a window with no tool bar then I don't want to use that site. Now Google wants us to use a browser that seems to want to do that and more all the time! It may not be as bad as I fear, and I hope not.

apparently its a buggy son of a browser....


hope they fix it before we get it

It's prerelease (beta) software. It's a bit silly to complain about how buggy it is.

hush!

oh im gonna regret saying that

Well, the EULA has been rewritten and Sergey Brin said it was "embarrassing" that there was no Mac version yet.

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.