Slashdot is powered by your submissions, so send in your scoop

 


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

WebKit Developers Discuss Removal of Google-Specific Code 92

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

WebKit Developers Discuss Removal of Google-Specific Code More

WebKit Developers Discuss Removal of Google-Specific Code

Comments Filter:

  • Clean It Up Boys (Score:5, Interesting)

    by Anonymous Coward on Friday April 05, 2013 @08:57AM (#43367453)

    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: (Score:3)

      by mwvdlee ( 775178 )

      I just hope they make it a fork in the sense that Linux distro's are forks; actively exchanging code with the upstream project for the benefit of both.

      • Re: (Score:1)

        by Anonymous Coward

        Directly contradicting the first post. The announcement suggests neither will be upstream of the other.

        • That still doesn't preclude sharing on equal terms, at least until the two projects diverge enough to make that impractical.

          • Re: (Score:3)

            by afidel ( 530433 )

            Yeah, the BSD projects borrow fairly liberally from each other despite the fact that the code can rarely be copied and pasted.

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        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.

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

      Please explain to me: What negative impact do cleanly separated platform adaptions have? So WebKit devs will delete the chromium directory in https://trac.webkit.org/browser/trunk/Source/WebCore/platform [webkit.org] and Google will delete all directories except chromium (and probably android) but I don't see why a buggy BlackBerry adaptation would have any negative impact on the Chromium adaptation and vice versa.

    • WebKit doesn't include a JS engine cheome has always had V8 and safari didn't. So your JS development should be any different.
    • That would make sense, but the discussion has now veered off into also removing the ability to plug in components such as your own JavaScript engine, because it is expensive to maintain....if anything the cleanup should go the other way of making it more easy to plug-in different implementations for specific pieces into WebKit. The lesson here should be IMHO, to avoid future forks by making ports less expensive, not use this as an opportunity to cut down on extensibility.

  • Like this part (Score:4, Funny)

    by Anonymous Coward on Friday April 05, 2013 @09:01AM (#43367471)


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

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

    • Re: (Score:1, Funny)

      by Anonymous Coward

      Because Adria Richards thinks forking is sexist and puts women down, that's why!

      God forbid you using your 4g dongle to connect to the internet in order to fork webkit's repo, she'd probably have the cops arrest you!

    • Re:On the Origin of Species (Score:4, Interesting)

      by Anonymous Coward on Friday April 05, 2013 @11:14AM (#43368621)

      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: (Score:3)

      by SeaFox ( 739806 )

      I don't see why people get so scared of forking code. Differentiation and species drift happens in nature all the time...>

      I think the fear here is that the forking of code will lead to browsers that interpret "standards" differently and don't display web pages the same way. We'll be back to "I have to use Internet Explorer for site x and Netscape to get site y to work right."

      One thing about homogenous browsers, we're more likely to all be on the same page on how to read the web (pun not intended).

      • Re: (Score:2)

        by AmiMoJo ( 196126 ) *

        We'll be back to "I have to use Internet Explorer for site x and Netscape to get site y to work right."

        That's a problem with the design of the site. HTML was never designed for pixel perfect layout, quite the opposite in fact. CSS gives you a lot of control but also wasn't designed for the kind of perfection that web monkeys seem to want. Aside from anything else a site should at least be able to cope with different font sizes, for example.

        If it uses so much tricky HTML/CSS/JS that it doesn't render reasonably in standards compliant browsers then I'm not browsing it.

  • Why not? (Score:2, Insightful)

    by RocketRabbit ( 830691 )

    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.

  • I have always wondered why everyone was using the same engine while every browser has a unique selling point. Now it becomes clear a one size fits all equals a one size fits noone perfectly. Perhaps this creates a bit more diversificaton and true unique selling points for the browsers.
    • Well code reuse has greatly helped anyone who has worked on open source. They don't have to reinvent the wheel every time. Apple forked KHTML because it was small (140,000 lines) and clean. Apple could have written it all from scratch but they benefited from the work that was already done in terms of time and direction. When they got more expertise they started to take it in a different direction. Google is doing the same with Blink. It's the same pattern as Apple's ARM hardware. They used slightly c
  • Comment removed based on user account deletion

    • The first thing I though of was the http://en.wikipedia.org/wiki/Blink_element/ [wikipedia.org] I can only imagine how much easier it will be for Google to track us via a custom HTML and extensions it implements...

      Which is doubly odd, because I just recently used the forbidden <blink> element once, in all my years of development, to create a blinking terminal-like cursor for a few quick one-off temporary landing pages (excerpts from my old text based BBS game). [project-retrograde.com]

      Firefox actually renders the "cursor" blinking... Guess which browser doesn't? Chrome.

      • Re: (Score:2)

        by keytoe ( 91531 )

        You may be the only other person I've heard of to use <blink> in a legitimate fashion.

        About 8 years ago, I was writing a web based application for a public facing help desk department. Appointments were limited to 15 minutes per customer, and to serve as a reminder we provided a timer right in the ticket system. At a certain threshold, the timer would turn red to indicate hurry up mode - and for the last minute, it would blink. One of my coworkers set out to write a JS timer to handle it until I remin

    • The first thing I though of was the http://en.wikipedia.org/wiki/Blink_element/ [wikipedia.org]

      And I was thinking about Bling. As in "Chrome, now with extra Bling!"

  • 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? Safari and Chrome don't share much of anything really in common save for the webkit api and even then it's a clusterfuck of vendor specific tags

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

      • Part of the reason for this is that Apple is not being completely vendow neutral. They seem to be fighting some Google enhancements on somewhat 'political' grounds rather than technical. I think this is going to end up being good for everybody.

        • Part of the reason for this is that Apple is not being completely vendow neutral. They seem to be fighting some Google enhancements on somewhat 'political' grounds rather than technical. I think this is going to end up being good for everybody.

          You got it the wrong way around. It was Google who refused to develop a multi-process architecture within WebKit, just as they refused to improve JavaScriptCore and instead created V8 as stand-alone project under Google-exclusive control.

      • Actually Apple at that time was a pretty bad FOSS citizen.

        Can you recite specific cases? The situation with KHTML was when two different development models clash. Apple with its paid development team churned out a lot of code because they needed to develop a working browser (Safari) quickly. Apple first submitted changes in Jun 2002 and by Jan 2003 had Safari in beta. They didn't have a lot of time to document the code as necessary when they submitted their patches to upstream. It happens. The KHTML core developers are mostly volunteer so they work whenever t

        • Can you recite specific cases? The situation with KHTML was when two different development models clash.

          Apple's development model at that time was behind closed doors and doing that is not good FOSS citizenship.
          Another example is Apple Public Source License 1.0.

          Apple has contributed to and still contributes to many open source project today. LLVM, OpenCL, Darwin, cups, Bonjour/ZeroConf, etc.

          Yes, today. I was referring to Apple's initial steps into FOSS development.
          Apple dropped source code under APSL unless it had no choice. Today even Apple's own developments such as Bonjour or Dispatch are released under Apache License or BSD-like licenses and other parties can easily pick them up. Apple successfully set up WebKit as vendor-neutral proj

  • Anyone said it yet? (Score:1)

    by Anonymous Coward

    DON'T BLINK!

  • That was an amicable parting if I've ever seen one. However, leave it to the internet peanut gallery and various religious nut jobs (i.e Google fan girls, Apple fan girls and certain other fan girls) to make a mountain out of this ant hill.
    • Indeed. This is what forking is supposed to do. If someone decides to take a code in another direction, they can do so as long as they meet the licensing terms.
  • Don't fix it. Once it starts causing problems and you see no upside in maintaining, remove it. Easy as that.

Slashdot Top Deals

"If it ain't broke, don't fix it." - Bert Lantz

Close