Slashdot Mirror
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.
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
#ifdef __CHROME__
doCheckpoint( 1332 );
doCheckpoint( 1335 );
doCheckpoint( 1337 );
#endif
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).
http://prng.net/blink-faq.html
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.
The video is for Chrome(ium), WebKit, and now Blink developers, not for the end users or the browser(s).
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
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.
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.
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.
There was a large number of "whiny bitches" on here when WebKit forked from KHTML. People react to change. Life goes on.
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
Chromium specific, as in, is only used when building Chromium/Chrome (that other Webkit browsers don't want or need). Not actual web standards stuff, probably. Except maybe WebGL?
Clever signature text goes here.
The first thing I though of was the http://en.wikipedia.org/wiki/Blink_element/ 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).
Firefox actually renders the "cursor" blinking... Guess which browser doesn't? Chrome.
Nobody is removing anyone's code from WebCore itself. They are only talking about now unmaintained platform adaptions. Unmaintained adaptions have always been removed. Nobody within the public even noticed when the Symbian S60 adaptations were deleted.
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.
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 customized Samsung chips in the beginning for the iPhone. Then they bought PA Semi and Intrinsity. With each generation of CPU, they have customized the ARM chip more and more. At first they modified the SOC but left the ARM core intact. With the A6, they have begun to make modifications to the core itself.
Well, there's spam egg sausage and spam, that's not got much spam in it.
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 project, joined LLVM and contributed Clang, even became the release manager of X.org at some point, etc.
Google should have learned from Apple's past mistakes. Yet, Google somehow successfully presents itself as great FOSS citizen, despite:
The Android kernel was as much of a "uncivil" fork of Linux as WebKit was from KHTML and it took much campaigning by Greg KH and others to get Google to even start to submit and maintain the patches upstream.
Google refused to implement a multi-process architecture directly in WebKit and insisted to make it Chrome-exclusive. Same with V8: No attempt to even try to optimize WebKit's JavaScriptCore, instead insisting on adding hard to maintain bindings for V8.