Announcing WebKit2

A better idea would be to contain the text in something.

At work, I have four browser instances open: three Chromes and one Firefox. I have placed two of them on the same virtual desktop, and the remaining two browser instances are on separate virtual desktops. On the first virtual desktop I manage my work-related tasks, such as company email, Hudson and VersionOne, a project management tool for agile software. The browser on the second virtual desktop is for developing software: the web application I develop is on it. The third virtual desktop is for fun and free time use. Altogether I have about ten browser tabs open; even that is too much. I feel that the more tabs I have open the more fragmented my attention is.

I don't even have to open a website, just open a new tab and its starts beachballing just to load the new tab. Also extensions are a big part of my browsing experience. Safari doesn't have large extension community like firefox and Chrome.

Simply put, for me, chrome is more than its rendering engine. Overall its just a well rounded piece of software with very frequent updates, which is very unique among browsers.

The bottom line is that Chrome and Safari will not be sharing any less WebKit code than before - the WebCore layer, the part that does most of the heavy lifting in rendering Web content - remains unchanged. We may actually have the opportunity to share more code since we'll now be facing many of the same problems.

We also hope the Chrome team someday decides to go more in a WebKit2 direction and do multiprocess inside the WebKit API boundary instead of outside, so they can share more code with other port. But that's up to them, and they already have a lot invested in their current path.

No, you still need all of the parent/child communication. if a child tab dies, who cleans up the mess? If the user changes rendering preferences, how do you update all the client process? At the very least there's some infrastructure to coordinate parent and children. It's likely they do clever things so each visible window can be rendered by multiple processes, without the ui getting fubared.

fork() is a long-standing thorn when porting code onto some platforms; it's seldom used for what it was originally intended for, and (when it is) the copy-on-write memory semantics and the file descriptors and network contexts and such aren't widely adopted.

About 95% of the cases reviewed during the ports were using fork() as a way to start a process; as a way to do a vfork()/exec() and to create a separate process. The remaining 5% of those applications were using the memory address spaces and the I/O channels and the rest of the process context. Which makes those really difficult to port to a platform that lacked a full-on fork().