3 ms·

One rendering engine that has some serious limitations, like not being very parallelizable, because of highly entrenched implementation choices. Which means th

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.

malandrew 14y ago
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.
- bzbarsky 14y ago
  > 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 14y ago
    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/ 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.
yuhong 14y ago
As an example, I personally figured out where legacy color parsing is in the Netscape classic source: http://stackoverflow.com/questions/8318911/why-does-html-think-chucknorris-is-a-color/12630675#12630675 http://stackoverflow.com/questions/8318911/why-does-html-thi... It is so subtle even Netscape's own Gecko rewrite did not get it completely right the first time: https://bugzilla.mozilla.org/show_bug.cgi?id=121738 https://bugzilla.mozilla.org/show_bug.cgi?id=121738
zobzu 14y ago
And to stretch that a bit, the same apply for operating systems, text editors, heck, clothes color, clothes type, food, etc. No choice & diversity = always been a bad idea and never, ever led to efficiency, progress, etc. It has always and every time led to the opposite.

malandrew 14y ago

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.

bzbarsky 14y ago
> 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 14y ago
  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/ 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.

yuhong 14y ago

As an example, I personally figured out where legacy color parsing is in the Netscape classic source: http://stackoverflow.com/questions/8318911/why-does-html-think-chucknorris-is-a-color/12630675#12630675 http://stackoverflow.com/questions/8318911/why-does-html-thi... It is so subtle even Netscape's own Gecko rewrite did not get it completely right the first time: https://bugzilla.mozilla.org/show_bug.cgi?id=121738 https://bugzilla.mozilla.org/show_bug.cgi?id=121738

zobzu 14y ago

And to stretch that a bit, the same apply for operating systems, text editors, heck, clothes color, clothes type, food, etc. No choice & diversity = always been a bad idea and never, ever led to efficiency, progress, etc. It has always and every time led to the opposite.