Ooh, and with multi-process coming to Firefox and other Mozilla apps (https://wiki.mozilla.org/Electrolysis), soon we'll have multiprocess/async web browsing everywhere.
Honestly, I'm not all that enthused about this. Once Safari segregated plug-ins to separate processes, I've literally not had a single crash from a stable version (there was a buggy nightly build about a week or so ago that crashed twice in a day — oh, the humanity!). I use my browser pretty much 16 hours a day, and can easily have 50+ tabs at any given point in time. Even though Chrome has extensions that I would appreciate, since each one of Chrome's tabs has to set up its own address space, it uses a significantly higher amount of RAM than Safari altogether — which makes Safari the browser I use 95% of the time.
If Apple waited until they needed something like this, it would already be too late. That's why they are doing it now. It's not that WebKit isn't good enough as is, they just want to make it that much better.
I have always wondered why people keep so many browser tabs open. From my point of view, open tabs represent unfinished tasks or web pages I should go back to as soon as possible.
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.
In a twisted way, I'm kind of disappointed, though; it'll make the choice between Chrome and Safari a lot harder. Right now I'm using Chrome 95% of the time, but if Safari becomes much better, I might end up sitting between two chairs.
Anyone knows what the implications of this are for Chrome? They use Webkit. Will they stay on Webkit1 while Apple splits with V2?
WebKit actually has multiple different API layers. There is the Cocoa API used by Safari on Mac, a Gtk API, a Qt API, and a special API just for Chrome. WebKit2 is really a peer to all these APIs, although we also hope it can be a tool for building new tightly integrated APIs that support multiprocess and nonblocking operation.
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.
Safari has bigger issues than rendering engine. (at least for me)
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.
Do you have top sites enabled? That's a comically inept botch (loading a 300MB image pack?) but with it disabled the difference versus Chrome is pretty minimal - it's mostly down to Chrome's ability to segregate CPU-hungry apps at that point.
In addition, there is a defaults command to disable web snapshots in Safari (for Top Sites, history, etc). This can save considerable amounts of disk and bandwith if you don't use the graphical previews.
Yes, I had top sites enabled. However, as I mentioned somewhere else, I just checked safari for the first time since the last update and the beachballing problem seems to be gone now. Safari overall seems much more responsive.
I agree. People always seem to bash Safari in discussion boards, and I always read these comments a bit confused. I've used Safari full-time for the past 2.5 years, and I've never once had a problem.
I downloaded Chrome and didn't notice anything significantly different than Safari (other than the strange-looking tabs, from the standpoint of someone used to Safari), so I shrugged my shoulders and deleted it.
I'm not saying Safari is a superior browser. Just that it has always seemed perfectly fine to me.
Now that you mentioned, I realized that I didn't use safari since the last large system-wide update (I think it was in the last 2 weeks or so, 10.6.3). So I tried it now and I can't replicate the beachballing problem, Safari seems much more stable after the recent update.
On an unrelated note, firefox on mac is a really sorry case. I hope this is not only on my system.
I've find the debug tools in the WebKit nightlies to be more polished and just as capable as those offered in Firebug, without the jank of Firefox on the Mac. What specific features are essential to your workflow that WebKit doesn't offer?
I hate to repeat it, but it's really true. Firebug makes it so easy to debug CSS due to the saneness of the CSS UI. WebKit's inspector UI is a nightmare for tracing a CSS calculation.
I wouldn't call it a nightmare, its just not as good as firebug yet but made major improvements over the last year or so. If there was no firebug today than I Web Inspector would be the second best choice. Their CSS editing and tracing needs to be a bit more intuitive, not a fan of clicking check boxes to remove CSS element.
Perhaps my requirements are much less demanding than yours, but I find the Safari develop tools to be more than adequate. Quite like them, in fact. Which aspects were you finding to be awful?
I was just going to say that. I had similar performance problems with Safari, especially when opening the Top Sites view. After the latest Safari update, however, I see none of those problems.
What's wrong with it? It works great for me. Memory usage seems like it might be a little higher, but it's well worth it for the extra add-ons and configurability.
Memory usage is higher, it generally feels a little bit slower than Safari or Chrome, and it takes a ridiculous amount of time to launch. I skipped Safari entirely when I first got a Mac because I was used to FF on Windows. I tried out Safari after a friend suggested I do so. I've since moved to Chrome as my primary browser, but there was a buggy release (for me) that caused me to switch back for a while. I now try to avoid opening FF unless I absolutely need something in Firebug or the Web Developer Toolbar.
One plus to Chrome is the integrated search/URL bar, also. I've gotten so use to using the same bar for both, that I've had issues using other browsers when they try to visit some site that's actually my search query.
Firefox still has a place on my system, but it's definitely not something I want to use all the time.
I would be very surprised if Apple took the time to re-write the rendering engine but didn't also work on the UI. I suspect that when this new rendering engine launches, it will probably wrapped in a UI that copies most of the innovations of Chrome (and hopefully improves on them) in the same way that Chrome took a lot from others.
On Mac if I need to have lots of tabs open (which I do when I visit photoline.ru and want to see all the photos of the day:
I just click on thumbnails to open them in background and then go through them. Sometimes it resutls in several hundreds of tabs, weird I know) Safari handles that much better than Chrome. Chrome is my default browser, but I swtich to Safari just to browse said site.
I understand the need for each process to be in a separate process, but would've all this special code (to separate processes) would've been needed if Windows had implemented fork()?
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.
Trivia time, the Windows kernel actually does implement fork, it just doesn't expose it to the Win32 subsystem. I keep trying to convince the kernel devs to expose it, because it'd be extremely handy for UAC if you had a ForkAndElevate() function that would create a forked child with elevated Admin privileges.
Someone once told me that the NT kernel is designed so that with a couple config changes you can make it behave like Unix or OS/2, with Windows being just one "personality" on top the device, supposedly because MS was contracted to build several different OS in the early 90s. Is this what you are referring to by "the Win32 subsystem"? Does that still work? Or have there been so many changes over the years that something crazy would happen if you tried to run NT OS/2?
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().
WebKit is used by many different applications and browsers (eg. Epiphany, Arora, Omniweb, Shiira, etc) -- by incorporating multiprocess support directly in webkit all of those applications can make use of it.
WebKit is also used in lots of other applications that are not browsers, but may be getting untrusted content from the network, or that may be rendering complex content but need total responsiveness. For example, Mail, iChat, Adium, Colloquy, lots of other chat clients on Mac too.
"Currently WebKit2 is available for Mac and Windows, and we would gladly accept patches to add more ports." does not sound like they are dropping anything.
WebKit isn't an end user product -- it's a library, ports are maintained by the people who want the port, there are active gtk, qt, wx, and efl ports. WebKit doesn't have a set of "supported" platforms, each port is responsible for maintaining their own backend support, and their front facing API.
There's also the element of "linux" not meaning much in this context -- as I said above there are multiple port, eg. webkit/gtk, qtwebkit, webkit/wx, etc
