Thursday, 4 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.)



17 comments:

  1. Yeah I'd love to try Chrome. Agree it sounds interesting - but hey, I'm a busy guy. They want me to read a 6.5 page Terms of Service agreement (cf 1.5 page for the FF EULA)? Yeah, right.
    Mark.
    [PS first comment here, but regular reader - remember you from ABC days. Still expat. Cheers]

    ReplyDelete
  2. So, out of curiosity, which architectural problems haven't we solved yet? Perhaps we've solved a few :)

    ReplyDelete
  3. I've been using chrome for about a day now.
    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).

    ReplyDelete
  4. I was excited till it was flooded in news pages, had like 50+ rss items about chrome today...

    ReplyDelete
  5. Speed, license, security,... blah, blah, blah!!!
    Chrome has the nicest logo!
    (and tht is what matters! It's all in packaging!:) )
    Ivan | www.JobsBlog.ie

    ReplyDelete
  6. I nodded all the way through your post, but this has really been ringing a bell:
    > 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

    ReplyDelete
  7. Robert O'Callahan4 September 2008 21:03

    Hi Mark!
    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.

    ReplyDelete
  8. I have to say SVG rendering is a multiple faster on chrome than firefox 3.0, at least for large images. I dunno if google worked some magic or if webkit provides the goodness.
    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.

    ReplyDelete
  9. Robert O'Callahan5 September 2008 09:21

    That's probably Skia's path rasterization performing better than cairo's. That's something we can look into.

    ReplyDelete
  10. Regarding that last paragraph, I don't think such a thing exists.
    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.

    ReplyDelete
  11. Robert O'Callahan5 September 2008 12:18

    There are a lot of tech jobs that don't involve head-to-head product competition. Some of them are even quite interesting --- academic/industrial research, for example, which I have done. It's competitive, but nothing like this.
    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.

    ReplyDelete
  12. Early stats are showing that chrome is penetrating into the Mozilla and Opera market. It's already hopped to 1% penetration but maybe that's for web developer geeks. Anyhow, I see big things for Google Chrome.

    ReplyDelete
  13. The real news is *who* is leading the V8 development - Lars Bak. And there are other members of the original Strongtalk team in the too. Strongtalk and the Hotspot Java VM are some track record to bring to the table - I'm expecting truly great things from their Javascript implementation.

    ReplyDelete
  14. The real news is *who* is leading the V8 development - Lars Bak. And there are other members of the original Strongtalk team in the too. Strongtalk and the Hotspot Java VM are some track record to bring to the table - I'm expecting truly great things from their VM.
    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.

    ReplyDelete
  15. Robert O'Callahan8 September 2008 09:57

    Actually, V8 is by far the weakest part of the Chrome story. Last night "Squirrelfish Extreme" landed in Webkit trunk, and today V8 is the third fastest JS engine on the Sunspider benchmark, behind Tracemonkey and SFX. (Sunspider is the standard benchmark that Opera, Webkit and Mozilla have been using for a while now.)
    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.

    ReplyDelete
  16. +1 for politically correctedness (is that even a word!)

    ReplyDelete