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
As of this article, that's exactly what's happened.
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.
I thought about going for the first "woosh", but I'll leave it for another :)
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
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.
Especially since none of the answers are useful at all.
It just says "it's a fork, so right now, it's the same thing". I don't know why they thought they needed to repeat this for 30 minutes.
The video isn't about how to use the browser. The article isn't about how to use the browser, or changes in UI of Chrome. Forking WebKit serves to accelerate and simplifying Chrome development.
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.
Yikes, the FUD is strong with this one.
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...
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.
They didn't block them before, I don't see why this fork would cause them to block them after. They may decide to do so at some point, but that decision doesn't have anything to do with the forking...
Anybody who has ever looked at their task manager and wondered WTF WebKit2WebProcess process was and why it was using so much memory.
I find it tends to try to use as much memory as it possibly can, and even if it's sitting just on a single web page over time it bloats enough that I have to exit the browser and restart it to reclaim it
I just wish Safari could actually delete cookies without that webkit process crashing. I suspect both Apple and Google would far rather I kept cookies so they could make money from me.
I'm starting to lose my patience with webkit based browsers.
Lost at C:>. Found at C.
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.
... with the ex helping to burn the pictures?
Note that at least two Google employees offered to help.
What a bunch of FUD. Did whoever wrote that actually read the original?
For example:
vs
How does giving devs a chance to use new features ahead of time, without vendor-specific prefixes, while keeping the -webkit- prefixes and saying "we won't use vendor prefixes for new features" translate into highjacking the standards process? If they are using the same approach as Mozilla, is Mozilla being accused of hijacking the standards process?
DON'T BLINK!
Thats because most sites sniff useragents and serve browser specific code. This move will break apps that sniff android or Chrome and only serve -webkit specific CSs
http://saveie6.com/
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.
I think defeating ad-blocking and enhanced ad management are one of the primary reasons for the fork.
The first thing Google lists for architectural changes is support for out-of-process iframes
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.
Blink will support -webkit prefix.
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.
Did you even bother to see why they are moving iframes to their own process? Yeah, it's all about ads, not about making a more secure product... I think this has infinitely more to do with Chromebook than it does to ad sales, in fact moving iframes to their own process would give any ad-in-iframe LESS visibility into your surfing which you would think would be the exact opposite of what an "evil" Google would want.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
That change has nothing to do with ads, and in no way does it help or hinder ad blocking.
Google could have handled that quite simply by banning ad blockers from the chrome store, or by not extending the API with things specifically designed to support ad blockers...
The fork doesn't have anything to do with ad blockers because nothing was stopping them from banning those before.
Wow. A comment like that from a UID much lower then mine.
Fascinating.
A major user of WebKit had submitted code for WebKit. News at 11.
Sweet, posting information about why a technical change is being made is now trolling on Slashdot, it really has gone downhill.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
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 they have free time; they didn't have time to review and implement all the code Apple was releasing and got further behind.
Apple has contributed to and still contributes to many open source project today. LLVM, OpenCL, Darwin, cups, Bonjour/ZeroConf, etc.
Well, there's spam egg sausage and spam, that's not got much spam in it.
I said nothing about Google being "evil". Google is just providing more value to its customers. Google most definitely does not want ads to be able to access the rest of your browser information. That information should only come from Google, properly anonymized and billed. While this change would make it harder for malicious iframes to sniff data that doesn't belong to them, it would also give malicious iframes more opportunities to inject code. Currently, if such an iframe tried that and failed, it will kill the parent process, effectively ending the injection attempts. With the new system, multiple iframes could keep trying different tactics.
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.
Google is just providing more value to it's customers.
Why is it that I find when a company says that it's providing me with "more value", that I find that they are in reality removing things that I actually value, and / or adding things I do not value, and are probably charging me more for the priviledge?
For example:
I called a company complaining about a new juice bottle that, because the bottom was concave, held 1/2 an ounce less than the previous bottle, but they had not lowered their already high price. The person had the nerve to tell me that the change had been made because market research showed that their consumers wanted it. She didn't have much to say when I replied, "So you can show me surveys where people say that they either want to pay more for their juice, or get less of it, right?"
Oh, and keep in mind that the users of Google and Chrome are NOT Googles customers. Google sells targeted ads to advertisers. To be a customer really requires some kind of payment to be exchanged for a good or service.
The consumers of Google's free products are not customers, they are the product that Google sells to it's paying customers, it's advertisers.
THINK! It's patriotic
It doesn't even have to do that, it could just ignore everything that returns 127.0.0.1 that isn't localhost, and only THEN query the DNS server. Or, it could keep it's own small file of Google's own ad serving addresses, and translate those into IP Addresses before the request even hits the hosts file. This would have the advantage of never allowing THEIR ads to be blocked, while allowing their competitors to be blocked.
And since most Google ads (AFAIK) are graphics and flash light, this might even be acceptable to most Chrome (and now Blink) users.
Since I actually like the free website model mostly in use today, I only ever block ads when they begin effecting my web browsing speed, browser stability, or my privacy. So, yeah, I block all flash advertising, always.
THINK! It's patriotic
One has to wonder.
-- Did you try Tao3D? http://tao3d.sourceforge.net
Don't fix it. Once it starts causing problems and you see no upside in maintaining, remove it. Easy as that.