Not a memory hog?! The smallest tab currently opened takes 18MB; the largest 83MB for a single tab. Each extension takes an additional ~13MB. It's using a grand total of 725 MB private memory, for 18 tabs.
Is that really where all of the memory goes? On a normal consumer-grade HDD a disk seek is ~10ms and reading a megabyte sequentially is another 10ms or so. Conservatively speaking it should be possible to load a site from the disk cache in under 50ms, and in practice that would probably be quite a bit faster (especially if the data is in the page cache). With that kind of speed it would make sense to persist these caches on disk if a page isn't actually opened in any tabs.
I don't know if data like this exists in an easily understandable format (i.e. not just cryptic massif dumps that would only make sense to WebKit hackers), but it would be interesting to see a heap profile of a WebKit/Safari session to see what's using all of the memory in an "empty" browser session.
Fast history browsing is plenty useful when undoing a closed tab. Not sure if Safari does this, but on Firefox if you undo a closed tab, the tab comes back exactly as it was before, with history intact. I use that feature quite a bit.
The bit about the Cloud being like electricity is very insightful.
However, if you've lived anywhere outside the US and Europe, you know that grid electricity is not as available as you're used to. In third world countries, electricity goes off periodically, specially in places where there are wars.
When I was young (and living in the middle east) I heard a joke where 3 men: an American, an Arab, and an African were asked the question: what's your opinion about electricity going off? The American says: does electricity go off? The African says: what's electricity? The Arab says: what's an opinion?
I visited Iraq in 2000; practically everyone had an electricity generator at home. I had to learn how to operate it and refill it with gas.
That should read "The Africa says, 'What electricity?'"
We certainly know what electricity is; we've heard of it and understand its usefulness; we even use it almost daily. However, as you aptly noted, its availability is sufficiently irregular and inconsistent that we expect it to be off as much as it is on.
Sure, maybe it's not bad in Brazil, but there are many places where it's not super good.
In Syria and Jordan, it goes off for about 3 hours every two weeks, or something like that (not scheduled, just randomly). I think the same is true for Egypt. I've heard the same about India. In fact, I've heard from a trusted person that computer/software offices in India have their own backup power generators. I can only assume the same applies to hotels and factories.
I absolutely love Chrome. I recently ditched Firefox + Firebug for Chrome [Canary build] + Developer Tools.
It didn't take any time to get adjusted with the new Firebug like CSS editing and I no longer have to deal with having to regularly restart Firefox once it becomes sluggish.
The majority of Chrome users have no idea that their browser is silently updating itself without their knowledge or consent, and if they did, they wouldn't have any idea how to shut it off.
I can think of plenty of cases where most users would want to turn it off—tethered to a slow data network, throttled bandwidth, etc—but the precedent it sets bothers me more than any hypothetical inconvenience. It's like I'm suddenly, unknowingly leasing a little space on my machine to Google, and I'm not always sure what they're installing.
You raise a valid point about not knowing exactly what is being installed, but the flip side of the coin is that security fixes and new feature support get adopted much faster.
It's nice knowing that mom's laptop will automatically receive that security patch.
Because it's a usurpation of my role as the administrator of my system. Because it necessitates a level of comfort with a company—whose business model is based on collecting and selling user data—rooting my system, and trusting that they're not going to abuse that privilege, or forget my best interest when acting in their own best interest. I think that's a good enough reason.
It's debatable what the best default setting would be, and wether or not average users:
a) know how to disable this
b) care to disable it
Like you say, it necessitates a level of comfort with a company. I suppose most people don't give this a lot of thought, and thus feel pretty comfortable with any company.
Wether this is "good" or "bad" is a separate discussion imo.
I think the problem here is the "one size fits all" assumption of the Google-centric future the article describes.
The browser update policy is a great example. Probably the world would be a better place on average if mom and pop auto-updated, but the policy has serious downsides. For one, it's a pain for me as a geek who likes to know what is running on his machine (and who, frankly, doesn't trust Google as far as he could throw it). It's also a pain for me as a web developer, because of the various breaking changes Google is demonstrably willing to make in its browser, as discussed in several recent HN threads.
There are other problems with "one size fits all" that I think undermine the entire premise of the article, though. If Chrome is to be the new OS, then does that mean every application front-end in the world has to be written in JavaScript? On the evidence to date, this is not going to be a success...
Similarly, "[Google App Engine] just runs the code you give it, and you don’t much care how" sounds like a great argument, until you realise that you have to write your code using the tiny fraction of the available programming tools that happen to be supported by GAE.
Given that in this business, the two most common scenarios are keeping geek opinion on your side or your company failing rather horribly, I think we can safely assume that nothing Google offers today is even close to comprehensive enough to displace native apps and make cloud/browser software the norm. Oh, and if the article author thinks that broadband-speed wireless is going to become as ubiquitous as electricity within a few years, I think he probably needs to go back to physics school. :-)
The updates are really small. As they've detailed in a number of blog posts, the patch format is a custom binary diff that understands the format of ELF/EXE/etc. file formats to get the smallest diffs possible.
Also, on Linux systems Chrome does not automatically update. When you download the deb/rpm from Google it sets up a package repository (e.g. by adding a file like /etc/yum.repos.d/google-chrome.repo) and you get updates via the usual package update mechanism on your system. I have no idea if this will ever happen, but it seems like if there was a better integrated update system for OS X and Windows then Chrome on those systems could have an option to work in a similar way.
It's not really the size but the principle of it. Google is installing something on my PC without asking me about it. Ev6en if in this case the result is good, it's not the kind of thing a program should do.
I know that when one installs Chrome, they are implicitly accepting that it will update itself, but it still is a very unique behaviour that wouldn't be accepeted in most programs.
When gmail rolls out an update, do you want to pre-approve it also? The only thing google does with chrome is bring the web model of automatic updates to a desktop app.
If you think about it, the only reason we want the control is because we don't trust software companies not to mess up our system. The crazy thing is wanting manual updates, because it implies gross incompetence from the software industry.
Well. Personally I see a whole lot of difference between web applications and code running on my machine.
In the case of gmail, I rely on their code only for checking/sending mail. And they have access to just my mail data. When something runs on my machine, I need to be a lot more careful about what data that code has access to and what privileges it has.
Since email is used to recover lost passwords, just checking/sending mail is equivalent to "the keys to every website I have an account on". By trusting Google to keep your email safe, you're trusting them to keep your entire online presence safe. In that light, letting someone run code on your computer seems relatively tame.
Statistically speaking, our crash rates have been going down with each release. However, there are, of course, always more crashers. If you'd be willing to help us diagnose the issue, we'd be appreciative.
Dev channel user here. Can't say I experience this at all. However, I have heard from other users that some extensions can cause the browser to crash. Not sure which, unfortunately.
You might want to click around in the preferences and make sure you click to enable anonymous usage data to be sent to Google. I think that sends crash reports back, which the team then triages to prioritize the bugs that are causing the most crashes for users.
I have been experiencing wierd crashes with some HTML 5 games where the whole browser crashes. It's funny because they are supposed to be standalone processes.
I think what Chrome really needs is the ability to watch HTML5 video in full screen (not just fill the browser window). At least this is Chrome's functionality on my Mac. I realize full screen video is not part of the HTML5 spec, it's left to the browser to implement. Safari will do full screen HTML5 video...
I agree with most of the article. Android and Chrome OS are great products, I just don't see how Google is going to make money from them.
Not sure about Chrome, but I feel like Android is a defensive measure against a possible monopoly. If one company controlled mobile then Google might be locked out of whatever greater potential mobile could reach. So Android doesn't necessarily have to be financially awesome to be strategically successful.
The influence of Chrome and Android on web development are very probably part of what Google is aiming for. It's the anti-Facebook/Apple, in a way, which should help Google Search keep earning enough money to support all the other peripheral projects.
I read recently that 90% of HTTPS traffic for Google properties <> Chrome is handled using SPDY. Interesting also that Google continues to put more and more of their properties on HTTPS.
I think Chrome is useful for them for just this reason, rather than solely trying to cajole others, they can just do things. I imagine this will continue to accrue benefits to them for quite some time.
As I read the article, and only a paragraph or two into it, I was reminded once again why I think Google naming both their browser and their Linux distro "Chrome" was a bad idea. Feels like an amateur mistake the kind I wouldn't expect them to make but they did. Yes, technically, one is called ChromeOS, but obviously many folks are going to drop the -OS part when talking about it, thus causing confusion.
It's not a weird-ux like IE, it's snappy unlike Firefox, it isn't a memory-hog like Safari, and it's well-supported (unlike the runner-ups).
It also has an epically nice PDF reader, which could be its own product and I would be very, very happy.