Submitted by The WebKit team is currently busy, integrating the patches made for Google
Chrome into the main WebKit repository. This includes the new V8 JavaScript engine and the Skia graphics library. Most integration work is done by Google employee and WebKit reviewer Eric Seidel. V8 is a fast, BSD licensed JavaScript engine that runs on 32bit x86 and ARM CPUs.
Due that platform restriction, V8 probably won’t replace WebKit’s new SquirrelFish engine anytime soon as default, because SquirrelFish has broader CPU architecture support. Epiphany developer and WebKit reviewer Alp Toker gives an overview about Skia. Unlike V8, Skia is licensed under the Apache License 2.0. Some of Skia’s main features are optional OpenGL-based acceleration, thread-safety, 10,000 less lines of code compared to Cairo, and high portability.
Excellent. I love open source
“me 2”
It’ll be interesting to see if Skia shows any advantages over Cairo.
It has been shown that 2D drawing using current OpenGL implementations, although fast, create results which generally aren’t very high quality or even consistent across OpenGL capable drivers and/or hardware.
Also, although I haven’t checked, I thought Cairo was already thread-safe to the degree that two threads can operate on two different surfaces simultaneously?
As for code size, I don’t see the point of comparing it. Cairo is a *mature* API and ABI stable *library* and shouldn’t be imported into the Chrome tree anyway. The app should be using the system Cairo library, which will certainly be present on most modern Linux/Free desktops or installed automatically by your package manager.
Edited 2008-09-06 20:38 UTC
Do you mean “app” as in Chrome or “app” as in WebKit? Cairo might be available on Linux or *BSD, but on other platforms frankly it’s a huge pain in the backside to port and maintain, and I’d rather do without it.
Thankfully WebKit is nicely abstracted so it’s not something I have to worry about: I won’t have to use Cairo or Skia if I don’t want too.
I meant Chrome, because Webkit isn’t an app.
Cairo has been ‘ported’ to Windows too, it has a solid Windows GDI back-end, and there are semi-official binaries for Windows on GNOME.org and at a few other sites.
And yes, Webkit is ‘nicely abstracted’ alright, except Cairo and Skia are already abstractions on other libraries such as various X libs/capabilities, GDI, SDL, OpenGL etc. Skia is being pulled into the WebKit tree, WebKit is being pulled into the Qt 4.4(?) tree as well into the GNOME desktop codebase for use in Epiphany’s Webkit back-end. Both the GNOME and Qt/KDE platforms already have their own designated drawing libraries, Arthur and Cairo.
Just what is going on here? Why another drawing library?
It looks like Skia SGL was an acquisition: http://opengardensblog.futuretext.com/archives/2007/03/the_real_goo…
It seems to me that Skia SGL has little to do with ‘competing’ with Cairo on the desktop and more to with maybe getting Google’s foot stuck further in the door with Opera on mobile devices.
Edited 2008-09-06 21:42 UTC
Yes, and that makes a lot of sense from Googles perspective. Cairo is overkill on a mobile device, so Skia appears to be their answer to that.
Calling Cairo an abstraction to underlying graphics is not very accurate except maybe for X. It’s more of a ‘tail wagging the dog’ kind of thing.
Agreed. Cairo’s code and project structure is among the worst I’ve seen so far.
I wonder if this is in current nightlies. Webkit nightlies are so much fun to play with.
I thought the word “nightly” and its variants were Mozilla Corp. trademarks. 😛
There are most certainly not.
http://nightly.webkit.org
According to Alp Toker’s post Skia is — at least partially — available in WebKit’s SVN. I don’t know if the official nightlies support it, though.
V8 is currently missing: https://bugs.webkit.org/show_bug.cgi?id=20619
Edited 2008-09-07 01:49 UTC
Indeed.
WebKit is my favorite rendering enigne. So much fun experimental CSS-stuff to play with.
Does anybody have a clue how much effort would it take to port V8 to the x64 arch.?
i dont know, first the x64 arch would have to actually exist, then we can talk about issues involved in porting to it.
were you talking about x86_64 ?
x64 is a commonly recognized abbreviation: http://en.wikipedia.org/wiki/X64
You also do not write “etcetera” — do you?
HTH
I’m actually a proponent of the x32 and x64 terms. They may not have so much of a historical relevance, but anyone with more than about 3 braincells can work out what each one means.
I’m a proponent of shooting humans. What’s your point?
Changing the terms to something not commonly used serves no real purpose and for no meaningful gain. Anyone can figure out the commonly used terms if they had 3 brain cells.. but that is the problem. So many people do not seem to have 3 brain cells.
Edited 2008-09-08 12:12 UTC
You’re right, using your logic. We should all ignore the [originally uncommon] term x86 and revert to ‘80386 compatible instruction set’.
x86 makes sense, x64 makes no sense, and x32 makes less then no sense. I always thought the whole x86_64 thing was pretty dumb too, since we didn’t have an x86_16 or x86_32. How hard is it to say 64bit x86?
Does it matter?
Not terribly, but I have never been a fan of marketing dept. inspired naming/versioning of tech products.
Stuff like windows 2000 vs windows millenium edition, or the 5 major revisions of OSX, or stuff like this. The goal of ME was to create an exciting name, but ended up conflicting with the previous “convention” of versioning by year. OSX was a rebranding of Mac OS, and went from meaning something (os 10) to meaning nothing (os X, version 10.5). x86_64 was done so as to reassure people that they were still getting x86 compatible chips, although it is pretty obvious to anyone who would ever really need to know what x86_64 means anyways.
All that stuff ends up doing is being non descriptive for no good reason, and confusing the crap out of laymen who want to understand what the names mean. There are alot of people who still use win2k and winME interchangably, think that OSX means something other then an arbitrary three letters chosen from the alphabet, and that since x64 means 64-bit, that x86 must mean 86-bit.
Actually, x86_64 makes a lot of sense to me. x86 with 64 bit extensions, which is essentially what it is. x86_32 is less used. x86 is the more commonly used term. x86 and x86_64 seem like a pretty logical combo.
if any effort at all…actually, if v8 is Leopard Mac OS X compatible, than, given that Leopard is only 64 bit (x86_64)…
I find quite strange the assumption of linking vs 32 bit libraries (see the issues on v8 site).
I find it strange that people say Leopard is 64-bit only, as I run it very well on my 32-bit Macbook first-gen Macbook…
they are stupid
They’re actually not that far wrong.
On Tiger, the entire OS was shipped as fat binaries, containing code for PowerPC and x86. On Leopard, those fat binaries also contain code for 64-bit PowerPC, and x86-64.
If you have a 64-bit capable CPU (like the newer Core 2 Macbooks), Leopard itself will use the x86-64 versions of everything, so it’ll be a fully 64-bit OS. Which can also run 32-bit applications.
Not entirely true. The only release of Tiger that was Universal, was a later version of Mac OS X Server: http://www.youtube.com/watch?v=8TjRyalqlJs
Not every Leopard app is 64 bit. That should be the case with Snow Leopard.
Is this where Apple and Google will diverge?
Is there any particular reason why one is better than the other?
V8 was not least developed for Android. I assume, it consumes less resources and is therefore better suitable to run rich content apps on mobile devices. Google wants more mobile market share!
In the foreseeable future: yes. Apple obviously wants a JavaScript engine that’s also compatible with PowerPC and x86-64. This should also be true for Nokia/Trolltech (QtWebKit) and GNOME (GTKWebKit/Epiphany)
I also don’t think that Apple wants to ship two different JS engines based on the device (eg. V8 on iPhone) because 100% compatibility between Safari for Mac/Win and Mobile Safari can’t be guarantied.
I think that overall SquirrelFish is newer — the first public “outing” was just earlier. Thus SquirrelFish is less optimized. So far V8 seems to perform better on platforms it supports.
How long has SquirrelFish been in use?
i have been using it every day since it was introduced to nightlys
June 08: http://webkit.org/blog/189/announcing-squirrelfish/
There is no way in hell they [Apple] drops this project for V8. Nor will they not use OpenGL for OS X.
I agree that V8 will most likely not make its way into Safari, but I disagree that Apple would rule out an OpenGL pathway for webkit rendering. From my understanding, Quartz GL can handle many of the final rendering passes in Safari (if enabled.) Apple has, over the years, been offloading more and more portions of the display pipline to the graphics card via OpenGL. If they can reasonably add another layer, they might.
EDIT: Actually, rereading your post, I can’t figure out what your trying to say about OpenGL.
Edited 2008-09-07 07:22 UTC
Why not? Currently V8 is not compatible with PowerPC Macs and x86-64, but once V8 is compatible with the architectures needed for Apple why shouldn’t Apple use the technically better solution? If V8 is still faster then, then Apple will use it.
Huh? Apple already uses its own Quartz backend for WebKit on Mac/iPhone OS X. Quartz is OpenGL accelerated since years. Skia offers no advantage for Apple.
available for Linux/BSD/Solaris/Syllable? I would also like to ask if Chome will support Mingw and or Cygwin. FF3 does not support it anymore.
Interesting is also what is Mozilla is going to do as all bigger companies (Nokia, Google, Apple) are going to use WebKit and JS engines related to this rendering engine. Also Apple’s Safari and Google’s Chrome are really strong Firefox competitors. Would it make sense for Mozilla to switch to WebKit. In fact Firefox is basically its rendering engine Gecko. If you replace Gecko by WebKit you have just the ugly FF GUI. I doubt if there is a future for Mozilla. At least their market share will follow the current stock market: Downstairs.
Unlikely, to say the least.
Webkit is nowhere near as mature as Gecko is. Webkit has some distinct advantages, not the least of which is size, which make it competitive with Gecko. Gecko and Webkit were written in two very different epochs- and their differences show this. Mozilla, which uses Gecko for rendering, is the child of Netscape, and the ecosystem of libraries which constitute Mozilla represents far, far more than Webkit.
Netscape, and hence Mozilla, were targeted at middleware-ie. a platform for software development which was transparent across operating systems and hardware archictecture. The sheer magnitude of this undertaking (code and complexity) has been a difficulty for the modern Firefox and attempts to bring this tech to mobile devices.
Firefox, as a project, was the first attempt to really streamline the legacy of Mozilla, and to isolate some subset of tech’s available to make a lean and powerful browser. Currently work is ongoing to streamline Mozilla even more to make it competitve in the mobile space.
Gecko was written within and for the ecosystem of Mozilla libraries-which from the vantage point of those using these libraries is a tremendous plus, but a disadvantage for those wishing to wrap Gecko in foregin UI’s. Which is almost the exact opposite of Webkit- Webkit was designed in such a way that it is far easier to embed, far easier to wrap in other languages. XPCOM provides accessibility to Gecko via other languages, and of course Mozilla has been working on providing Gecko in such a way that it can be used outside of the Mozilla ecosystem-yet this work has been slow in the coming(ask the Galeon/epiphany devs), and I think there are many reasons for this.
One of the reasons is that Gecko alone is not all that interesting or valuable-it’s value lies in it’s integration with other Mozilla tech’s(XUL, XPCOM, etc.), whereas Webkit is *merely* a renderer in the first instance. Apple took KHTML to create Webkit, partialy because it was very little work to seperate the rendering part from the GUI parts of the code. Then they wrapped this part in objective-c (Cocoa- Mac users correct me if I am wrong), then Trolltech retook the code and wrapped it in QT, embedding it in QT itself. Then others started wrapping it- ie. GTK.
Webkit, which started out from a tiny code base has blossomed into something that is beginning to grow as large as what Mozilla was 10 years ago. Luckily for Webkit it’s design makes it simply to adapt, but only because it never attempted to be everything to everyone which Mozilla was from it’s inception.
From a dev perspective Webkit offers a lot of advantages over Gecko. But as a user I still far prefer Gecko over anything else. In much the same way I prefer Firefox over any of it’s competitors-Safari has no appeal to me(even if it did run under Linux), neither does Konqueror-as a browser, nor Epiphany. The existence of these other browsers however is something I am very thankful for- they increase the presence of certain standards, they decrease the relevance of IE, and they are a healthy ground for competion-which makes the Web a better place. Webkit is having a huge success right now in the mobile space- this is because the developers are right now creating platforms for these devices. Mozilla, of which Gecko is a part, is already and tremedously powerful platform, unfortunately one not written for tiny computers which simply did not exist when it was written.
And remember Chrome is not simply *using* Webkit, they significantly changed Webkit for V8, even in their comic they talk about how they started with only 23% compatibility with stock Webkit-they say they are now 99% compatible-but that only shows how much hacking they did on Webkit/V8. How many projects/devs are willing to put that time and effort into making Webkit fit their needs? That speaks volumes against the *ease* of Webkit integration.
That’s funny. Essentially the only project that uses Gekco is Firefox and everyone under the sun is using WebKit. That speaks volumes about how bad Gecko is from a developers perspective. Also the fact that a very large number of developers for Apple, Google and other companies/projects are ex-Firefox developers and they all think WebKit is better in every aspect. WebKit was also the first HTML rendering engine to have full support for ACID2/ACID3 and the best draft HTML5 support. Firefox/Gecko is a complete disaster. It is just another example of people using the “most popular” piece of software but it does nt mean it is good at all.
Think again. There are quite a few projects that employ Gecko. Try looking and see how many programs use xulrunner. (That’s basically the standalone Gecko library)
Remember, Gecko is much more than just an HTML rendering engine. It’s a development platform. Some apps that employ it may have very little in common with a web browser. Take Miro for instance, or SongBird.
Characterizing Gecko as a “disaster” sounds too much like a WebKit fanatic with little insight. WebKit is very good, and improving, and perfect for handheld architectures. But don’t write off Gecko. It has it’s own advantages in certain areas over Webkit as well. Especially in dealing with XML based technologies for web applications.
From a development perspective he has a point. There is very much programming going on in the preprocessor and platform specific code is found everywhere even in the javascript-code. Unfortunatly the people working on development only seem to add to this mess rather than trying to clean it up. The mozilla-code is in need of a huge refactoring to be attractive to anyone.
For instance this header (71k) really should be divided to platform specific ones instead of preprocessor programming:
http://mxr.mozilla.org/mozilla/source/nsprpub/pr/include/private/pr…
Let me say that you are a troll. WebKit and Gecko have a different focus (as you laid out) but WebKit is not immature. If it was immature, Adobe, Google, Apple, Nokia, etc. wouldn’t use it.
Aw, another lie. V8 is a separate project. As Eric Seidel (Chrome developer) said himself in WebKit’s Tracker: “[V8 integration] is going to require a small number of source changes”. To integrate that separate project, just the build system was modified in a larger way.
See https://bugs.webkit.org/show_bug.cgi?id=20619
To quote one of the linked articles:
Wow, you have a propensity to misunderstand things don’t you?
lol calling me a troll, do you know the old adage, “it takes one to know one”.
Firstly I said that Gecko was far more mature than Webkit- I did not say that Webkit is immature. Gecko is the result of almost 15 years of fine tuning for millions of web pages. Webkit is very young in contrast-being perhaps 3-4 years old at the most.
Secondly I did not lie. Although I am no expert in either the Webkit or Chromes code base it seems obvious to me from the comic published by Google that they must have made rather significant changes to the Webkit code. According to that comic when they first started to use Webkit they were only getting 23% compatibility-ie. only 23% of the pages rendered like they normally would with Webkit. Now they claim to have 99% compatibility. I of course cannot explain to you exactly what changes needed to be made- but it seems obvious that both V8 and Webkit needed to be modified to work correctly together to get correct rendering.
As i stated repeatedly in my post, Webkit does offer advantages to devs- it is far easier to integrate with other software, due in large part to it’s modular design, and to a smaller degree due to it’s relative lack of complexity in contrast to Gecko.
I have nothing against Webkit. I have used applications built with Webkit(epiphany, yelp and others). But IMNSHO Webkit is not as mature as Gecko/Mozilla and I prefer to use Mozilla for my web browsing needs.
Practice your reading comprehension skills before you go around calling others trolls.
Where do you get those dates from? KHTML/WebKit is at least as old as Gecko.
For WebKit to render correctly the platform implementation must be complete, as it necessarily implements a lot of the low-level rendering code. Things like rounded corners, gradient fills etc. are all platform-specific. If you’re starting with a new port you’ll find that page rendering is not comparable to existing ports. It is likely that all Google mean by their comic is that their WebKit/Skia combination started out as a basic skeleton and was developed until it matched 99% of the functionality in the other platforms.
Replacing JavaScriptCore/SquirelFish with V8 didn’t require any major changes to the rendering engine either, as the two are nice and cleanly defined within the source tree.
Well KHTML did not exist when Gecko was first released. According to wikipedia KHTML was first released in 1998. But it should be noted that KHTML did not see much in the way of significant usage until Apple took the source and created Webkit, prior to Webkit, Konqueror was the only notable browser using this code.
What this means concretely is that very few people actually used it for their browsing needs for most of it’s history, perhaps today there are 1-2 million Konqueror users, although I doubt it. Which consequently means that KHTML was not exposed to the breadth and width of existing web pages. I cannot offer you empirical statistics as to it’s usage back then but it was only available on Linux and the *BSD’s and only a fraction of those users used KDE and only a fraction of KDE users used Konqueror as their primary browser-realistically we are talking about a couple hundred thousand users-in contrast to Safari, based, on Webkit, which certainly has several million users, which is still less than a 1/3 of the number of Mozilla users.
I downloaded the source code for Gecko in 1997. Webkit was first released in 2003. By the time Safari was released Firefox had in excess 10,000,000 users.
My point in all of this is that Webkit/KHTML is simply not as mature as Gecko. This does not mean that Webkit/KHTML is a *bad* renderer. Now that Webkit is getting the kind of uptake that it is it is rapidly approaching compatibility with the existing web pages which Gecko has, due in part to improvements in Webkit, and due in part to new web pages being designed in such a way as to correctly render with Webkit.
As I already stated I am no expert in either Webkit or Chrome code bases. Yet I find it unlikely that the discrepancy between 23% and 99% of web pages being correctly rendered can be attributed to low level integration issues with skia, but I will not pursue this point further other than stating a couple of things
1) epiphany which uses the GTK Webkit port renders pages almost identically to Safari. The epiphany devs are building on the work of the Nokia GTK Webkit port- not sure how long Nokia worked on that port but they have been working on it for at least 2 years in connection with the maemo device.
2) again if devs have to spend 1-2 years to port Webkit to support a new GUI/toolkit(GTK, Skia, etc), this does not make a good argument for the ease of use of Webkit-sure once that work is done it may be amazingly easy to integrate, but I bet the work to port Webkit to a new or different toolkit is about the same amount of work to port Mozilla to a different platform.
I will leave this spat to the better informed
It is pretty sad when one gets attacked for pointing out the relative difference in maturity between Webkit and Gecko.
Yes, and the Syllable port does not render exactly the same as Safari: Acid 2 does not render correctly, for example, neither do normal web pages like OSNews or Slashdot. This is almost entirely due to missing platform support.
Not even close. Having investigated both, and having worked with WebKit, I can honestly say that WebKit is much, much easier to port than Gecko. The number of ports for WebKit compared to Gecko underlines this neatly.
I’m not attacking you and this is not a spat: I’m providing my informed opinion on WebKit (In case you weren’t aware I maintain the out-of-tree Syllable port these days)
Lol, hey there Vanders…didn’t notice it was you
Damnit there I go picking an argument with someone who has a hell of lot of more programming experience than I do
The Netscape 5 source code was released in 1998, so was KHTML. However, both projects built on older code. Yes, if you trace back Netscape’s heritage back to Mosaic from 1994 then you are right: It’s about 4 years older. BUT! During the development of Mozilla, the Netscape 5 source code was completely scrapped. Netscape 5 was not Gecko… not even remotely. Only a few graphics survived the rewrite (the Classic theme and one or two mouse cursors).
While WebKit has probably not much in common with KHTML from 1998, AFAIK there was no “Aw, f*#k everything. We start from scratch.” kind of moment. So yeah, WebKit is older.
Webkit was the core library for Safari, released as a beta 5 years ago (which means it had at least 6 years of development at Apple). Initially it was a simple wrapper around KHTML/KJS, which had been developed in anger since 1999, which makes for nine years of development.
Gecko’s development started in 1997, after Netscape acquired the IP, giving 11 years of development, but development was infamously rebooted in 1999. So Gecko is exactly one year older than Webkit. Until recently, of course, the difference in developers meant Gecko supported more sites, but Webkit has more than made up the difference in the last two years.
You don’t seem to know much about coding at all.. Webkit is a component in an overall application.
The Webkit component saw little change, other than hooks to allow a new JS engine to be plugged in, and the Skia library to be used. Webkit, being a redistributable layout engine, always made it easy to change drawing technologies, so none of this was particularly invasive. The work Google undertook was in the design of the overall application utilising the Webkit component.
They went from passing 23% of their layout tests to 99% of them. This is not the same as saying 23% of sites failed to render (no-one would have ever considered if Webkit was that bad). What it means is they identified the layout designs most likely to stress the layout engine. Pages which failed probably used a combination of these.
Webkit needed to be modified to support a new JS engine, and they fixed bugs in its layout, but existing performance on Safari shows that changes were incremental (though keeping in mind the usual 80/20 rule)
I’d be interested to know if you prefer the layout engines (Webkit versus Gecko) or the browsers (Epiphany versus Firefox). My experience has been that even KHTML is faster and more lightweight than Gecko, though it suffers as it does not have all the compatibility fixes Apple (and now Google) contributed to Webkit.
Likewise it may help you to check your facts on Wikipedia before lecturing those around you. The 15 versus 3/4 years development comparison was a pretty poor mistake.
Erhm, KHTML started in 1999, Gecko was re-started in 1999, yet Gecko is exactly one year older? I’m missing some simple math in there.
KHTML had no significant user base until Apple ported KHTML to create Webkit. Prior to Webkit the only notable browser based on KHTML was Konqueror which had a usage base in the few hundred thousands. The practical upshot of such a small user base is that KHTML, as used in Konqueror, had severe rendering problems with very large number of web pages- the lack of users equated to the lack of exposure of the KHTML renderer to the breadth and width of existing web pages. I used it on occassion back then and found it more than wanting. The first Webkit beta was released in 2003. At that time there were already several million people using Mozilla/Firefox. Only in 2004 did Webkit start counting a user base in the millions, yet it was still only a tiny fraction of the number of users using Firefox.
The real test for the maturity of a rendering engine is not merely the number of years since the algorithms were written. That test lies in being used by large numbers of people, being relied upon day in and day out, and which is exposed to the hundreds of millions of existing web pages, and which is adapted over time to meet the needs of it’s users. Perhaps you disagree with what I mean when I talk about the relative maturity of the different rendering engines. But at no point in it’s history did KHTML have a user base comparable to Gecko, with perhaps the exception of the 1 year following the rewrite. And only in the past *4 years* has Webkit been comparable, in terms of actual usage, to Gecko.
Gecko is, as I already stated, simply more mature than Webkit/KHTML. This point has been substantiated and no amount of historical dating via wikipedia will change this. You are free to disagree. This difference in relative maturity will likely change with the large number of smaller computing devices using Webkit based browsers and the probable success of Chrome. Another poster followed up on your post stating that Webkit is older than Gecko, nice historical revisionism at work.
As to my personal impressions of Webkit. I too was drawn to Webkit by virtue of it’s smaller foot print and speed. I compile all of the software I use on my machine and the software I use, GNOME, has many components which make use of a rendering library (Yelp, Devhelp, Epiphany/Galeon, etc.).
For many years yelp and devhelp were built with gtkhtml, a tiny renderer which was at once horribly limited and extremely slow. Epiphany and Galeon were built against Gecko-Galeon was my prefered browser for a couple of years, Epiphany never appealed to me at all. About 2 years ago the GNOME devs decided to abandon Gtkhtml and started building Yelp and Devhelp against Gecko. This lead to both of these apps becoming quite bloated-huge memory foot print and heavy CPU usage. About 6 months ago GNOME devs decided to take advantage of the Nokia led GTK-Webkit port.
Being curious, as I am, I downloaded Webkit and built it and built Yelp, Devhelp and Epiphany against the Webkit. Webkit based Yelp and Devhelp are wonderful-quickly rendering with a light foot print. Epiphany using Webkit is still extremely crippled- one cannot use any plugins (flash etc.)-I know that work is ongoing to get the nsplugin api working, but it does not yet work for me- and the UI has still not been migrated over to the new Webkit base(lots of things in the UI are still not functional).
Konqueror is and remains for me a browser of last resort, although, that being said, the new versions of Konqueror built against QT4.4, which makes use of more recent Webkit code, has improved dramatically. I look forward to playing with it more once QT4.5 is released.
I look forward to a mature Webkit based Epiphany-which hopefully will be usable by GNOME 2.26,and I will probably use the KDE4/QT4 Konqueror as a fall back browser in the next months. At this point I still view Webkit as a lightweight renderer-it has a myriad of uses in a lot of apps for HTML rendering, and I would love to see GNOME completely abandon Gtkhtml and use Webkit internally for all of it’s web rendering needs.
However I remain a loyal Mozilla user, I started using Netscape in 1994, I downloaded the code to Mozilla the day it was released in 1998-not because I am a great programmer but because I was fascinated by the release of the code, and I used Mozilla as my broswer long before the 1.0 release, and then Phoenix, Firebird and finally Firefox, and even today I still use SeaMonkey. Maybe someday a nice GNOME Webkit based browser will motivate me to turn against my beloved Mozilla,but it being lightweight is not enough to change my habits, and on my machine the speed differences are simple not perceptible.
I already discussed this issue with Vanders- I will take his word concerning how easy it is to port/integrate Webkit. He assures me that it is much easier to use from a dev perspective.
My own perspective is perhaps difficult for devs to grasp. I am not a dev, I am firstly a user, but since I am constantly compiling software(which often means hacking ./configure/Makefiles and the code itself), I have a degree of exposure to the actual code which most users do not have- I am somewhere in between a dev and a user, not unlike those who create and maintain distributions. I am familiar with the design and structure of the code in Webkit, I can see it’s advantages for devs, but my interest in it’s design is limited by it’s practical import to me as a user.
I honestly have no knowledge of what Google devs did when creating Chrome-other that what they told me in their comic depicting the creation of Chrome. Honestly much of that which I have read regarding Webkit is contradictory and confusing. I know that prior to the Nokia led Webkit port that one man, whose name I have foregotten, had already created an initial port of Webkit for Linux/Gtk. I also read that another GNOME dev had done a lot of work porting Webkit to GTK prior to Nokia’s efforts. Apparently only with Nokia’s Webkit GTK port did Webkit become really visible on the GNOME radar. I assume this is due to the quality of the wrapping.
When I read that Google initally only passed 23% of their layout tests and how they worked to get it up to 99%, I was somewhat baffle. I doubt there is anywhere near that kind of difference between Safari, Konqueror(QT4) and the GTK-Webkit based Epiphany. So I asked myself what was so special about Chrome- sure they had to port Webkit to the Skia GUI toolkit, and use a different Javascript core-and a jitting one at that, in the form of V8.
I know that coding changes were required to go from 23% to 99%-but exactly where those coding changes took place is unknown to me-it seemed however likely to me that much of those code changes must have happened in Webkit, which you insist is not the case, perhaps it took place in their own Skia-Webkit interface, or in the V8-Webkit interface or both.
But this does not speak much to the *ease* of using Webkit for Google-it must have been a hell of a lot of work, Google has been working on this project for 2 years now. Perhaps these ports had to be rewritten several times, like the GTK-Webkit port, or the fact that the Webkit used in Konqueror(QT4) is no longer based on KHTML. What I take from all this is that once the real work of creating a good solid port has been done, and merging this upstream, that those devs making use of the already ported code find Webkit really easy to use and code against. And If I was the dev who did the actual port, and then made applications which used the port, I would find this all much easier that having to work with Gecko, if for no other reason than the reason that I myself wrote the code.
That was the original goal, but then the age of horribly written plugins happened, and the devs had a choice; either do nothing and let people use these horribly written plugins and have a bad experience, or integrate the more commonly used bits.
Firefox 1 was phenomenal, 2 was pretty sucky, but better then the alternative, and 3 is a mature version of 2, but has long since left behind any hope of being “streamlined” or minimalist”.
The great thing about gecko is that everyone tests for it nowadays. The bad thing about gecko is that it has a long, kludgy history of bad design decisions, and it quite slow compared to the competition. There were alot more good choices made with webkit, and it shows in both the code quality/modularity of the engine, and in terms of perf.
Webkit has had two big flaws up till now. The first was that its javascript implementation was terrible, the second was that safari as a browser is pretty sucky, and that was the only really mature implementation available for the end user.
Also, Mozilla has managed to position themselves as the old boring standby that works with everything now, which is not a good place to be.
We haven’t seen much in the way of innovation coming from there in quite awhile now that is not duplicated in other camps. Even those vids that MozLabs put out awhile ago are far from revolutionary, and IE8 already implements the beginnings of most of the ideas that Mozilla sees as long term goals. Google managed to ship a JIT engine for js before they got theirs out the door, and Opera is a good five years ahead of their efforts to get into the mobile space.
Correct me if I am missing some big thing, but it is hard to see Mozilla being a long term player unless they get their act together really soon. Firefox is actually my least favorite browser at this point, which is a real shame, because it had such a bright future back in the phoenix/firebird days.