Wednesday 3 September 2008
Chrome
A few people I know have asked me what I think about Google's Chrome browser.
Technically, it looks good on paper. There are some interesting architectural problems they haven't solved yet, especially with the process separation model, especially with regard to windowless plugins, and also Mac. These are problems that will be encountered by anyone doing process separation so it will be interesting to see how that goes. V8 seems overhyped when you take into account the JS work being done by other browser vendors.
I'm not sure how the competitive landscape is going to play out. Mozilla's in a strong position now and the immediate future looks great. We just need to stay focused, keep making smart decisions, and keep shipping great software.
Overall, I'm actually really excited. No matter who gains and who loses, there's no doubt that this innovation and investment and energy is great for the Web (especially when it's delivered in free software).
(Admittedly, there are moments when I half-wish for a nice quiet job where I'm not competing against the world's biggest tech companies and I don't have to worry about the future of the Internet. But that would be so boring. Having a job I'm passionate about is worth the stress.)
Comments
Mark.
[PS first comment here, but regular reader - remember you from ABC days. Still expat. Cheers]
The process separation model seems like a smart move and it will be interesting to see how well it plays with multi-core architectures. roc... you spent a lot of time on multithreading a single display engine, but this is a much simpler way of taking advantage of multicore.
As far as features... On its face it has some really nifty features. Specifically I love how the status bar appears only when there is status, and how the CTRL+F find bar is more featureful and even less intrusive than firefox's. Chrome gives the user more page real estate than any other browser I've seen.
But there are some things which clearly show its immaturity. Despite its multi-process magic its still noticeably slower than firefox. It doesn't have the nice history and bookmark sidebar that firefox has nor the separate downloads window. Its also a bit strange that it has its own vista-like UI theme.
And its buggy (but we can let that slide for now... its only been beta released for 48 hours).
Overall... this'll increase competition and will make guys like roc work harder which is good for us (but maybe not so good for you).
Chrome has the nicest logo!
(and tht is what matters! It's all in packaging!:) )
Ivan | www.JobsBlog.ie
> there are moments when I half-wish for a nice quiet job where I'm not competing against the world's biggest tech companies and I don't have to worry about the future of the Internet. But that would be so boring. Having a job I'm passionate about is worth the stress.
So true!
--Tristan
Peter: here are some issues I'm aware of:
-- Multiple processes rendering to a single window on Mac. There's no supported way to do that AFAIK. From your docs (great docs by the way!), it seems you don't have an answer there yet either.
-- Separate-process plugins rendering in windowless mode. I haven't had a chance to grovel through your code yet, but I didn't see anything in the docs about it. Sounds especially tricky in Chrome since, if I understand correctly, all interaction between the plugin and the page is routed through the master browser process.
-- Synchronous two-way script interaction between the page and a separate-process plugin seems like it's hard to make performant.
-- Running different-origin iframes in separate processes sounds hard; the interaction between iframes and their hosts is complex and bears on Web compatibility. (And the interaction gets more complicated with HTML5 "seamless" iframes.) But it really has to be solved, I think, because otherwise a compromised renderer process can violate the iframe security boundary --- a gaping hole in the security architecture.
Maybe the answer to some plugin problems is just to sandbox plugins and actually place them in the same process as the page. Sandboxing plugins is hard though, as you know. Acroread and Java spawn helper processes, for example, and I know Java is very firmly wedded to that approach. I suppose you can support limited subprocess spawning from the sandbox, but ugh.
Like I said, I'm not implying the Chrome design is flawed. The approach you've taken makes sense, it's just a really tough problem that you haven't reached the end of yet.
load some static svg image, then hit ctrl-+ a few times and see how long it takes to update when the image gets large. Try this one:
http://www.croczilla.com/svg/samples/tiger/tiger.svg
On my machine, just swag'ing it, I'd say chrome is 3x faster or more.
On the other hand, pages with embedded videos don't scroll very well in chrome as compared to FF3. Go to youtube, select any video, and while it is playing, scroll the window up and down. FF3 is pretty smooth, while chrome is choppy and the movement of the video window lags the movement of the rest of the web page.
I remember going to a VMWare info session a couple years back, they'd done VMotion or something, competition wasn't even discussed at any time, they were on cloud nine. I dropped by two more recent ones within the last year, and the tone (I think this was brought up in questions afterward) had markedly changed as they noted Parallels, XenSource, Microsoft, and possibly InnoTek. The same thing happened with OLPC as numerous competitors sprung up to do the same thing on cheaper, if possibly less principled and ambitious, systems. Mozilla's already faced competitors even beyond the elephant in the corner for a few years.
Markets without competition simply do not stay that way for long; I think the only exceptions would require direct government restriction of competition, very limited scale, or a very very low level of interestingness. I can't see most of the people I know being willing and able to settle for a job in a market which met any of these requirements.
Another option is in-house development. Most of it's deadly dull, IT for banks and such, but some of it's fun, like bespoke development for movie studios.
Plus, in the wider picture, I'm hoping it turns into the CLR for dynamic languages. The potential for languages like Ruby, Smalltalk, and the rest of the dynamic crowd is huge.
That is, to my mind, the piece of the Chrome announcement that is really exciting.
OK, V8 is still the fastest on their own hand-picked benchmarks. But I don't expect that to last for long; I'm sure both SFX and Tracemonkey developers are working furiously on improving performance on those benchmarks.
[One of the most annoying things about the Chrome launch marketing was the way Google said "V8 redefines Javascript performance! Everything else is crushed!" and the press said "Yeah!"]
Anyway, this race is really fun and great for the open Web. I'm optimistic about Tracemonkey's chances; I think trace compilation is great technology and a very good fit for JS.