Coffeehouse Thread

292 posts

Google Chrome, Google’s Open Source Browser Project

Back to Forum: Coffeehouse
  • brien

    Amen.

    I hate the fact that there are so many browsers out there.  Think about the billions of dollars wasted on multi-browser support.  Supporting various browsers is one of the biggest (if not the biggest) challenges developers face.

    This being said, maybe Google can help crush some of the other pesky browsers out there (e.g. FireGerbil).

    My main complaint with FireGerbil has always been it's lousy memory management (it's a leaky pig).  If each tab in the Google browser has "it's own memory and it's own copy of global data structures" doesn't that mean it's going to waste a ton of memory? 

    The reason the web is a beaf-cake is because most sites deliver crappy content.  IMHO technology companies need to focus more on delivering useful solutions and less on elegant technology.  Craigslist is a good example of this, Google used to be, but even their search page (well, results page) has bloated.

    For example, Silverlight is really cool, but so far that's all I've seen from it.  ...Cool things.  Not useful things.  ...Cool things get old and become boring, useful things are always appreciated.  ...And this really sucks, but I had a lot of problems getting Silverlight running.  Maybe that's because I originally had a Beta version, but that's no excuse.  Ditto for IE8 Beta 2.  ...I had to uninstall IE8 Beta 1 first?  ...Why couldn't my computer do that for me again?

    Honestly, after 20 years I'm started to dislike technology. 

  • eddwo

    I'm not yet entirely convinced this is all a good idea. Yes the separation into processes is good for resiliance in both IE8 and Chrome, but didn't we move to multithreading for a reason? Isn't there a whole load of overhead in managing separate process page tables, interprocess communication, etc. It seems like in both the IE and the Chrome teams have given up on the idea of actually being able to write really solid code that behaves itself, so are papering over the problem. On Windows the overhead per process is something like 1MB in bookkeeping state alone, imagine if you have 50 browser tabs going at once.
    If you have a virtual machine with garbage collection and you can relocate objects on the fly surely the problem of memory fragmentation goes away, if you can write your layout and rendering code in a safer environment than C++ then most of the chance of one rogue page taking down the whole process goes away.

    But I do think the comic strip is really excellent, it gives a very clear explanation of some quite complex issues so that most people could probably understand them.

  • jamie

    eddwo said:
    I'm not yet entirely convinced this is all a good idea. Yes the separation into processes is good for resiliance in both IE8 and Chrome, but didn't we move to multithreading for a reason? Isn't there a whole load of overhead in managing separate process page tables, interprocess communication, etc. It seems like in both the IE and the Chrome teams have given up on the idea of actually being able to write really solid code that behaves itself, so are papering over the problem. On Windows the overhead per process is something like 1MB in bookkeeping state alone, imagine if you have 50 browser tabs going at once.
    If you have a virtual machine with garbage collection and you can relocate objects on the fly surely the problem of memory fragmentation goes away, if you can write your layout and rendering code in a safer environment than C++ then most of the chance of one rogue page taking down the whole process goes away.

    But I do think the comic strip is really excellent, it gives a very clear explanation of some quite complex issues so that most people could probably understand them.

  • evildictait​or

    Given that Firefox and IE already do everything that they need to do, I can think of no good reason why Google thinks it'll get market penetration, other than by brand-whoring it's name on the product.

    Because of the laxness of HTML, websites will always render badly between websites unless a common standard is adopted; but unless that standard is enforced the browser hell will just continue.

    What needs to happen is to drop HTML and go to a new system; one with:
    * Vector based drawing and fixed positioning of elements (vector scaled up to the browser size)
    * Byte-code support instead of javascript to stop the rampant code-stealing on the internet as well as to allow higher speedups in VMs
    * Drop the concept of languages-in-languages. You shouldn't be allowed to set the style of something in HTML, Javascript, Visual Basic and CSS. It's ridiculous.
    * Reject bad pages. This stops the system being diluted.

    If you wanted, you could produce this and a dinky way of "converting" a HTML+JavaScript+CSS page to get consumer buy-in, but frankly the state that HTML is in today, it's a wonder anyone chooses to use it at all. People are tied into using cra.p browsers, cra.p languages and cra.p technology because there's no alternative. If Google sorted out that problem, that would be something.

  • evildictait​or

    kettch said:
    Bas said:
    *snip*

    The ability to launch web apps in windows without an address bar? Is that a good thing? Doesn't that open the user up to all kinds of phishing scenarios?

    Maybe. The rationale is quite simple though. When you run an application under Windows, you typically run it fullscreen. When you run Google App's spreadsheet/writer programs, you only get a bit of the screen because there's not only the toolbars for G-apps, but also the browser stuff at the top.

    If you could open the page fullscreen, then Google could get more screen real-estate for its apps, and make them more competitive.

    Further, if by owning the browser, Google can direct the development of the engine so that their apps can run with half the power of MS-Excel they'll be happy.

    Type "= 4 + 2" into Excel, it parses it quickly in native code to the string "6" and a structure in memory, and repaint the cell.
    Type "= 4 + 2" into Google, and it has to wrap it into Ajax, send it up to Google, parse it quickly in native code to the string "6", wrap it up in Ajax, send it down to the browser, unwrap it, modify the DOM in interpreted javascript and redraw the entire page.

    If Google can help "massage" the browser so that some of this computation can be done client side, and engineer in some ingenius way for the browser to give Google back some of the 50-90% slowdown that running anything in Firefox or IE will give you, Google might actaully stand a chance in the Apps market.

    Oh, and since Apps arn't free for companies, Google has money to make from this.

  • jamie

    somewhat off topic - but relevant...


    ok - the mac ads... 

    did you read that apple hired justin long?  and then read that they hired ..pc guy (john hodgman)

    then did you read about the main message? - before seeing it?

    i didnt.


    Out of the blue came the ad.


    why on earth does ms make a PR campaign - about something thats coming - thats supposed to be cool?


    you dont do it like that...

    cool = all of a sudden - wow.

    there is no pr lead up to cool

  • Sven Groot

    eddwo said:
    I'm not yet entirely convinced this is all a good idea. Yes the separation into processes is good for resiliance in both IE8 and Chrome, but didn't we move to multithreading for a reason? Isn't there a whole load of overhead in managing separate process page tables, interprocess communication, etc. It seems like in both the IE and the Chrome teams have given up on the idea of actually being able to write really solid code that behaves itself, so are papering over the problem. On Windows the overhead per process is something like 1MB in bookkeeping state alone, imagine if you have 50 browser tabs going at once.
    If you have a virtual machine with garbage collection and you can relocate objects on the fly surely the problem of memory fragmentation goes away, if you can write your layout and rendering code in a safer environment than C++ then most of the chance of one rogue page taking down the whole process goes away.

    But I do think the comic strip is really excellent, it gives a very clear explanation of some quite complex issues so that most people could probably understand them.
    Yes there is overhead but it's a good solution to a real problem. Even if the code is 100% perfect and will never crash, as long as you allow native plugins the way every browser currently does you cannot guarantee the browser won't crash. It might be Flash, or the JVM, or something equally beyond your control.

    I certainly love the way it only kills one tab when that happens in IE8, and then it restores that tab too. I'm willing to pay a little overhead for that.

  • Andre Da Costa

    Do no evil huh? Sounds like that oath has been thrown out the window. Time for world domination Google style. BTW, I don't want the porn sites I recently visited to be first thing I see when I open my browser. Bad move already.

  • evildictait​or

    Sven Groot said:
    eddwo said:
    *snip*
    Yes there is overhead but it's a good solution to a real problem. Even if the code is 100% perfect and will never crash, as long as you allow native plugins the way every browser currently does you cannot guarantee the browser won't crash. It might be Flash, or the JVM, or something equally beyond your control.

    I certainly love the way it only kills one tab when that happens in IE8, and then it restores that tab too. I'm willing to pay a little overhead for that.

    Yes there is overhead but it's a good solution to a real problem. Even if the code is 100% perfect and will never crash, as long as you allow native plugins the way every browser currently does you cannot guarantee the browser won't crash. It might be Flash, or the JVM, or something equally beyond your control.


    And therein lies the WTF.

    I don't let my customers write native plugins to my programs. I don't see why Microsoft feels the need. They have managed programs now that can crash safely - there's no excuse for letting native code run wild all over your program if you didn't code it yourself.

  • Sven Groot

    evildictaitor said:
    Sven Groot said:
    *snip*


    And therein lies the WTF.

    I don't let my customers write native plugins to my programs. I don't see why Microsoft feels the need. They have managed programs now that can crash safely - there's no excuse for letting native code run wild all over your program if you didn't code it yourself.
    So you're suggesting they close up IE to any native plugins, thus making all existing plugins (including Flash and Silverlight) completely useless?

    I'm sure everybody would really like that. </sarcasm>

    And if they do allow only managed plugins, it still wouldn't solve the problem. The CLR is not flawless, and it's impossible to completely prevent managed code from calling into native code (even if you put a sandbox on your plugin, those assemblies can call any assembly in the GAC which will be allowed to break the sandbox).

  • evildictait​or

    Sven Groot said:
    evildictaitor said:
    *snip*
    So you're suggesting they close up IE to any native plugins, thus making all existing plugins (including Flash and Silverlight) completely useless?

    I'm sure everybody would really like that. </sarcasm>

    And if they do allow only managed plugins, it still wouldn't solve the problem. The CLR is not flawless, and it's impossible to completely prevent managed code from calling into native code (even if you put a sandbox on your plugin, those assemblies can call any assembly in the GAC which will be allowed to break the sandbox).
    Well just a moment ago I was suggesting that they abolish HTML, which would be a whole lot less popular.

    You say that you can't sandbox the CLR, but that isn't true. Every unsafe function is marked in the header table of a CLR exe/dll, and thus a cursory glance over this by IE would be able to prevent unsafe code from executing.

    Even so, my experience has been that native code goes AWOL due to incompetence rather than malice (even in IE), and that most C# programmers have a strange and unwarranted, but none-the-less laudable and healthy unwillingness to touch unsafe code. Consequently if IE took the tack of saying IE8 will support CLR and native code for plugins, but IE9 won't support native plugins *hint, hint*, then I suspect they'd have less problems in future.

    PS. surely it would be trivial to move the Silverlight dll to a managed plugin? Flash would be harder mind you.

  • hordak3000

    Maybe it will go beyond the html browser? It may be displaying some sort of rich multimedia applications, powered by OpenGL, for example and more extensions down this road.
    By the way, chrome... chrome..., reminds me of the project chrome by Microsoft, DirectX for the Webbrowser which has been shot dead after Beta 2 in the late 90s.
    So will googles Webbrowser be just another webbrowser? Or are they planning more?

  • deanrd7

    How do you know what the world needs?

  • Sven Groot

    evildictaitor said:
    Sven Groot said:
    *snip*
    Well just a moment ago I was suggesting that they abolish HTML, which would be a whole lot less popular.

    You say that you can't sandbox the CLR, but that isn't true. Every unsafe function is marked in the header table of a CLR exe/dll, and thus a cursory glance over this by IE would be able to prevent unsafe code from executing.

    Even so, my experience has been that native code goes AWOL due to incompetence rather than malice (even in IE), and that most C# programmers have a strange and unwarranted, but none-the-less laudable and healthy unwillingness to touch unsafe code. Consequently if IE took the tack of saying IE8 will support CLR and native code for plugins, but IE9 won't support native plugins *hint, hint*, then I suspect they'd have less problems in future.

    PS. surely it would be trivial to move the Silverlight dll to a managed plugin? Flash would be harder mind you.
    You cannot fully sandbox the CLR. The core .Net libraries need to be able to call native code. The way the CLR deals with that is to allow assemblies in the GAC to call native code even when they are called from an untrusted assembly. All a plugin would need to do is install something in the GAC and then call that from the plugin's assembly.

    Remember we're not just talking about PInvoke here, but any interaction with native code, including PInvoke and COM interop.

  • Human​Compiler

    hordak3000 said:
    Maybe it will go beyond the html browser? It may be displaying some sort of rich multimedia applications, powered by OpenGL, for example and more extensions down this road.
    By the way, chrome... chrome..., reminds me of the project chrome by Microsoft, DirectX for the Webbrowser which has been shot dead after Beta 2 in the late 90s.
    So will googles Webbrowser be just another webbrowser? Or are they planning more?
    My parents (and all "general" users like them) could care less about how a web browser works.  Or how plug-ins work.  Or how much memory each page is taking up.  Or how many milliseconds faster the page renders.  I completely agree with the first few pages (the general idea that browsers weren't designed for what they do today) of the comic, but after that I get confused.  Why would people other than developers care about any of this?  Ask someone you know who isn't a developer what they think about the idea.  Perplexed

  • La Bomba

    Are you automatically included in the beta if you download it?

  • Zeus

    HumanCompiler said:
    hordak3000 said:
    *snip*
    My parents (and all "general" users like them) could care less about how a web browser works.  Or how plug-ins work.  Or how much memory each page is taking up.  Or how many milliseconds faster the page renders.  I completely agree with the first few pages (the general idea that browsers weren't designed for what they do today) of the comic, but after that I get confused.  Why would people other than developers care about any of this?  Ask someone you know who isn't a developer what they think about the idea.  Perplexed
    Absolutely agree, people could care less on how the application works, and that is true for all the software we here develop, weather it's a win32 app, or a web application.

    It just has to work ...

    C9 is a very special exception, because the users of this application are developer themselves, and DO care about how it works, and how it is built.

    Am pretty excited about this Google browser though, like the idea of having the tabs right at the top, and this V8 thing should rock if it lives up to the comic.

  • kettch

    Zeus said:
    HumanCompiler said:
    *snip*
    Absolutely agree, people could care less on how the application works, and that is true for all the software we here develop, weather it's a win32 app, or a web application.

    It just has to work ...

    C9 is a very special exception, because the users of this application are developer themselves, and DO care about how it works, and how it is built.

    Am pretty excited about this Google browser though, like the idea of having the tabs right at the top, and this V8 thing should rock if it lives up to the comic.
    After I saw the screenshots of the tabs on top, I started paying attention to how I use tabs in normal day-to-day use (heisenburg anyone?). It seems that I prefer my tabs as close to the content as possible. When I am looking through my tabs, and switching between them, I don't care about the address or any of the functions. I just want to switch between content.

    Ideally somebody should allow the tab bar (and the rest of the top-level UI components) to be moved around wherever. Top, bottom, left, right, whatever. Ultimately, usability for a browser comes down to letting the user customize the UI to their workflow and preferences. All within reason, of course.

    However, I think that customization is only going to work for the relatively small number of options that something like a browser exposes to the user. As the complexity of the app increases, the value of having a well designed and rigid UI is going to become more important.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.