Re:State of web browsers in 2018
by danShumway on Thursday December 06, 2018 @12:00PM
(#18619749)
Sure, but how big would those issues need to be?
Would it be worthwhile to make a fork over HTML imports? Suppose that in a mono-engine world Google decides to build AMP directly into the browser rather than on top of Javascript -- would that be a big enough issue to make a fork? I was (like many people) fairly disappointed about Web DRM, but I was happy that Firefox was at least planning to put some additional sandboxing above what Chromium was doing. Would they have forked a codebase just to introduce that extra sandboxing?
You're right that Open Source does allow us to reverse course and fork Blink later if something terrible happens. Remember though, the moment that someone like Mozilla or Microsoft makes a fork, at that point they're back to the same situation that they're in right now -- even worse, because they're stuck using a codebase that wasn't architectured specifically to meet their goals. That provides a big incentive to wait as long as possible before deciding, "heck it, we'll build our own engine."
What I would suggest is that there are at this moment already at least minor organizational issues within Chromium, and there are currently benefits to having multiple browser engines. We could give up those benefits and get them back later if stuff got really bad. But it would mean waiting until things got really bad; and ignoring all of the tiny, daily decisions before that point that go in to setting the direction of the web.
Remember that the web isn't supposed to break backwards compatibility. If you don't get things right the first time, there isn't a second chance to change them.
Would it be worthwhile to make a fork over HTML imports? Suppose that in a mono-engine world Google decides to build AMP directly into the browser rather than on top of Javascript -- would that be a big enough issue to make a fork? I was (like many people) fairly disappointed about Web DRM, but I was happy that Firefox was at least planning to put some additional sandboxing above what Chromium was doing. Would they have forked a codebase just to introduce that extra sandboxing?
You're right that Open Source does allow us to reverse course and fork Blink later if something terrible happens. Remember though, the moment that someone like Mozilla or Microsoft makes a fork, at that point they're back to the same situation that they're in right now -- even worse, because they're stuck using a codebase that wasn't architectured specifically to meet their goals. That provides a big incentive to wait as long as possible before deciding, "heck it, we'll build our own engine."
What I would suggest is that there are at this moment already at least minor organizational issues within Chromium, and there are currently benefits to having multiple browser engines. We could give up those benefits and get them back later if stuff got really bad. But it would mean waiting until things got really bad; and ignoring all of the tiny, daily decisions before that point that go in to setting the direction of the web.
Remember that the web isn't supposed to break backwards compatibility. If you don't get things right the first time, there isn't a second chance to change them.