Slashdot Mirror

← Back to Stories (view on slashdot.org)

WebKit Developers Discuss Removal of Google-Specific Code

Posted by Soulskill on from the cleaning-house dept.

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.

8 of 92 comments (clear)

  1. Clean It Up Boys by Anonymous Coward · · Score: 5, Interesting

    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

  2. Like this part by Anonymous Coward · · Score: 4, Funny


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

  3. On the Origin of Species by Anonymous Coward · · Score: 5, Insightful

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

    1. Re:On the Origin of Species by Anonymous Coward · · Score: 4, Interesting

      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.

  4. Re:Hurr durr Google by Anonymous Coward · · Score: 5, Funny

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

  5. Know your audience. by RivenAleem · · Score: 5, Insightful

    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

  6. Re:quid pro quo by moronoxyd · · Score: 4, Informative

    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.

  7. Re:So... by KugelKurt · · Score: 4, Insightful

    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.