<div><div class="gmail_quote">On 22 March 2010 00:12, Benjamin M. Schwartz <span dir="ltr"><<a href="mailto:bmschwar@fas.harvard.edu">bmschwar@fas.harvard.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im">Lucian Branescu wrote:<br> > I am inclined to choose the second for a few reasons. First, current webkit<br> > is much faster and uses less memory than current gecko, which has been<br> > especially visible on XOs.<br> <br> </div>I'm not willing to accept this as proven. As for faster, see<br> <a href="http://weblogs.mozillazine.org/bz/archives/020434.html" target="_blank">http://weblogs.mozillazine.org/bz/archives/020434.html</a><br> <br> As for memory usage, see<br> <a href="http://dotnetperls.com/chrome-memory" target="_blank">http://dotnetperls.com/chrome-memory</a></blockquote><div>Of course Chrome usage is much higher. Chrome has at least one process for each tab.</div><div>Safari is also a wreck, especially on Windows.</div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br> <br> Webkit may be faster (although... with which javascript engine? on what<br> graphics hardware? with which bookmarks/awesomebar system?) but I don't<br> think it's so obvious. Previous comparisons on the XO have been deeply<br> flawed because Gecko was scaling up all fonts and images, while Webkit was<br> not.</blockquote>The test I have done both on OS X and soas have shown webkit to be far superior in execution speed and still superior in memory usage for benchmarks. These weren't entirely relevant, so I will do another set of benchmarks that are more relevant to XO usage (with firefox 3.6).<div> <br></div><div>Here are my old results:</div><div><a href="http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20osx.txt">http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20osx.txt</a></div><div><a href="http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20soas.txt">http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20soas.txt</a></div> <div><a href="http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20winxp.txt">http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20winxp.txt</a> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im"><br> > While gecko has superior extendability (XUL<br> > extensions), Browse isn't compatible with Firefox extensions, so anything<br> > would need to be rewritten anyway. Userscripts (Greasemonkey) serve most<br> > needs for now and if needed, an extension API akin to Mozilla's Jetpack or<br> > Chrome's extensions could be implemented.<br> <br> </div>This sounds like an argument for staying with Gecko and adopting<br> Greasemonkey and Jetpack.<br></blockquote><div>It's an argument for not really needing Gecko. Both could be implemented on Webkit. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im"><br> > Second, webkit is being used by a lot of projects and has the backing of<br> > several companies.<br> <br> </div>Gecko is far more widely deployed (~30% of all internet users).<br></blockquote><div>The arguments other people have given to me have to do with how many projects use it (maintained by many companies/communities).</div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im"><br> > Furthermore, it is packaged more consistently across<br> > platforms/distributions.<br> <br> </div>I'm not sure what this means, but it doesn't seem critical.<br></blockquote><div>Xulrunner tends to have many patches applied by distros. Webkit doesn't. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im"><br> > Third, pywebkitgtk and hulahop have a similar API (and pywebkitgtk tries not<br> > to diverge unless necessary) and it should be possible to not depend too<br> > much on any one of them. A thin abstraction layer could be written on top to<br> > handle most differences and it should only rarely be needed to go beneath<br> > this abstraction. While this would most likely not result in a browser than<br> > can switch engines at runtime, it should make any future porting much<br> > easier.<br> <br> </div>I'm certainly not going to complain about an abstraction layer of this<br> sort. As I've said before, I think a lot of developers would enjoy an<br> "engine-agnostic" browser widget.<br> <br> --Ben<br> <br> </blockquote></div><br></div>