×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

How Competing Companies Are Jointly Building WebKit

Soulskill posted about a year ago | from the getting-along-behind-the-scenes dept.

Software 125

New submitter jgb writes "WebKit is, now that Opera decided to join the project, in the core of three of the five major web browsers: Apple's Safari, Google's Chromium and Opera. Therefore, WebKit is also a melting pot for many corporate interests, since several competing companies (not only Google and Apple, but also Samsung, RIM, Nokia, Intel and many others) are finding ways of collaborating in the project. All of this makes fascinating the study of how they are contributing to the project. Some weeks ago, a study showed how they were submitting contributions to the code base. Now another one uncovers how they are reviewing those submitted contributions. As expected, most of the reviews during the whole life of the project were done by Apple, with Google as a close second. But things have changed dramatically during the last few years. In 2012, Google is a clear first, reviewing about twice as much (50%) as Apple (25%). RIM (7%) and Nokia (5%) are also relevant reviewers. Code review is very important in WebKit's development process, with reviewers acting as a sort of gatekeepers, deciding which changes make sense, and when they are conforming to the project practices and quality standards. In some sense, review activity reflects the responsibility each company is taking on how WebKit evolves. In some sense, the evolution over time for this activity by the different companies tells the history of how they have been shaping the project."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

125 comments

Companies can work together just fine... (5, Insightful)

