Slashdot Mirror
WebKit2 API Layer Brings Split-Process Model
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."
Don't let facts and history 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:
Well, there's spam egg sausage and spam, that's not got much spam in it.
Well, my own custom browser that I designed and that I use uses a VM (I chose VMware) for every tab, I find it even more secure that way ;-))
Everything I write is lies, read between the lines.
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
Still, whenever a Tab hangs in my Chromium, usually most, or all other tab dies as well, occasionally entire chromium.
The next "big thing" will be some dipshit who writes an HTML rendering engine using nothing but JavaScript and HTML5 canvas.
Nope, canvas clearly isn't the right choice. If some dipshit were to seriously consider this, they'd use OpenGL.
Just because this is how the Web community does things, that JavaScript/HTML5/canvas browser will in turn get a new scripting language that's even shittier than JavaScript is.
First: Where's your evidence that this is how the Web community does things? I honestly can't remember the last time I wrote a scripting language within a scripting language in anything at all related to web development.
Second: What, exactly, is shitty about JavaScript? Most people who think JavaScript is shitty don't understand it. It's actually a very nice language, albeit with a few ugly quirks.
Soon it'll be hyped even more than Ruby on Rails, AJAX and Cloud Computing were.
Nope, because as much as you'd like to believe otherwise, each of those things actually has something of value to contribute to the world. You may not like Rails, but it did remind everyone that MVC is a Good Idea, and new Web frameworks generally include at least that concept. AJAX allows applications to run in the browser -- again, like it or not, that's something which has value. Cloud computing, in either sense -- whether you're talking about web apps keeping your data, or utility computing -- again have something to contribute.
What does your hypothetical browser contribute? It does the exact same thing as everything we have, only slower and shittier. (And before you claim that this is how web apps work, how, exactly, could I safely run an application without installing it before now? Again, it actually has some positive points, whether or not they're things you want -- your idea has none.)
Managers around the world will force their developers to rewrite all of their web sites and web apps to target this new shitty scripting language and browser.
I don't know any managers who have suggested something so stupid with the current generation.
Don't thank God, thank a doctor!
https://developer.mozilla.org/devnews/index.php/2010/04/08/firefox-lorentz-beta-available-for-download-and-testing/
'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!
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.
I am TheRaven on Soylent News
Like GP said, WebKit is basically just the work of the KHTML devs. Apple leeched off of their work.
If by 'leeched' you mean they took an existing open project, modified and extended it, then released that work for free. I guess if you redefine leech then yes they leeched it.
While WebKit began from KHTML, since 2002, it's definitely been an Apple-driven innovation, and they contribute most to its existence.
So, is there a way to run all of those processes inside a one big process?
Not on most operating systems, no. This is a major flaw (I actually gave a talk about this and proposed a language extension that takes advantage of it a couple of weeks ago) in most modern systems. It's particularly embarrassing because several mainframe operating systems did support this idea back in the early '70s.
The browser should not be doing this, it should be the job of the OS. Operating systems have a much better track record of isolating processes from each other. A process should be able to create subprocesses that have a subset of the capabilities of the parent and can not interact with the system without going via the parent. The isolation could then be trivially enforced by the MMU, without requiring (slow, complex, buggy, insecure) software implementations.
I am TheRaven on Soylent News
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.
On the other hand I think Steve Jobs made a great point about this at the iPhone OS 4 event. If your end user has to use some sort of process management you have failed. The more I have thought about it the more I agree, only coders and debuggers should have to deal with process management. If I'm not working on the project I don't care about processes, and unless your program is screwing up my system I don't care about processes.
Computers allow humans to make mistakes at the fastest speeds known, with the possible exception of tequila and handguns
IMHO of course :)
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.
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.
Don't thank God, thank a doctor!
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.
"Unless your program is screwing up my system..."
In what way is a process hang *not* screwing up my system?
List of ways it's potentially screwing up my system:
- It's consuming CPU and not doing anything useful.
- It's consuming RAM and not doing anything useful.
- It's stopping me from doing actual work in it.
His point is that the only time the end user should see a process manager is if you fucked up... Admittedly programmers tend to fuck up an awful lot – this programming thing is *really* hard to get right, but the general point is right. A user shouldn't see the process manager unless a program has fucked up.
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.
Are you absolutely sure it's not Flash/PDF/[Silver/Moon]light plugins that are freezing Chrome?
Wait, hang on, what's the difference in a plugin freezing Chrome and the problem described by GP? He says a tab can hang and then sometimes all the other tabs die too, to the end user who cares if it's technically caused by a plugin or not?
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.