Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Chromium Google Opera Safari The Internet Apple

WebKit Developers Discuss Removal of Google-Specific Code 92

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.
This discussion has been archived. No new comments can be posted.

WebKit Developers Discuss Removal of Google-Specific Code

Comments Filter:
  • by Anonymous Coward on Friday April 05, 2013 @09:03AM (#43367481)

    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).

  • Why not? (Score:2, Insightful)

    by RocketRabbit ( 830691 ) on Friday April 05, 2013 @09:06AM (#43367495)

    It only makes sense to trim unused legacy code from any library. If Google isn't using Webkit any more, why leave their own specific stuff in there?

    It isn't a problem to fork code and remove legacy stuff. It was done when KHTML was forked into Webkit, and it will probably be done again. The only losers in the event of a fork like this are possibly the independent developers who contribute to Webkit, but it is doubtful that they were contributing code that is Google specific.

  • by RivenAleem ( 1590553 ) on Friday April 05, 2013 @09:19AM (#43367565)

    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

  • by Rich0 ( 548339 ) on Friday April 05, 2013 @09:20AM (#43367571) Homepage

    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 (Score:4, Insightful)

    by flimflammer ( 956759 ) on Friday April 05, 2013 @09:47AM (#43367755)

    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.

  • by Anonymous Coward on Friday April 05, 2013 @09:57AM (#43367875)

    Linux distros like ubuntu are technically not forks, but rather derivatives. A fork becomes independent after the fork takes place, even if they do merge code back and forth with the parent project. A derivative, on the other hand, is still dependent on the upstream project for core functionality.

    Autonomy is what makes a fork a fork. Dependence is what makes a derivative a derivative.

  • Re:So... (Score:4, Insightful)

    by Bill_the_Engineer ( 772575 ) on Friday April 05, 2013 @10:04AM (#43367947)
    There was a large number of "whiny bitches" on here when WebKit forked from KHTML. People react to change. Life goes on.
  • Re:So... (Score:5, Insightful)

    by KugelKurt ( 908765 ) on Friday April 05, 2013 @11:06AM (#43368537)

    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.

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...