WebKit Developers Discuss Removal of Google-Specific Code

hypnosec writes "WebKit developers have already started discussing the removal of Chrome- and Chromium-specific code from the rendering engine in a bid to make the code easier to maintain. Just a couple of days back, Google announced it will go ahead with a WebKit fork to develop a new browser engine — Blink. According to Google, having multiple rendering engines — just like multiple browsers — will allow for innovation as well as contribute toward a healthy open-web ecosystem. The discussion was started by Geoffery Garen, an Apple WebKit developer. He said Google's departure is an 'opportunity to streamline' the code of WebKit, which would eventually make development 'easier and more coherent for everyone.' Garen expects that developers who will be working on WebKit in the future should help to clean up the code. However, Adam Barth and Eric Seidel — two Google WebKit developers — have already offered their help." Google plans on making the switch to Blink in the stable Chrome release in around 10 weeks. They've posted a half-hour video explaining how the transition will work.

Comments

Clean It Up Boys

[Anonymous Coward]

The removal of Chrome specific code from WebKit, and non-Chrome code from Blink will benefit everyone in the long run. Both code bases and rendering engines will be smaller, faster, less buggy, etc.

The down side to all this is checking code in another browser model as well as a different js debugger in Blink.

World Wide Web of Moving Targets

Re:Clean It Up Boys

[BasilBrush]

Webkit does have a JavaScript Engine. It's called JavaScriptCore. But Chrome didn't use it.

Like this part

[Anonymous Coward]

#ifdef __CHROME__
doCheckpoint( 1332 ); // load additions to keystroke log and browser history
doCheckpoint( 1335 ); // compress
doCheckpoint( 1337 ); // send contents to gmail server
#endif

On the Origin of Species

[Anonymous Coward]

I don't see why people get so scared of forking code. Differentiation and species drift happens in nature all the time, and a code-base that tries to fit too many different requirements is awful to maintain (and also unstable).

Re:On the Origin of Species

[Anonymous Coward]

Well, in this case Webkit is planning to drop V8 support. I'm kinda freaked out by the fact that Webkit apparently isn't script engine agnostic as it should be, but now all the incentive to make it such may be lost.
Forks in general tend to cause much duplication of effort, especially if both branches remain popular. Given enough time, fixes for one fork aren't obvious to implement in the other. You shouldn't really fork a project unless you cannot reach a peaceful decision.
In this case however, Google just didn't want to contribute to the new Webkit2 with generalised multi-process support, because that would make it easy to develop a multi-process browser, which just happened to be Chrome's main selling point.
The Webkit folks made the right technical decision, Google made the right marketing decision. A fork was inevitable, sadly.

Re:Hurr durr Google

[Anonymous Coward]

http://prng.net/blink-faq.html

Know your audience.

[RivenAleem]

The "how the transition works" video will be for people interested in how the transition works, not a regular user. Your comment is like saying a 30 minute video on "how the internal combustions engine works" is a pointless exercise, because the regular driver just wants it to work

Re:Good luck with that

[Rich0]

This is an open source project, and the video is directed at people who work with the browser source code or who have an interested in webkit/blink. It isn't targeted at end users.

It is a rendering engine. How many end users have even heard of webkit?

Obviously the browser will work the same after as before. The only thing a user might notice is that it is faster (some day) or that it has some new feature that perhaps would not have been as easy to develop without the fork.

I for one appreciate that a company like Google takes the time to actually create videos like this. I can certainly say that my employer doesn't put half-hour videos on Youtube discussing the software engineering decisions it makes for its closed-source systems.

Re:quid pro quo

[flimflammer]

Erm... You're confusing external functionality that isn't cross platform (ActiveX, the old DirectX-labeled text effects, etc) versus internal functionality designed to integrate better with the browser. This is obviously the latter.

Re:quid pro quo

[moronoxyd]

For the same reason there is Apple specific code in WebKit. And (probably) PowerPC code, and x86 code, and Android code, and iOS code, and ...

Why is HyperV code in the Linux kernel?
Or code that is for Intel graphics?

If a piece of software tries to support many platforms and usage cases, you have code that is only used in specific scenarios.

And if the reason to support this platform or usage case is gone (i.e. iOS support for Blink, and Google support for post-split WebKit), then you remove it.

Re:So...

[Bill_the_Engineer]

There was a large number of "whiny bitches" on here when WebKit forked from KHTML. People react to change. Life goes on.

Re:So...

[KugelKurt]

Google is evil according to all the whiny bitches on here for Forking Webkit into Blink. So just how horrifically evil is Apple for forking KHTML into Webkit?

Actually Apple at that time was a pretty bad FOSS citizen. People campaigned to Apple to rethink the way it does development and that resulted in a vendor-neutral development home for WebKit. These days KDE is a happy user of WebKit.

Google now repeating Apple's past mistakes is not so great. 2 wrongs don't make 1 right, as they say.