Forgot your password?
typodupeerror
Software Apple News

WebKit2 API Layer Brings Split-Process Model 95

Posted by Soulskill
from the empire-strikes-back dept.
99BottlesOfBeerInMyF writes "Anders Carlsson and Sam Weinig over at Apple just announced WebKit2, a rework of the WebKit engine that powers Chrome and Safari. This new version of WebKit incorporates the same style of split-process model that provides stability in Chrome, but built directly into the framework so all browsers based upon WebKit will be able to gain the same level of sandboxing and stability. AppleInsider has a writeup, and the team has provided 'high level documentation' as well. Both Palm and the Epiphany team are going to be happy about this."
This discussion has been archived. No new comments can be posted.

WebKit2 API Layer Brings Split-Process Model

Comments Filter:
  • by UnknowingFool (672806) on Friday April 09, 2010 @06:27PM (#31795922)

    Like so many things, Webkit isn't an Apple innovation!

    Don't let facts and history [wikipedia.org] get in the way of your bias. Webkit was forked from KHTML by Apple in 2002 and named it Webkit. For a while KHTML developers backported Apple's features independently but have since worked closely with Apple incorporating Webkit features into KHTML. Apple released Webkit as open source in 2005. They are still active in maintaining and developing it. Specifically, some developers at Apple did the development and announced the changes on a dev forum:

    This is a heads-up that we will shortly start landing patches for a new WebKit framework that we at Apple have been working on for a while.

  • by Anonymous Coward on Friday April 09, 2010 @06:33PM (#31795978)

    Alternatively, you can use a better task manager such as Process Explorer which will group all processes in a nice hierarchical view:

    http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx [microsoft.com]

  • by Tumbleweed (3706) on Friday April 09, 2010 @06:58PM (#31796150)

    https://developer.mozilla.org/devnews/index.php/2010/04/08/firefox-lorentz-beta-available-for-download-and-testing/ [mozilla.org]

    'Lorentz' - a beta version combining FF 3.6.3 with the out of process plugin feature, became available yesterday. This shoves the plugins into their own process, which is where the vast majority of problems occur. Give it a shot and report them bugs!

  • by TheRaven64 (641858) on Friday April 09, 2010 @06:58PM (#31796152) Journal
    Did you ever use KHTML? It did a tiny fraction of what WebKit does, and most of the recent stuff (JavaScript implementation, all of the HTML5 support much of the CSS support) is from Apple. It's basically just the work of the KHTML devs in the same way that FreeBSD is basically just the work of those guys at UCB in the '80s.
  • by bonch (38532) on Friday April 09, 2010 @07:00PM (#31796162)

    While WebKit began from KHTML, since 2002, it's definitely been an Apple-driven innovation, and they contribute most to its existence.

  • Re:Electrolysis ETA? (Score:3, Informative)

    by TLLOTS (827806) on Friday April 09, 2010 @07:13PM (#31796302)

    I think it's coming in phases. Isn't the next version of Firefox supposed to isolate plugins in their own processes?

    It is indeed, in fact I'm writing this post on the beta version [mozilla.com].

  • Chrome is Webkit (Score:2, Informative)

    by Anonymous Coward on Friday April 09, 2010 @09:47PM (#31797292)

    If I have a choice between Webkit and Chrome, I'd prefer Webkit to embed in applications. However, the graphics and network components of Apple's Windows port are appropriate, so Chrome is clearly the better choice, even after Apple has added this split process feature.

    Chrome uses WebKit as its HTML renderer. Google essentially packaged a separate Webkit instance inside each tab.

    This is just moving it down a level.

  • by Anonymous Coward on Saturday April 10, 2010 @02:37AM (#31798294)

    Except that threads share memory and processes don't. That's the main reason for Chrome's process boundary to ensure that different parts of the browser (tabs, plugins) don't correct each other. A VM can enforce this on the code, but the browsers are compiled. So basically he wants threads without shared memory in C/C++.

  • by SanityInAnarchy (655584) <ninja@slaphack.com> on Saturday April 10, 2010 @03:13AM (#31798406) Journal

    wtfjs [wtfjs.com]

    Top post on that is a remark about how things behave weirdly when you redefine certain methods. That's true of other languages I like -- any language that supports operator overloading can create some really weird shit.

    The more important question is why you would ever do that? Don't abuse the language, and it won't abuse you.

    Next one is about numbers close to infinity. When would I ever see this?

    And there is one that's an IE-specific bug. That's an IE bug, not a Javascript bug.

    Again, these are interesting warts, but why would I care?

    Secondly, Prototype-based OO is quite ugly. Sure, it's workable, and you can argue that it's the more pure way to do OO...

    I can and do. I actually like it, because it's simpler, and I think it's far easier and cleaner to build a class-based system on top of prototype-based than the other way around.

    any way you try to sugar coat it, Javascript makes it a lot uglier than it needs to be.

    I don't think so. There are a few patterns in particular which work very well in Javascript, even elegantly. I certainly agree that it has room for improvement, but the fact that it's prototype-based is the last place I would look.

    Thirdly, the fact that it's a defacto standardized language, a lot like the web itself was defacto'd into existence rather than people trying to follow standards (which came later), each implementation is different enough that what will work in one does not necessarily work in another.

    There is, however, an official standard now. The differences seem to be largely at the API level, and that's something which can be handled in libraries.

    Still, you can point out flaws and inconsistencies in any language, but the web-related technologies tend to be a lot more, well let's call them "special" (just to make them feel better).

    Could be. I still don't think it justifies the "even shittier" comment. It's not hard to find many examples of languages shittier than JavaScript -- I'd start with, oh, Java.

  • by beelsebob (529313) on Saturday April 10, 2010 @03:40AM (#31798468)

    When he says JavaScript engine, he means that Apple wrote the entire javascript engine in WebKit. It happens that KHTML had a javascript engine that was much slower, much less stable, and much less supporting of modern javascript, but that doesn't change the fact that apple wrote *all* of WebKit's Javascript support as it stands. They also wrote most of it's CSS support, and most of it's HTML support (even for older standards).

    To suggest that WebKit as it currently stands is the work of the KHTML devs is a bit of an enormous stretch, and probably falls into the rabid anti-apple fanboisim category. Try using a KHTML (from when apple grabbed it) browser, and a WebKit one, and then consider how much work apple have done.

  • by jo_ham (604554) <joham999&gmail,com> on Saturday April 10, 2010 @03:46AM (#31798486)

    Yes, they rolled their own Javascript engine for Safari 4, but based on the original engine with large improvements in speed. This is Nitro (or SquirrelFish, or SFX, or whatever it is being called right now).

    They also did *massive* work on the CSS core to enable Safari (and Webkit itself) to pass Acid 2. So "working fine" before Apple "ripped it apart" to make it more standards compliant.

    Apple have done a great deal of work on Webkit, not to diminish any of the work done by people on KHTML before that, but any charge that Apple haven't done much, or just rebadged it and called it done, or have negatively affected KHTML or Webkit is just a non starter.

  • Re:Yay! Sandboxes! (Score:4, Informative)

    by Bake (2609) on Saturday April 10, 2010 @07:51AM (#31799058) Homepage

    I actually have seen something similar since I started to use Chrome. It usually happens when I fire up many tabs from one tab (in my case it happens when I open what I deem fit for further reading from my Google Reader, which can reach up to 30-40 tabs). What appears to happen is that the tabs opened from another tab share the same tab process as the parent tab.

    Under other circumstances this might not be a problem, but given the nature of Google Reader when you're scrolling through your unread items list (i.e. it "appends" newer and newer RSS items to the bottom of the list frame itself) it starts to take up a fair amount of ram that isn't freed up when you reload the originating tab (all in the name of caching no doubt).

    This has happened less often now that I have Flashblock installed, but still happens occasionally. It also helps that I now open fewer tabs from the Google Reader tab and simply close and reopen it when I'm done reading the tabs that I opened from within the GR tab. This kills the ram eating process and starts a new one.

All constants are variables.

Working...