mwvdlee (775178) | about a year ago | (#43054937)

...just as long as you keep managers, marketeers, sales people and HR out of it.

Re:Companies can work together just fine... (2, Insightful)

Anonymous Coward | about a year ago | (#43055119)

So who decided they weren't confident in opera's own engine and let's swap years of work out for webkit? Developers?

Re:Companies can work together just fine... (3, Insightful)

Anonymous Coward | about a year ago | (#43055445)

So who decided they weren't confident in opera's own engine and let's swap years of work out for webkit? Developers?

I doubt it's so much a matter of confidence as it is a matter of outbreaking common sense. Why spend resources on your own engine when there is an open, fast, very popular, well-supported, and well-regarded engine available for free? I'm surprised they waited so long, though I am not surprised that Microsoft is outlasting them.

A small fraction of users care about what engine their browser is using. They care that the websites they visit work, and WebKit certainly has the edge over Opera's old engine on that point.

Re:Companies can work together just fine... (0)

Anonymous Coward | about a year ago | (#43055835)

As a long time Opera user, I welcome the change. As long as they keep the features that make Opera so powerful, this will be the best of both worlds.

Re:Companies can work together just fine... (4, Insightful)

Grond (15515) | about a year ago | (#43055125)

You don't think management was involved Apple's decision to use KHTML as the basis for Safari rather than Gecko (the Mozilla engine)? Or the decision to use an open source engine in the first place rather than creating their own proprietary engine? You don't think sales and marketing were involved in the decision to feature the open source nature of the engine when Safari was first announced [apple.com] ("Safari’s features include ... the industry’s best rendering engine based on KHTML, from KDE’s Konqueror open source project, to which Apple has made significant enhancements that will be contributed back to the open source community."). You don't think HR was involved in recruiting software engineers with experience working with open source projects?

The same is true of every other company that has used WebKit. Companies that base products on open source projects are not self-governing programmer utopias.

Re:Companies can work together just fine... (1)

Tough Love (215404) | about a year ago | (#43055199)

What was avoided here is the usual horde of slavering, shambling, mindless middle managers who usually bring every worthwhile software development effort to a pathetic halt.

Re:Companies can work together just fine... (0)

Anonymous Coward | about a year ago | (#43055269)

No, it was probably a cost cutting measure, nothing even remotely related to marketing.

Think about it for a second. There are so many companies all working on that engine, it's a win-win-win situation for them. They reduce research and development costs by A LOT, look at MS how much it spent on IE to bring it to it's current status, then they get a finished product that is high quality, or at least as good as their competitors and they get karma/marketing points by having their names plastered all over the open source community.

Google did this first, they helped Firefox to really take off, and won so big, they now have their own browser with a healthy market share.

Re:Companies can work together just fine... (4, Informative)

Grond (15515) | about a year ago | (#43055353)

Google did this first, they helped Firefox to really take off

No, Apple announced Safari in January of 2003, years before Google began seriously funding Mozilla through search referral kickbacks and hiring a few engineers to work part-time on Mozilla projects. Work on WebKit started within Apple even further back, in mid-2001.

Re:Companies can work together just fine... (0)

Anonymous Coward | about a year ago | (#43055863)

Except Safari never got popular.

Re:Companies can work together just fine... (0)

Anonymous Coward | about a year ago | (#43056851)

Safari is responsible for two thirds of all mobile web browsing. That's objectively pretty popular.

Re:Companies can work together just fine... (0)

Anonymous Coward | about a year ago | (#43057341)

Depending on which stats you believe, mobile web browsing is 13-15% and iOS is 25-55% of that. That is, about as popular as desktop Opera.

People tend to forget that despite media focusing exclusively on OMGnewshinies, old and boring PCs don't just disappear.

Re:Companies can work together just fine... (4, Informative)

blacklint (985235) | about a year ago | (#43055321)

From the guy who chose to base Safari of KHTML [donmelton.com] : "But I chose the engine we used — with my team’s and my management chain’s support, of course —"

Sounds like an engineering-led decision to me.

Re:Companies can work together just fine... (1)

Grond (15515) | about a year ago | (#43055369)

Sounds like an engineering-led decision to me.

Engineering-led, sure, but that wasn't the claim I was responding to. The claim was "Companies can work together just fine... ...just as long as you keep managers, marketeers, sales people and HR out of it." Management was clearly involved.

Re:Companies can work together just fine... (1)

oever (233119) | about a year ago | (#43055423)

Management was involved but did not decide. Don Melton decided to use KHTML [donmelton.com] :

But I chose the engine we used -- with my teamâ(TM)s and my management chainâ(TM)s support, of course -- ...

That's not really involved though (0)

SuperKendall (25149) | about a year ago | (#43056197)

Just letting someone do what they want is not "involvement". Involvement is stopping someone from doing what they want, or making a choice for them.

Mere support is not involvement.

Re:Companies can work together just fine... (2)

BitZtream (692029) | about a year ago | (#43055651)

Having embedded both Gecko (mozilla's rendering engine) and WebKit into various applications, it doesn't take any sort of silly thinking to understand why they picked WebKit.

Gecko is a fucking mess that no self respecting programmer will get with in half a billion miles of. It is a shining example of how to write shitty code. It is in fact the most bloated, buggy, confusing pile of shit I've ever had the dis-pleasure of working with.

WebKit is far from a trivial beast to work with, but its a HTML layout engine, which is a non-trivial task. WebKit makes sense and was 'designed', not thrown together by idiots who should have been fired in 2000 from netscape.

Management was certainly involved, but I'd bet a weeks pay that none of the developers involved even gave Mozilla a second thought. The first glance at the code base makes it clear that the Mozilla project is not something you really want to be involved with unless you want to learn how 'to do it wrong' by example.

Re:Companies can work together just fine... (1)

Anubis IV (1279820) | about a year ago | (#43056383)

...just as long as you keep people out of it.

FTFY

If what you said was true and there weren't any problems so long as it was just engineers, programmers, and the like on a project, then a number of forks of open source projects would simply not exist at all. The fact is, everyone fails to get along at some point, though I'll readily admit that some of the types you left off that list are more capable of getting along than some of the ones you put on that list..

Re:Companies can work together just fine... (1)

hairyfeet (841228) | about a year ago | (#43056445)

Everyone acts like this is a good thing but it is NOT and here is why: First of all...doesn't anybody remember what happened with IE 6? How you had every damned site coded to IE 6 ONLY and any time a bug came out for IE 6 it spread like wildfire? Having everybody on the same thing just ain't a smart move.

Second nobody seems to be talking about the ugly truth of why Opera had to go Webkit, because the only way they could get within a million miles of iPad is as a pathetic skin for Apple's browser. I'm sorry but that level of douchebaggery and control was NOT cool when MSFT did it and it sure as hell ain't cool just because its coming from Cupertino. We are talking about a company that was able to change the entire direction of HTML V5 from an open codec to a patent trolling H.264,until they got stopped were controlling the prices of eBooks and are able to kill technologies like Flash and the Presto rendering engine by simply saying its verbotten on the iPad.

The future is NOT looking bright where I am sitting folks, everybody is cheering the death of MSFT but I wanted them replaced by something better not WORSE, didn't you? Between Google locking down bog standard X86 hardware so you can't install another OS without jumping through a bunch of CLI hoops to Apple controlling which way the web goes frankly this is looking to end up worse than when MSFT was ruled by Darth Gates and that's pretty damned bad.

We need the web to stay open as much as possible and be as patent free as possible but just handing control from Redmond to Cupertino is just switching one master for another when what we need is no masters at all. Hell maybe I'm wrong, the public sure does seem to love paying crazy prices for glorified game consoles so maybe I'm old fashioned in wanting a non corporate controlled web, but all these changes we've had lately? NOT for the better IMHO.

Re: Companies can work together just fine... (1)

cyber-vandal (148830) | about a year ago | (#43056565)

Yeah a proprietary Web browser controlled by a convicted monopolist is just the same as an open source rendering engine that has multiple contributing companies, two of whom are bitter rivals.

Re:Companies can work together just fine... (0)

Anonymous Coward | about a year ago | (#43056575)

One's closed blob that never got updated by sole developer to fix bugs and support standards, other's continuously improved by bunch of competing developers and if you don't like the direction it goes you can fork it and add your own patches. Totally same situation.

And the stab at iPad is completely misguided, as it doesn't matter what engine the desktop Opera uses - every alt browser on iOS has no rendering engine at all and just hands HTML to the viewer component. IOW, Opera there is basically a picture viewer for Opera Turbo, same as Opera Mini from long ago.

So yeah, many developers from many companies working towards a single goal of standard compliance and uniform support for features across browsers is a Bad Thing.

Re:Companies can work together just fine... (1)

ShoulderOfOrion (646118) | about a year ago | (#43058457)

As long as Mozilla and IE continue to be viable, I don't think your concern is valid with regard to the browser.

As for your other points, particularly the abominable choice of H.264 instead of a free codec for HTML5, you're spot on.

Re:Companies can work together just fine... (1)

hairyfeet (841228) | about a year ago | (#43059723)

Nice to see somebody who isn't a fanboy and can see the risk here. And I'm so damned sick of everyone screaming "M$ Shill" if I don't drink the iKoolaid or kiss Google's ring. Who was calling for MSFT to be broken up when the evidence came to light in the antitrust trial? Oh yeah that was ME, same as i thought Intel deserves a hell of a lot more than a couple billion bribe to AMD to make a decade of backdoor bribery go away.

Why is it that nobody can see that being the biggest corp on the planet brings with it serious dangers to the web and openess? It was wrong and I screamed bloody murder when MSFT tried to control the web through IE 6, and I'm gonna scream just as fucking loudly now that Apple is controlling the web by saying "Do what we say or it don't run on the iPad" as they did with HTML V5 video. for what its worth, know who I was rooting for? NOT MSFT who simply aped Apple, I thought and still do that a minimum of Drac or Theora should have been mandatory. But apparently its totally okay to stick a "pay your $699 license fee" troll as the "standard" for video across the web as long as it was blessed by St. Jobs of Cupertino. A good rule of thumb...if MSFT would have pulled the exact same shit, would you be cool with it? I sure as hell wouldn't and just because Apple builds for hipsters doesn't magically give them a "be a douchebag free" card.

Why won't this paradigm work on an Office Suite? (2)

bogaboga (793279) | about a year ago | (#43054971)

Why won't this arrangement work on an Office Suite?

That's the question.

Re:Why won't this paradigm work on an Office Suite (4, Insightful)

erroneus (253617) | about a year ago | (#43055039)

Critical mass.

*.DOC(X) is not just he most universally accepted format for word processing documents, it's the most universally EXPECTED format for word processing documents.

And then there's the ridiculously high amount of integration which is the expected norm for all of this. It's more than just office. It's everything it touches. And as we saw when Microsoft took an active role in attempting to stop ODF from becoming an ISO standard and we saw it in how Microsoft inexplicably got an incomplete and impossible to implement standard fast-tracked through the same process.

They have no shame or sense of morality when it comes to defending their territory and will never allow anything to get in their way.

Now, if there were such a collaboration I'd be all over it. Right now? I just can't see it happening.

Re:Why won't this paradigm work on an Office Suite (3, Interesting)

bogaboga (793279) | about a year ago | (#43055177)

*.DOC(X) is not just he most universally accepted format for word processing documents, it's the most universally EXPECTED format for word processing documents.

But I remember IE was in this exact position not many years ago. Heck, you could hardly "get anywhere" around the web without hitting so called "IE only" sites. What happened in this case?

Re:Why won't this paradigm work on an Office Suite (0)

Anonymous Coward | about a year ago | (#43055245)

Proprietary IE features were never as widely used as some people claim. In most cases those "IE-only" websites were 98% semi-standard HTML/CSS/JS, and the developers just didn't want to support the non-standard shitbox that was Netscape 4. Very few public websites had an ActiveX plugin or anything of that nature.

Web front-ends tend to be redesigned every few years so there was plenty of opportunity to fix this.

Re:Why won't this paradigm work on an Office Suite (1)

BitZtream (692029) | about a year ago | (#43055681)

Microsoft upgraded IE and caused all those IE6 sites to not work properly in newer versions of the browser so the issue had to be addressed regardless of outside influence.

Microsoft killed IE6, not anyone else. It wasn't until Microsoft killed it that anything else changed.

Re:Why won't this paradigm work on an Office Suite (1)

saleenS281 (859657) | about a year ago | (#43057899)

IE had horrible issues with picking up viruses, and Microsoft let the application fester in it's own filth. Eventually it got to the point you couldn't browse the web with IE and not get a virus - "power user" or not. So Mozilla started picking up steam - then they added extensions which brought all this cool new functionality, and suddenly it caught on.

Re:Why won't this paradigm work on an Office Suite (1)

Kjella (173770) | about a year ago | (#43055309)

Critical mass and a lack of companies that indirectly make money off it. The kernel is free but Red Hat makes money selling service and support, Webkit and the web browsers are free but Google makes money selling web services - or giving them away and making ad revenue, same thing. Who makes money off Open/LibreOffice? The StarOffice business model never really worked for Sun and Oracle simply killed it outright. The Linux distros a little bit maybe, but desktop Linux has never been a moneymaker. On Apple's products you've got other choices, Google wants to push Google Docs, there's other apps for Android and there's no Android port anyway.

You have of course all the companies producing MS Office documents who'd be interested in offering a cheaper solution but their customers probably have other solutions forcing them to go MS anyway. And really at the bottom of the ladder there are those who'd like a cheaper alternative to MS Office, but then they're usually on a tight budget and not interested in hiring people to fix software way outside their core business. Now if you could unseat Microsoft then yes I suppose they'd all together would be enough, but none of these are really rocking the chair as it is. To put it a little cynically, there's plenty money in being Microsoft but there's not so much money in replacing it with a free and open standard, then nobody really makes much money off basic office documents.

Re:Why won't this paradigm work on an Office Suite (1)

AmiMoJo (196126) | about a year ago | (#43057051)

There is nothing stopping you sending ODF files to MS Office users, they can open them just fine with any version of Office from the past five years.

Re:Why won't this paradigm work on an Office Suite (1)

erroneus (253617) | about a year ago | (#43057273)

Prolblem is a lot of businesses and individuals are still on 2007.

Re:Why won't this paradigm work on an Office Suite (1)

hairyfeet (841228) | about a year ago | (#43057349)

Do you HONESTLY think if only ODF would have been approved it would have made a damned bit of difference? Like them or hate them MSFT did get a few things right, one of them is MS Office. With LO it feels like what it is, a mish mash of separate programs bolted together that don't really belong together and for the longest time Writer was the only program that got any love, the rest didn't get squat comapred to Writer. with MS Office its an actual suite, with everything working together and honestly Excel and Access are pretty impressive in the amount of work you can do with them and the entire ecosystem that has built up around them.

There are some places where FOSS got it right, browsers being a damned good example. Office Suites? Not so much. The other field where MSFT really doesn't have any competition of note is groupware which they also do REALLY well but frankly I don't know why MSFT wasted that money getting OpenDoc or whatever the hell its called pushed through because everybody has stuck with Doc(X) so neither ODF or OpenDoc really made a dent and when you compare the latest MS Office, hell MS Office 2K3 or 2K7 even to the latest LO you can see why, MS Office is the better product. I wish it weren't so because lord knows the market works better with real competition but LO is AMD to MSFT's Intel, they ain't even in the same ballpark.

Re:Why won't this paradigm work on an Office Suite (2)

erroneus (253617) | about a year ago | (#43057433)

it is supposed to make a difference when government entities require that ISO standards are followed when possible and one exists for documents, that it should be used. So if/when government follows its own laws and policies, they would have to select software which utilizes an accepted ISO format. If Microsoft wasn't able to manipulate its way through, there would have been some really tough questions to answer.

And let's be clear on how important an issue this is. We're talking about government record keeping. We are talking about file formats wihich should be able to stand the test of time... 10 years, 50 years, 100 years from now if documents are to be accessed, which format do you think would be most accessible? A clean and clearly defined spec (ODF) or an XML formatted memory dump (OOXML)?

As for MS Office getting it right? Do you actually use MS Office? I more than use it, I support it so I get to identify and manage problems associated with its use. I encounter problems all the time... well not "all" the time, but often enough to keep me employed.

Re:Why won't this paradigm work on an Office Suite (4, Funny)

Xemu (50595) | about a year ago | (#43055195)

Why won't this arrangement work on an Office Suite?

That's the question.

The transformation of the office Paradigm will be disruptive and imperative in a cloud computing initiative and to leverage Web 3.0 and deliver a truly seamless Prosumer solution .

Re:Why won't this paradigm work on an Office Suite (4, Funny)

wonkey_monkey (2592601) | about a year ago | (#43055601)

Aww, you were only missing "synergy" to win Bullshit Bingo.

Re:Why won't this paradigm work on an Office Suite (0)

Anonymous Coward | about a year ago | (#43057693)

He used a revolutionary, far-thinking communication style to avoid the pitfalls of hyper-implementing the term. Nice forward thinking, GP. Blast fax kudos all around!! (I would include an optimistic pie-chart ---it would even have rounded corners--- but there's no slashcode options for that.)

-Sincerely, Marketing

Re:Why won't this paradigm work on an Office Suite (1)

Bearhouse (1034238) | about a year ago | (#43055775)

Mod up. This is really what we need - it would truly knock a big nail into MS Office's coffin.
Not that I'm against either MS Office or indeed MS per se. Apple is just as bad.
Goggle has progress to do; you can open a "pages" document in Google docs, but not then save it in another format.
For the love of Christ, how hard can it be?

I'm just so sick of trying to manage, and use, documents with needlessly opaque and complex formats.

It's a losing strategy, but still a powerful one, "I own your data, because I own the format you create and store it in".

People here froth at the mouth about personal data, but this is equally important. I have shitloads of files, in various formats, many proprietary, going back years. Please give me one ring to own them all, FOSS.

Is there any reason (0)

mozumder (178398) | about a year ago | (#43054975)

For Mozilla to continue developing their own engine?

I see them dropping and switching to WebKit, and maybe even Microsoft dropping their engine eventually.

Re:Is there any reason (3, Insightful)

erroneus (253617) | about a year ago | (#43055045)

The moment "everyone" goes to the same platform is the moment everything slows to a crawl or even a stop.

Re:Is there any reason (2)

Ambvai (1106941) | about a year ago | (#43055297)

We have never sought to become a monopoly. Our products are simply so good that no one feels the need to compete with us. -CEO Nwabudike Morgan, Alpha Centauri (Fictional quote, by the by.)

Re:Is there any reason (1)

ninetyninebottles (2174630) | about a year ago | (#43055591)

The moment "everyone" goes to the same platform is the moment everything slows to a crawl or even a stop.

I disagree. Monopoly, slows innovation to a halt, because there is no motivation to improve to gain share. Apple, Google, Opera, etc. still want to gain share from one another and they still need to advance Webkit to support those advancements in applications and services. The nature of copyleft prevents the normal monopoly issues (although patents can still introduce that problem).

Re:Is there any reason (0)

Anonymous Coward | about a year ago | (#43058257)

The nature of copyleft prevents the normal monopoly issues (although patents can still introduce that problem).

Except WebKit isn't copyleft. Actually, most software that runs the web isn't. Front-end stuff? Almost always MIT-licensed. Back-end? Apache, nginx, PostgreSQL, *BSD, memcached, nodejs, lighttpd, redis, Varnish, PHP, Perl, Python, Ruby... yeah, none of it is copyleft.

Stallman has done well in convincing the gullible that we need a long, complicated license to ensure companies "give back," but it's obviously not the case.

Re:Is there any reason (1)

ninetyninebottles (2174630) | about a year ago | (#43058633)

Except WebKit isn't copyleft.

The core components are LGPL, which means if it is distributed contributions have to be submitted back. That's pretty copyleft in my book, in fact it is about the most copyleft license I know of that is practical for a library that the developers want to be widely used.

Re:Is there any reason (1)

AmiMoJo (196126) | about a year ago | (#43057181)

Webkit is just a layout engine. Network operations, rendering and script execution is all handled by the browser, which should also be sandboxing the layout engine anyway. A flaw in Webkit shouldn't cause a major problem in a well designed browser.

Re:Is there any reason (4, Interesting)

bill_mcgonigle (4333) | about a year ago | (#43055109)

Here's a pretty good discussion [arstechnica.com] of the issue.

Selfishly, I hope Mozilla never adopts WebKit because both the Gecko and WebKit teams tend to stagnate when nobody is out-classing them, but they both have strong competitive instincts and everybody benefits from that.

And, frankly, I think the aesthetics of Gecko are much nicer on Linux than Webkit. I use Chromium for Google Apps because I pretty much have to, but the text layout and rendering really has room for improvement. I do too much work in a browser all day to use that as a primary tool until the necessary work is completed on my platform.

Re:Is there any reason (1)

Tough Love (215404) | about a year ago | (#43055219)

Mozilla should fork Webkit, GPL it, then compete on that basis. More efficient all round. We will still have great competition and rapid evolution, what we won't have is the nasty hairball that is Gecko sandbagging Mozilla progress.

Re:Is there any reason (2)

Elbereth (58257) | about a year ago | (#43055255)

We could call it... KHTML [wikipedia.org] and make it a part of KDE!

However, to be fair, KHTML is actually LGPL.

Re:Is there any reason (1)

allo (1728082) | about a year ago | (#43055841)

and the lgpl-part is, why companies like apple can use it without opensourcing their browser.

Re:Is there any reason (0)

Anonymous Coward | about a year ago | (#43056165)

The sheer fact that you call Gecko a "nasty hairball" shows how objective and impartial you are, and just how seriously you ought to be taken.

Perhaps you could also contact Microsoft and tell them to working on the filthy dishrag that is Windows? Or contact Apple and tell them to stop wasting everyone's time on the.. uh, fetid dishwater that is OSX when they could just as easily contribute back to BSD?

Translation: hey, I don't like Gecko, and I think that it would be better for Mozilla to dump something that has numerous advantages over the competition simply because I think my uneducated opinions mean something.

Re:Is there any reason (1)

Tough Love (215404) | about a year ago | (#43056727)

The sheer fact that you call Gecko a "nasty hairball" shows how objective and impartial you are, and just how seriously you ought to be taken.

The sheer fact that you do not understand that Gecko is a nasty hairball shows that you do not have the slightest clue about anything to do with software design, and nobody should take you seriously.

Exactly how does this improve MathML? (0)

Anonymous Coward | about a year ago | (#43056403)

Google just decided to remove MathML from Chrome 25 [maths-info...e-jeux.com] , so much for "great competition and rapid evolution" for academic e-books.

Re:Exactly how does this improve MathML? (1)

Tough Love (215404) | about a year ago | (#43056737)

Proved my point. Mozilla foundation should GPL KHTML (call it MozML?) and restore MathML.

Re:Is there any reason (1)

kangsterizer (1698322) | about a year ago | (#43058061)

I don't know. I don't find webkit much better than gecko as a user. I mean, seriously, if you remove all the "webkit-only" websites, I don't see anything faster in chrome than in firefox. Sometimes I bench webgl out of curiosity (mainly because the other pages are all instant on both browsers), and some webgl demos are 2fps faster on one or the other.
When I'm on Android, Firefox is actually noticeably faster than Chrome, for some reason (memory footprint maybe?).

Thus, I'm not sure what the gain would be with webkit (minus being able to load webkit-only sites). Easier multiprocessing, yes, but it doesn't seem to be that much of a big deal. Firefox has as much or as little security issues as Chrome, and it crashes as rarely (if not more rarely in fact.. i'm pretty sure my chrome crashes/freezes/what not more often, since Firefox virtually never does).

Re:Is there any reason (0)

Anonymous Coward | about a year ago | (#43055145)

Then we get IE6 again, great idea.

How about fixing memory management? (1)

Anonymous Coward | about a year ago | (#43055069)

I'm not knowledgeable enough to understand the deep innards, but the first browser that doesn't slowly (or sometimes quickly) consume all my Mac's RAM will win my undying allegiance.

There's an extensive thread about this problem with Safari here: https://discussions.apple.com/thread/3255375?tstart=0

Some people have reported that disabling JavaScript fixes the problem, but that obviously isn't a realistic solution. But it leads me to suspect that in the race for bragging rights about having the "fastest JavaScript", developers have prioritized execution speed over memory efficiency. Personally I'd be happy with a slower JavaScript that paid attention to memory use. Just like I'd like fewer megapixels but better low-light performance in my digital camera.

Re:How about fixing memory management? (0)

Anonymous Coward | about a year ago | (#43055201)

You're essentially talking about a *platform* not a piece of software. Your comment is on par with "show me the first computer that doesn't run out of memory and I'll buy it". Our web browsers now have a compiler, hardware drivers, etc. It's what is running *on* them that is probably responsible for about 50% of aberrant memory usage. The other 50% is probably feature creap/design related.

Re:How about fixing memory management? (0)

Anonymous Coward | about a year ago | (#43055275)

Javascript performance in Safari is Apple's responsibility. Google's Chrome Javascript engine is totally different, named V8.

I don't think either javascript engines are included in Webkit governance.

Re:How about fixing memory management? (0)

Anonymous Coward | about a year ago | (#43055639)

if disabling JavaScript fixes your problem, it's probably not caused by webkit. The JavaScript engine is a separate piece of software, webkit is "just" the rendering engine.

Re:How about fixing memory management? (2)

Carewolf (581105) | about a year ago | (#43055897)

That is just the Safari Mac defaults. It is using up to 1Gbyte on JIT code, and even more on various caches, but it should throw it out when hit with a memory pressure event. The iOS defaults are much much smaller of course.

Re:How about fixing memory management? (1)

Jeremi (14640) | about a year ago | (#43056037)

But it leads me to suspect that in the race for bragging rights about having the "fastest JavaScript", developers have prioritized execution speed over memory efficiency. Personally I'd be happy with a slower JavaScript that paid attention to memory use.

You can get 16GB of RAM these days for less than $100. In a couple of years you'll probably be able to get 32GB for that amount. CPU speeds, OTOH, aren't going to get a whole lot faster (more cores notwithstanding). So I think there is a good case to be made that trading memory for CPU cycles is a good strategy in 2013 (along with parallelizing whenever possible).

Why is webkit on Kindle so poor? (0)

Anonymous Coward | about a year ago | (#43055147)

If webkit is so good, why is the browsing experience on a Kindle 3g so awful?

Re:Why is webkit on Kindle so poor? (1)

excursive (2823185) | about a year ago | (#43055389)

The Kindle 3G doesn't have a powerful processor or gobs of memory. The display refreshes slowly. The internet connection is not very fast. Maybe all the transactions go through Amazon's servers (as they do on the Fire unless you turn that off). Amazon probably had to make many additions to the code to adapt to the Kindle's physical interface. In other words, there are several potential reasons. What in particular do you not like about it?

Re:Why is webkit on Kindle so poor? (1)

tyrione (134248) | about a year ago | (#43055885)

Hey genius, every platform is responsible for porting WebKit to their API needs and platform. It requires work.

Antitrust (0)

Grond (15515) | about a year ago | (#43055257)

When Microsoft dominated the browser market by abusing its market power in the operating system market, that was an antitrust problem. Should we not be concerned when a group of competitors collude to dominate the HTML rendering engine market? It's a different kind of market than the browser market, but it is still a market, and a dominant player will cause problems for both competitors and consumers. For example, even though the WebKit browsers are generally free, WebKit's dominance is steadily leading to a lack of choice and a security monoculture. Witness the recent FillDisk exploit [ubergizmo.com] , which only affects WebKit browsers.

This is an example of how open source can allow competitors to collaborate in ways that might ordinarily raise more antitrust scrutiny. Here, several companies for whom an HTML engine is an input have collaborated to reduce the cost of that input. In doing so they have effectively pushed a competitor (Opera) out of the HTML engine market. Firefox and IE's usage share have also steadily been falling for years in favor of WebKit browsers. Will we wait until WebKit has a stranglehold on the market before taking corrective action, like we did with IE?

Re:Antitrust (1)

Anonymous Coward | about a year ago | (#43055509)

No. Being a monopoly is perfectly legal, abusing the power is not. They are not abusing their power, and they are not even close to being a monopoly.

Opera were not forced except by the fact that writing an HTML renderer these days is hard, and they are a small company. By trying to keep up, they would have wasted effort that could better be used otherwise (everything around the renderer).

Basically, you have no idea what you are talking about and just throw around words that make you sound clever.

Re:Antitrust (1)

Grond (15515) | about a year ago | (#43055699)

No. Being a monopoly is perfectly legal, abusing the power is not. They are not abusing their power, and they are not even close to being a monopoly.

There is much more to antitrust law than monopolies. For example, there are "contracts, combinations..., or conspiracies in restraint of trade or commerce" in violation of the Sherman Act. I did not suggest that WebKit was a monopoly. I suggested that competitors (such as Google and Apple) were colluding to dominate the HTML rendering engine market. That kind of concerted anticompetitive action is precisely what the Sherman Act is aimed at preventing.

I am not the first person to suggest that collaboration between competitors via open source projects can raise antitrust concerns. See, e.g., Stephen M. Maurer, The Penguin and the Cartel: Rethinking Antitrust and Innovation Policy for the Age of Commercial Open Source [ssrn.com] .

Basically, you have no idea what you are talking about and just throw around words that make you sound clever.

I am an attorney. You may want to rethink that accusation.

Re:Antitrust (0)

Anonymous Coward | about a year ago | (#43056003)

Basically, you have no idea what you are talking about and just throw around words that make you sound clever.

I am an attorney. You may want to rethink that accusation.

Must...not...make...obvious...lawyer...joke....

Re:Antitrust (0)

Anonymous Coward | about a year ago | (#43056765)

Being an attorney doesn't automatically prevent you from speaking out of your ass.

For a start, you didn't even mention what harmful actionsexactly comprises that Google-Apple "collusion" except for "putting out good product". I wasn't aware that Apple and Google sell HTML rendering engines. That's kinda hard for them to do with Webkit being permissively licensed and all.
So, what exactly of Apple and Google's actions is illegal and how they profit from Presto's demise?

Re:Antitrust (0)

Anonymous Coward | about a year ago | (#43058757)

For an attorney, your attention to detail is seriously lacking.

Exhibit A: Your own link on the FillDisk exploit. In that link (and every other link on the exploit, since its factual), it states that Opera and Internet Explorer were both vulnerable. Both browsers do not use WebKit.

Hardly "only affects WebKit browsers." Perhaps you should limit your comments to legal issues and leave the technical side to people who actually understand what their talking about. See security monoculture may sound witty, and it conjures up images of a biological monoculture that's vulnerable to being wiped out by a single virus or disease.

But software is different. Yes, a standardized platform creates a single, more attractive target for attackers. But it also increases the attention that the code gets...just check out the summary for just how much code review is happening within WebKit. This makes WebKit more akin to an encryption algorithm where security researchers around the world are invited to participate in the process.

The only way for software to be considered secure is for it to be reviewed as widely as possible. WebKit's popularity, open development process and open source make it more secure than any other rendering engine.

Re:Antitrust (0)

Anonymous Coward | about a year ago | (#43055939)

I see this as more of an mirror of the optical disc market.

The DVD forum was a collaboration between so many companies.
They all worked and built on the same spec.
They were allowed to research and create new derivative specs as long as everyone else could use it.
There was even huge disagreements (DVD+/-R)
But for the most part, it worked out well.
Think of the disc market if there was even 10+ competing disc formats. That would be horrible.

These 3 are working on ONE implementation of the spec, of which there are 3 main competing engines and various smaller secondary competitors.
All 3 are still capable of working on their own research with the engine, they can then discuss with the others ideas to be added in to the spec at WHATWG and W3C mailing lists with their experimental specs, possible future implementations and then the others get to working on other ideas. They can still even fork it if they wanted to, right?

There is still going to be competition, even if they are using the same base engine.
And more to the point, the real competition with browsers has NEVER been the renderer, it has been the features built on top of said renderer.
At a time IE6 was still better than Firefox, up to 1.5 in fact, FF previous to these versions was just plain bad.
IE6 had a tabbing extension for it as well, but of course people weren't as clued in to IE extensions as they weren't really that big of a thing.
And it actually worked really well. I just cannot remember the name of it for the life of me.
The differences between IE6 and FF1.5 at the time weren't that huge and could, for the most part, be solved very easily with some CSS and JS.
But MS were still behind in a lot of the more advanced features, regardless.
These days Microsoft are actually competing though, and all of the current engines are actually pretty damn well up to date on many of the main features.
So there is basically no real advantage sharing an engine right now. Features and ease of use are the things that will get you users.
It was the reason Chrome exploded in use because it was such a simple and quick browser compared to FF and IE. Features of the renderer weren't even that different then, besides a few of the more experimental things.

So people worrying that things will just become the webkit web are being silly.
Even they don't want that to happen. Things stagnate in monopolies, that would be the worst thing to happen.
And in all honesty, if things were to somehow get to a state of there being The One Renderer To Render Them All, someone can easily come in, steal the source, re-arrange it entirely and just release it closed source.
Sure people can come in and easily decompile it, but as long as they re-arranged the code and featureset well enough, nobody would ever find out.
A really good copy of an open source base would look completely unique, even if it had the same features. And given that someone was in code, they'd likely be smart enough to know how to go about hiding that fact.
Nobody would stand for an open source monopoly like that if it did happen. So don't worry. The only bad thing that will happen is we will get Great Websites out of it. The horror.

This is a very good GPL myth debunking (0, Flamebait)

hotfireball (948064) | about a year ago | (#43055259)

So can we now just close that utter bullshit statement about GPL as being world-best license to keep project alive?

Re:This is a very good GPL myth debunking (0)

Anonymous Coward | about a year ago | (#43055357)

What statement would that be? I'm sure you'll be perfectly willing to provide a quote or citation.

Re:This is a very good GPL myth debunking (0)

Anonymous Coward | about a year ago | (#43055421)

In fact, what does this have to do with the GPL at all? Is there some other GPL browser engine that's technically comparable to WebKit but falling behind due to the licence? Did you mean to post that on a different story?

... so long as it meets their interests (5, Interesting)

Anonymous Coward | about a year ago | (#43055303)

I interned on the Chrome team 3 years ago. Google was still building up towards being a major player on Webkit. This lead to issues when Google's interests didn't match Apple's.

For example, there was a bug on a KURL object (held a url in it or something). According to specs, it was supposed to wipe out certain data whenever such and such an event occurred. I do not remember the specifics. But, Webkit had this bug where it did not do that, going against its own documentation and specs. This was causing Chrome some issues, so they wanted to patch the problem.

Apple refused to accept the patch- there were many places where Safari RELIED on the bug to work. If you wanted to fix the bug in Webkit, Apple would have to fix Safari. Since Apple had the majority of commiters/contributors, they could outvote any decision, open source be damned.

In the end, Google made a GURL object for their own purposes, which was essentially the same object, without the bug.

*Note: I may be mistaken on many of the details here, or the specific object names (it was a while ago), but the overall scope of the issue, I'm telling it to you like I remember it happening.

Re:... so long as it meets their interests (1)

Skapare (16644) | about a year ago | (#43055415)

This is exactly why projects should be run by the community instead of a for-profit corporation. Such corporations simply have not learned to really work together for a common goal. In theory, it is impossible for them to do so, anyway, since, by definition, the only goal a for-profit corporation can have it to make a profitable return on the investment of its owners.

Re:... so long as it meets their interests (2)

BitZtream (692029) | about a year ago | (#43055725)

Right, because they exact same thing wouldn't happen with 'the community' in charge.

THERE ARE ALWAYS CONFLICTS, even in your fantasy hippie commune. Not everyone gets what they want in the real world.

Re:... so long as it meets their interests (-1)

Anonymous Coward | about a year ago | (#43055817)

I interned on the Chrome team 3 years ago. Google was still building up towards being a major player on Webkit. This lead to issues when Google's interests didn't match Apple's.

For example, there was a bug on a KURL object (held a url in it or something). According to specs, it was supposed to wipe out certain data whenever such and such an event occurred. I do not remember the specifics. But, Webkit had this bug where it did not do that, going against its own documentation and specs. This was causing Chrome some issues, so they wanted to patch the problem.

Apple refused to accept the patch- there were many places where Safari RELIED on the bug to work. If you wanted to fix the bug in Webkit, Apple would have to fix Safari. Since Apple had the majority of commiters/contributors, they could outvote any decision, open source be damned.

In the end, Google made a GURL object for their own purposes, which was essentially the same object, without the bug.

*Note: I may be mistaken on many of the details here, or the specific object names (it was a while ago), but the overall scope of the issue, I'm telling it to you like I remember it happening.

And Apple were right. Merging in a patch that breaks Webkit is utterly wrong. If Google had been serious about the fix they would have patched the bug and also all the places in Webkit that they had then broken. Instead Google followed their usual route - a half-assed change that only works for them. Google is the new Microsoft: embrace, extend .... and soon extinguish.

Re:... so long as it meets their interests (0)

Anonymous Coward | about a year ago | (#43055991)

If you read this correctly you would know that Apple was wrong. They refused a bug fix to the rendering engine. A fix that that would make the engine work the way the documentation and specs said it should work. This was because Safari was using the undocumented bug. Not because WebKit was using it. Reading and comprehension fail causing you to come to exactly the wrong conclusion. Doh!

Re:... so long as it meets their interests (1)

Tumbleweed (3706) | about a year ago | (#43056103)

And Apple were right. Merging in a patch that breaks Webkit is utterly wrong. If Google had been serious about the fix they would have patched the bug and also all the places in Webkit that they had then broken. Instead Google followed their usual route - a half-assed change that only works for them. Google is the new Microsoft: embrace, extend .... and soon extinguish.

You seem to have misread the parenter's description of the problem, and are possibly also confusing WebKit with Safari. He said there was a bug in WebKit which *Safari* relied on. Apple refused to fix the bug in Safari, and refused to accept Google's WebKit bug fixes. This, if true, is COMPLETELY a problem with Apple, not Google.

What Hapened to KHTML? (0)

Anonymous Coward | about a year ago | (#43055365)

Does anyone know what happened to KHTML?

Re:What Hapened to KHTML? (1)

ninetyninebottles (2174630) | about a year ago | (#43055643)

Does anyone know what happened to KHTML?

It is still the default in Konqueror although many users swap it out for Webkit. Kubuntu, probably the largest KDE distro, dropped Konqueror for a Webkit based alternative, so the KHTML fork of the code seems pretty close to dead from my perspective.

Re:What Hapened to KHTML? (0)

Anonymous Coward | about a year ago | (#43055937)

Stritcly speaking, WebKit is the fork. Credit where its due.

Re:What Hapened to KHTML? (1)

ninetyninebottles (2174630) | about a year ago | (#43056325)

Stritcly[sic] speaking, WebKit is the fork. Credit where its due.

Strictly speaking, they're both forks of the same code. While some people use the term "fork" to try to indicate a spin off of a code base, that sort of connotation becomes really murky really fast. Is LibreOffice or OpenOffice the fork? It all depends upon your perspective. In truth, like forks in the road, when code diverges both divergent code bases are forks.

Monoculture (3, Interesting)

Alain Williams (2972) | about a year ago | (#43055395)

Much as I like the idea of competitors working together I do have a slight concern that a security flaw found will be exploitable on many platforms. OK: more developers working to kill bugs, but this code is large and complicated.

Does it matter (1)

Chuck Chunder (21021) | about a year ago | (#43057049)

Ie is there a practical difference between 30%, 50% and 90% of people's browsers being exploitable with a particular exploit? In any case it a phenomenally large number of people.

a parallel view (1)

burdickjp (2530248) | about a year ago | (#43055451)

This is a great example of how a market can work together to achieve a goal. I think this kind of collaboration should be encouraged by the state. Here's a similar example of how and how not to: In cameras there is a consortium which promotes a lens mount standard called four-thirds. A few companies have made cameras and lenses to fit it. More recently they made a standard called micro four-thirds. This is for mirrorless interchangeable lens cameras. Only Panasonic and Olympus have adopted it. Even so, a BUNCH of companies have now made similar cameras, all with different standards. Some companies have more than one standard for their MILCs! I understand each party has different goals, but some form of collaboration would be much better for the consumer, which is I guess my mistake. They don't care about consumers. They want you to buy their lenses and cameras and things.

Re:how a market can work together to achieve (1)

TaoPhoenix (980487) | about a year ago | (#43055567)

Since the Slashdot tradition is to apply caution to news-spin, here's my reply to your fair post.

I certainly agree that if multiple companies can agree to work together on something like a rendering engine, they all share the cost savings. That's the easy part.

Right now the blend of players is interesting - with Opera folding its efforts on Presto, the player mix is becoming "Them", who all that ever entails, Microsoft, and Mozilla. I wish Opera well but I never saw them as a "shaker" in the scuttle of the modern internet white water rapids. If either of the *other two* follow suit, then I think we'll see a real turbulent shift with an "odd man out" scenario.

We can agree that companies can achieve neat cost savings with a single render engine. The usual curse of Ant-Trust is when they *then* decide to jam something into it that users can no longer escape from.

Errror in blurb (0)

Anonymous Coward | about a year ago | (#43055541)

> Apple's Safari, Google's Chromium and Opera.

Isn't Chromium the operating system?

Should be "Chrome."

Re:Errror in blurb (2)

BitZtream (692029) | about a year ago | (#43055741)

No, Chrome is the Google branded closed source version of Chromium, which is the open source browser tied to Chrome. ChromeOS is the OS.

As is traditional of tech companies, the names they chose are confusing and retarded to anyone who doesn't follow tech religiously.

Re:Errror in blurb (2)

pthisis (27352) | about a year ago | (#43055903)

As noted, Chromium is the open-source browser project, Chrome is Google's branded version of that code (much as Netscape v6 and later and Mozilla were related).

The bigger error in the article is calling Opera one of the 5 major browsers. The summary then links to a page that isn't overall browser share, but is only non-mobile browser share. When you stop cherry-picking data, it becomes clear that:

a) There are only 4 major browsers; Firefox, Chrome, IE, and Safari all have about 10-30% of the market share, and nothing else has more than 5% share; and
b) The 5th largest browser is the Android stock browser. Opera is at best the 6th biggest browser, with 3.2% of the market.

Couple things to say on this... apk (1)

Anonymous Coward | about a year ago | (#43055815)

1 point others have noted, in "monoculture" (bad in ways, since it has parallels in 'the real world', ala diseases being like a grenade (in the disease here), that can take out a "single group" genetically for instance, whereas that isn't as possible in genetically varied groups as easily because of their having adaptations from diff. environments steering them to be 'different' & in some ways, better (or worse, conversely)).

The other is my disappointment in a way, with Opera doing it... they have done SUCH A GREAT JOB on their own engine, & it shows in 12.14 (especially the 64-bit model which I use) - I just do NOT understand WHY they'd "drop the ball" on something they've worked on for many, Many, MANY years now, & have running excellently!

(Then again - from what I understand, Mr. Hakom Lie (main dev of Opera iirc) is also on the standards board for the web, & perhaps HE even *thinks* it's "for the best" to even take a beating personally that way, giving up HIS motor/engine, so the "herd"/whole can gain from a SINGLE webplatform & engine that interprets it...)

* Pure speculation, I have no "inside info." on this, but it's the ONLY way it makes sense (especially on my point on Opera's "latest/greatest" 12.14 build - probably the LAST we'll see on the actual original "opera motor/engine"!).

APK

P.S.=> On the "flip side" - I can see the "web boys" giving THIS move to a consolidated SINGLE display motor/engine for the web being great for them personally: Less "hassles" having to build sites for diff. browser engines & doing the "pre-flight check" on browsers hitting their sites in order to do so, etc./et al...

... apk

So the only way to remain an Opera fanboi is to (0)

Anonymous Coward | about a year ago | (#43056385)

become a webkit apologist.

Thank Apple. (0)

Anonymous Coward | about a year ago | (#43055919)

Funny how it took Apple's work on creating webkit (as well as darwin, llvm, etc) to prove that an open source project can really make some amazing stuff. And yet you read slashdot any time and there is nothing but hatred for Apple, apparently hated for proving that open source can just work by being the first to build amazing and amazingly successful software on top of it. Put that in your pipe and smoke it, freetards.

Re:Thank Apple. (0)

Anonymous Coward | about a year ago | (#43058987)

Apple did not create Webkit. They just gave KHTML a new name, and started contributing some code. KHTML was as grassroots as an open source program can get. At the time, KDE critics were complaining about how we don't need another web rendering engine, since we have Netscape and stuff. Now everyone is glad that those critics were ignored.

Now more browsers will fail the MathML Acid test (0)

Anonymous Coward | about a year ago | (#43056333)

Now that Google has decided to remove MathML from Chrome 25, the MathML Acid Test [maths-info...e-jeux.com] will show which browser is doing the most for academic e-books.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...