One rendering engine that has some serious limitations, like not being very parallelizable, because of highly entrenched implementation choices.
Which means that if you want hardware capable of rendering the web it can't be low-power highly-parallel hardware; it has to be high-power-consumption fast-serial-operation hardware. Why is that bad? I guess that's a matter of perspective. I think that would be a terrible outcome, personally.
I should point out that I'm not aware of any compiler that has implemented C++ perfectly, and I doubt any ever will given that it's a moving target. So why bother having multiple compilers or a C++ standard at all? For example, why does the WebKit argument not apply to gcc? And note that in compiler-land not being able to compile some codebases is OK as long as you can compile the codebase your user cares about, while the Web equivalent (only rendering some websites but not others) is a lot more problematic, because the typical compiler user compiles fewer different codebases than they visit websites. And also because using different compilers for different codebases is a lot simpler than using different browsers for different websites.
You know that you can always start an open source project that fixes these parallelization issues and start building out an engine that is better, right? It'd probably be a 5-7+ year project, but it certainly is doable.
In fact, it's possible that the poor parallelization support will be the Achilles' tendon of WebKit on a long-enough time scale.
This is no different than the Achille's tendon of the DOM that is procedural-style immediate mode graphics instead of retain-mode graphics. Browser apps will never compete with iOS apps in terms of user experience until this procedural approach is replaced with a declarative functional reactive approach.
Think long term. The Windows hegemony eventually buckled under its own weight. There's no reason to think that WebKit won't eventually do the same on a long enough time scale. Figure out what will lead to its collapse because that is an opportunity. In fact, letting WebKit lead the way allows you to learn all the ways in which WebKit does it wrong. WebKit will continue to trail blaze on the interface, but doesn't have to be the end all be all of implementations for those interfaces.
Between Tizen and B2G, there is plenty of innovation in the web browser space. I just hope that transclusion is always considered a first world citizen in this brave new world.
> 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.
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.
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.
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.
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.
Which means that if you want hardware capable of rendering the web it can't be low-power highly-parallel hardware; it has to be high-power-consumption fast-serial-operation hardware. Why is that bad? I guess that's a matter of perspective. I think that would be a terrible outcome, personally.
I should point out that I'm not aware of any compiler that has implemented C++ perfectly, and I doubt any ever will given that it's a moving target. So why bother having multiple compilers or a C++ standard at all? For example, why does the WebKit argument not apply to gcc? And note that in compiler-land not being able to compile some codebases is OK as long as you can compile the codebase your user cares about, while the Web equivalent (only rendering some websites but not others) is a lot more problematic, because the typical compiler user compiles fewer different codebases than they visit websites. And also because using different compilers for different codebases is a lot simpler than using different browsers for different websites.