[bzbarsky]

> you can always start an open source project that fixes these parallelization issues and start building out an engine that is better

Sure. We (Mozilla) are doing that right now.

> It'd probably be a 5-7+ year project

If there is no WebKit monoculture. If there is, such that the project has to duplicate WebKit bugs after reverse-engineering them, then it's a lot longer, if possible at all (because some of the bugs are parallelism bottlenecks).

Which is precisely my point. A WebKit monoculture would make it less possible to start such an open source project.

> Think long term.

You mean the one in which we're all dead?

Even if a hypothetical WebKit monoculture "merely" delays the advent of more-parallel rendering engines by 20 years, as opposed to preventing it altogether, that's still a huge loss in my book.

[malandrew]

I don't know if it does or does not. Maybe. Was the Opera browser engine doing anything to provide a more parallel engine option? If not, it arguable wasn't helping in this respect either.

Since WebKit is open source, can't you just submit bugfixes for the bugs that are parallelism bottlenecks? Seems like that would make a lot more sense than coding another engine to accommodate those bugs. If it truly is a bug, there shouldn't be any problem with submitting a bugfix and getting it accepted.

Since you're working on FireFox, are there any examples of WebKit "bugs" that prevent parallelism that you could not fix yourself? Does Mozilla have a team of WebKit engineers whose sole job is to fix WebKit so that those monoculture problems are mitigated and don't become a problem for other browser engines? At the end of the day, all you guys need to defend is the interface, not the implementation. Fixing each other's engines before bugs become features seems like a good way to accomplish this. ref: http://xkcd.com/1172/

The most important abstraction to fix isn't even a WebKit abstraction, it's a W3C abstraction. Everything was doomed from the get go because of the one-to-one relationship between the window and the document. I agree with Kay here about TBL & Co being shortsighted in what the web could have become if a richer interactive experience instead of a document based experience had been considered from inception.

Look at Twitter. That's not a document. That's an application. Each tweet in the interface is a document. Every tweet in that feed is a document that has been "transcluded" into the app Twitter built on top of a document. There needs to be a standard way to "transclude" documents with reference URL that allows interactivity. The fact that the only hyperlinking option we have today is the <a> tag is unfortunate. There need to be more ways of hyperlinking than an <a> tag. You need to be able to window directly to a document or document fragment at a different URL. The #hashanchors aren't sufficient, since they only describe a beginning, not an end to the fragment being excerpt. iFrames kind of provide an alternative, but this was never explored properly. The host app should also be able to provide a cached copy of the contents of any sub-document for performance and to guarantee that a copy of the referred document is always available in the parent context.

edit: downvote? srsly? without a response? downvoting is for comments that don't contribute to the conversation, not for comments you simply don't agree with.

[bzbarsky]

You're arguing that it's not necessarily terrible if Opera switches to WebKit, in terms of monoculture issues.

That may well be true. But what others in this thread are arguing is that it would also not be terrible if everyone else switched to WebKit too, and I believe they're wrong about that.

> can't you just submit bugfixes for the bugs that are parallelism bottlenecks?

You mean bugs like being written in C++ and not architected around parallelism?

Bolting on parallelism is _hard_. Have you ever tried doing that with an existing multi-million-line C++ codebase? I've tried with Gecko, and I've spoken with people who have tried with WebKit, as well as reading a good bit of WebKit source, and it's not really feasible unless you drop everything else and focus all your energy on it. And maybe not even then.

> are there any examples of WebKit "bugs" that prevent parallelism that you could not fix yourself

And get the patches actually accepted in WebKit? Lots.

Again, you seem to think the problem is some small issues here and there, whereas the problem is more that you have lots of code touching non-const data through C++ pointers, which means that if you try to parallelize you either get tons of data races or lock contention that kills performance or most likely both.

> At the end of the day, all you guys need to defend is the interface, not the implementation

As long as there are multiple implementations. Unless you include in "interface" everything that's web-visible, but policing that is a huge endeavor that no one working on browser implementations has the manpower for.

[makomk]

Assuming that no webpages are reliant on those bugs, sure. One of the problems with everyone targetting a single rendering engine is that they become reliant on the bugs of that engine, to the point that it becomes difficult to make any changes without breaking compatibility. Look at IE, for instance, especially the IE7-compatibility mode in later versions which wasn't IE7 compatible.

[Ygg2]

Hell don't look at IE, look at Windows, Windows guys had to rewrite a CORRECT implementation of logic check if SimCity was running and turn of a special flag to run the old version of allocator.

http://ianmurdock.com/platforms/on-the-importance-of-backwar...

Now multiply that story for every badly written WebKit site that relies on some backward ass crazy bug that no maintainer sees fit to fix.