For several years (2001-2005) we've already had the situation when the single browser engine (Trident, MSIE) had the dominant share of 90% and more. Indeed, this was bad for the Web as a platform, pretty much in ways the article describes.
However this time we've got a difference: new dominant browser engine is open-source with a very liberal license (BSD, LGPL). So anyone who is not satisfied with the development of WebKit is welcome to fork. In fact, Google has replaced JavaScriptCore (part of WebKit) with V8.
So is there actually any reasons for having competitive open-source full browser stacks? I believe licensing reasons (the one behind FreeBSD and Linux) is not very important for browser world (Gecko and WebKit have very similar licensing terms). And I don't see much ideological reasons that can't be fixed by forking.
What else? Usually developers hate abandoning their work and switching to improve competitor's solutions — especially in the open source world. Developers like the feeling of doing important stuff and money. Market share of Firefox is still quite high (~25%) and Mozilla still receives money (company is non-profit, but developers are being paid I believe). Probably for this reasons the struggle will continue for some time.
However it is difficult to assume that there is something useful for web platform in this struggle. Every new web standard feature requires independent implementation from two different open-source projects and the whole platform adoption process goes as fast as the slowest team goes.
It's a very valid point - it doesn't take a genius to figure out competition drives development, while having a market monopoly affords you a great position of "extortion" in regards to your customers (developers). If there was only one solution from only one company, it would literally be their way - and that's it.
Then again, this is why we first develop web standards or markup languages (e.g. HTML, XHTML, XML) in the first place ;)
If a single company was in control of Webkit then it would be an issue, but thankfully there's not. I actually see Webkit's main competition being native apps!
I feel like we're at an interesting tipping point here: I've seen about an equal number of articles in favour of a Webkit monoculture and opposed to it.
The general pattern seems to be that, if you're interested in building a better X (browser, compiler, operating system), then a monoculture is bad. If you're interested in building on top of X (websites, code, applications), then a monoculture is great, so long as the dominant entity is good enough.
In lots of cases, I think the people building on the platform tend to get their way, both because they're more numerous and because the technology in X eventually stabilises, so fewer people want 'a better X'. If a truly better X does later emerge, it then needs a Herculean effort to break the monoculture (e.g. Firefox in the bad old days, clang, the Linux desktop). Then there's an interesting transition period before, perhaps, a new dominant force emerges.
Maybe Mozilla can maintain a mixture of rendering engines by being the determined underdog. It would probably make it easier for a new rendering engine to emerge, but the open web may seem less inviting than more uniform technologies. For all its faults, one of the reasons Flash did so well for so long was that developers didn't have to deal with multiple competing implementations.
"For several years (2001-2005) we've already had the situation when the single browser engine (Trident, MSIE) had the dominant share of 90% and more. Indeed, this was bad for the Web as a platform, pretty much in ways the article describes.
However this time we've got a difference: new dominant browser engine is open-source with a very liberal license (BSD, LGPL). So anyone who is not satisfied with the development of WebKit is welcome to fork. In fact, Google has replaced JavaScriptCore (part of WebKit) with V8.
So is there actually any reasons for having competitive open-source full browser stacks? I believe licensing reasons (the one behind FreeBSD and Linux) is not very important for browser world (Gecko and WebKit have very similar licensing terms). And I don't see much ideological reasons that can't be fixed by forking.
What else? Usually developers hate abandoning their work and switching to improve competitor's solutions — especially in the open source world. Developers like the feeling of doing important stuff and money. Market share of Firefox is still quite high (~25%) and Mozilla still receives money (company is non-profit, but developers are being paid I believe). Probably for this reasons the struggle will continue for some time.
However it is difficult to assume that there is something useful for web platform in this struggle. Every new web standard feature requires independent implementation from two different open-source projects and the whole platform adoption process goes as fast as the slowest team goes."
Competition in open source is not bad. It is actually needed. People can fork WebKit but they might not able to change it dramatically if it's not in favor of Google, Apple and Nokia.
I can't think about a case that WebKit "bosses" won't like a change from another party, but that might happen. We need competition for implementations. What we don't need is double standards for the web.
Microsoft proposed and standardized CSS grids which is awesome, but Google and Apple for some reason do not implement it in WebKit. Microsoft will not do that too. Both ends are enjoying the situation. Pulse.com works great in IE10 because of CSS grids. Microsoft can put their "work best in IE" logo on their website again. Webkit seems don't care much about CSS grids because they think flex-box is the solution.
This is the problem. We have companies making and implementing new standards for their use without caring for the rest of web.
The cost of Firefox switching to WebKit would be enormous, likely even infinite. Too much of Firefox and its extensions depend heavily on non-HTML features of Gecko.
That is a great comment and apparently he is hell banned for a single massively downvoted apple snark. Either heavy down voting automatically triggers a ban or the moderators are smoking something.
If true, "Works best with Chrome" / "Only works with WebKit" etc would simply show that today's web developers are even bigger bozos than the ones from the 1990s.
So, what we learn from history is that people don't learn from history: they just repeat the same mistakes over and over.
I think today's web developers are just a lot younger. I'm 21 and I came to start developing when IE6 was still relevant. (Around my age 15). The generation after me came to developing in a completely different post-IE6 world. I don't think most of them realize the historical context or even the relevance. It's a vicious cycle. I'm not sure if there will ever be a cure for young naivety.
These literal kids just want to build cool stuff and they have more power/freedom/resources than ever before. Give them time and the good ones will learn from their mistakes.
What bugs me about all these articles is that there is no call to action - anyone who wants to defend against monoculture (whether or not that is a worthwhile goal) should start contributing to servo[1], Mozilla's experimental next-generation engine, written in their experimental new language, rust[2].
Good point, and I should probably update the article to include something. Servo is one way, though I fear it's a bit too far out still to make much of a dent in the mobile web for quite some time. Still, it may be a good choice depending on your skills and inclinations.
There are other options too. My main ask for web devs would be to test on mobile Firefox and/or the Windows phone browser in addition to whatever webkit browsers you normally would. Actually, for now testing on Opera would probably be better than either of those; the general consensus seems to be that they're the best wrt standards.
It won't prevent the monoculture, but it will mitigate its effects and help keep the field open for competition.
I think the OP forgot one: the potential for a zero-day vulnerability that hits all current browsers, because they're all descended from a single ancestral code base, and a C++ one at that.
Doh! You are absolutely right, which is sad since I was using a mental model of invasive species when I wrote the post, and even pondered how some plant species do great, smothering and outcompeting the natives, until a fire comes through during their dry season and wipes them and their seeds out.
I honestly apologize for that. My post grew out of a thought I had that if someone wrote a sim-type game about the Browser Wars, then it would be a lot easier to demonstrate to people the ramifications of the forces at play. The only way to figure out a winning strategy would be to analyze the incentive structure, and from that predict the other players' moves. Sadly, I omitted that background from the post, leaving only the title behind as a hint. I agree that an actual game would be cooler and relevant to a different audience (namely, you and the others I suckered in to reading my post due to the title).
That's some pretty heavy fear mongering to excuse being stubborn and outdated.
The entire article is written as though it's a parody, yet we still have to live with their inferior browser and cumbersome ignorance of what people want.
Vague criticism without detail adds nothing to any discussion. Why not try to articulate what, specifically, bothers you about Firefox? What specific ways is it outdated and ignoring what people want?
For a few years Internet Explorer had a monopoly and lots of web sites became dependent on its bugs, quirks, and extensions. A lot of corporations are still stuck due to that.
And that monolithic mono-culture was NOT able to evolve to reduce power consumption in a reasonable timeframe. It wasn't even a big priority, since nobody expected x86 to be in a person's pocket, ever. (AFAIK). It took an outside player, ARM, to drive the debate. So it's pretty much a validation of what Mozilla's saying.
Preventing innovation: a gang of hackers makes a new browser that utilizes the 100 cores in 2018-era laptops perfectly evenly, unlike existing browsers that mostly burn one CPU per tab. It’s a ground-up rewrite, and they do heroic work to support 99% of the websites out there. Make that 98%; webkit just shipped a new feature and everybody immediately started using it in production websites (why not?).
Notwithstanding the other points made, how is rapid adoption of new features, and a competitor's ostensible inability to keep up, preventative of innovation?
The issue here is not rapid adoption, it's an effective monopoly being used to lock competitors out of the marketplace by making fast, arbitrary changes and forcing people to keep up. This has already happened in a few scenarios despite WebKit having competition, so it will get worse if all the competition slowly dies off. webkit-only mobile websites are an obvious example but chrome-only audio code in HTML5 games is another great example (Chrome's HTML5 audio stack was so broken it caused crashes, so to have working sound in Chrome you had to use their special API. As a result, there are HTML5 games out there that only support Chrome's API or, if you're lucky, have a fallback based on a flash plugin).
EDIT: Another great example is the stunt Intel pulled with AVX to intentionally sabotage AMD's ability to compete in the market, as documented here:
http://www.agner.org/optimize/blog/read.php?i=25
Essentially, Intel published a proposed new instruction format, and AMD said 'that looks great, we'll be compatible with it'. After AMD announced this and had started preparing to ship their new chips, Intel suddenly announced that they had changed their instruction format from what they published - after it was too late for AMD to adapt.
The end result was AMD shipping chips that were incompatible with Intel's despite AMD's best effort. Intel knew that as the majority market share holder, developers would prioritize Intel compatibility over AMD compatibility, and AMD would lose.
Writing a browser engine takes time. While you write it, WebKit will be adding new features. By the time you get up to it, it would advance ahead, adding more and more quirks (keep in mind you need to implement bugs as well as features). Since WebKit isn't a standard, it moves quickly, so your own team must be better than all developers working actively on WebKit and then some.
You're confusing innovation in features with innovation in basic architecture.
But the premise of the article doesn't even require innovation in features. It just requires changes that change behavior that sites then depend on and that you have to reverse-engineer.
And reverse-engineering is very time-consuming and slow. If all possible competitors have to reverse-engineer to become viable, that puts in place a huge barrier to competition.
Note that WebKit already behaves this way in various cases: their transitions draft proposal was very vague (as in, what they described could have been figured out in a few afternoons by someone playing with the functionality and their developer docs) and then the editors (Apple employees, note) did nothing to improve it for a few years, forcing everyone else to reverse-engineer WebKit to implement this "standard"...
I think having more then one engine is important to keep everyone accountable and motivated. To me the idea of developing for the standard is merely idealism until either we have either one engine to rule them all or the engines come to the realization that the responsibility of consistently implementing the spec starts with them and not the developer.
In the case of having only one engine, obviously the standard suffers but in the case of multiple engines the developers suffer. Which is worse?
I feel like we as developers have done a good job to mitigate the suffering from having multi engine compatibility with frameworks to the point where it's still better to maintain the direction of multiple engines and code for the implementation rather then the spec simply for the sake of accountability.
At the same time it would be nice to fork everything off the best candidate and unify things but then we wouldn't have anything to compare it to in order to know it's STILL the best candidate.
Competing browser engines and using Javascript frameworks to normalise quirky behaviour sounds like the best of both worlds. Any bugs (i.e deviations from the spec) are quickly patched by the framework until they can percolate down to the browser engine. Of course, note that I consider writing raw HTML to be 'low level programming' ;)
But there's still room for competition with the same codebase. WebKit browsers differ significantly, and still compete with one another.
Though this post claims to be talking about WebKit, I see something like this:
> There’s a bug — background SVG images with a prime-numbered width disable transparency. A year later, 7328 web sites have popped up that inadvertently depend on the bug. Somebody fixes it. The websites break with dev builds.
And have to wonder if they're trying to project IE's issues onto WebKit. I used to have a lot of respect for Mozilla. But now that MDN is stagnating, Firefox is a much less inviting development environment than Chrome (oh how things have changed), and with Mozilla talking shit at every turn, I think I have to revoke all respect. Good luck, guys.
The post is discussing how people develop against a single engine as opposed to a standard, its not 'projecting' and certainly not 'talking shit' about webkit
What do you mean MDN is stagnating? There's a constant upkeep going on there, which is difficult considering how fast the web moves but it's constantly being updated.
For some weird reason removed front the front page in short time. I have seen submissions with less votes and less discussions stay on the FP much much longer than this.
Open-source counters most of the issues around monoculture. Remeber that the first browser wars occurred between two closed source products.
In fact, I think that a single OSS project is far more effecient than attempts at standardization across competing products when it comes to user-beneficial innovation.
Look at the open-source UNIXes. Nearly all the value-add has come from cross-pollination of "proprietary" and not-yet-standardized enhancements, which are consumed by users and application vendors targeting those platforms.
You're basically saying there should only be one web browser and no one should try alternate approaches to common problems unless they're starting with the same codebase.
Being open source doesn't change the fact that it's the same codebase.
Why should there only be one browser engine? I'm a web developer and I hate cross-browser testing/compatibility, I prefer to use Chrome for it's devtools. I would hate for there to only be one browser in the world.
How does open-source counter the issue of monoculture? If there is a monoculture and it's open source it still has the same problems. You can fork but there's a monoculture so your fork is irrelevant. You can submit a patch but there's a monoculture so your patch doesn't get accepted.
Open source isn't a magic bullet, try forking Chrome and see how far you get without prominent adverts on the most popular page on the internet and investing millions into packaging your browser as part of Flash/Java/etc. updates.
[+] [-] anshargal|13 years ago|reply
However this time we've got a difference: new dominant browser engine is open-source with a very liberal license (BSD, LGPL). So anyone who is not satisfied with the development of WebKit is welcome to fork. In fact, Google has replaced JavaScriptCore (part of WebKit) with V8.
So is there actually any reasons for having competitive open-source full browser stacks? I believe licensing reasons (the one behind FreeBSD and Linux) is not very important for browser world (Gecko and WebKit have very similar licensing terms). And I don't see much ideological reasons that can't be fixed by forking.
What else? Usually developers hate abandoning their work and switching to improve competitor's solutions — especially in the open source world. Developers like the feeling of doing important stuff and money. Market share of Firefox is still quite high (~25%) and Mozilla still receives money (company is non-profit, but developers are being paid I believe). Probably for this reasons the struggle will continue for some time.
However it is difficult to assume that there is something useful for web platform in this struggle. Every new web standard feature requires independent implementation from two different open-source projects and the whole platform adoption process goes as fast as the slowest team goes.
[+] [-] Breakthrough|13 years ago|reply
Then again, this is why we first develop web standards or markup languages (e.g. HTML, XHTML, XML) in the first place ;)
[+] [-] suhastech|13 years ago|reply
Read from: "The Ideology of Competition" http://blakemasters.com/post/20955341708/peter-thiels-cs183-... http://blakemasters.com/post/21169325300/peter-thiels-cs183-...
[+] [-] stuartmemo|13 years ago|reply
[+] [-] takluyver|13 years ago|reply
The general pattern seems to be that, if you're interested in building a better X (browser, compiler, operating system), then a monoculture is bad. If you're interested in building on top of X (websites, code, applications), then a monoculture is great, so long as the dominant entity is good enough.
In lots of cases, I think the people building on the platform tend to get their way, both because they're more numerous and because the technology in X eventually stabilises, so fewer people want 'a better X'. If a truly better X does later emerge, it then needs a Herculean effort to break the monoculture (e.g. Firefox in the bad old days, clang, the Linux desktop). Then there's an interesting transition period before, perhaps, a new dominant force emerges.
Maybe Mozilla can maintain a mixture of rendering engines by being the determined underdog. It would probably make it easier for a new rendering engine to emerge, but the open web may seem less inviting than more uniform technologies. For all its faults, one of the reasons Flash did so well for so long was that developers didn't have to deal with multiple competing implementations.
[+] [-] stuffihavemade|13 years ago|reply
"For several years (2001-2005) we've already had the situation when the single browser engine (Trident, MSIE) had the dominant share of 90% and more. Indeed, this was bad for the Web as a platform, pretty much in ways the article describes.
However this time we've got a difference: new dominant browser engine is open-source with a very liberal license (BSD, LGPL). So anyone who is not satisfied with the development of WebKit is welcome to fork. In fact, Google has replaced JavaScriptCore (part of WebKit) with V8.
So is there actually any reasons for having competitive open-source full browser stacks? I believe licensing reasons (the one behind FreeBSD and Linux) is not very important for browser world (Gecko and WebKit have very similar licensing terms). And I don't see much ideological reasons that can't be fixed by forking.
What else? Usually developers hate abandoning their work and switching to improve competitor's solutions — especially in the open source world. Developers like the feeling of doing important stuff and money. Market share of Firefox is still quite high (~25%) and Mozilla still receives money (company is non-profit, but developers are being paid I believe). Probably for this reasons the struggle will continue for some time.
However it is difficult to assume that there is something useful for web platform in this struggle. Every new web standard feature requires independent implementation from two different open-source projects and the whole platform adoption process goes as fast as the slowest team goes."
[+] [-] msoad|13 years ago|reply
I can't think about a case that WebKit "bosses" won't like a change from another party, but that might happen. We need competition for implementations. What we don't need is double standards for the web.
Microsoft proposed and standardized CSS grids which is awesome, but Google and Apple for some reason do not implement it in WebKit. Microsoft will not do that too. Both ends are enjoying the situation. Pulse.com works great in IE10 because of CSS grids. Microsoft can put their "work best in IE" logo on their website again. Webkit seems don't care much about CSS grids because they think flex-box is the solution.
This is the problem. We have companies making and implementing new standards for their use without caring for the rest of web.
[+] [-] rdtsc|13 years ago|reply
[unrelated to topic]
Always wondered, if someone is hellbanned, how come anyone can see it? In other how did you see it and how did you know he was shadow banned?
[+] [-] lucian1900|13 years ago|reply
[+] [-] youngerdryas|13 years ago|reply
[+] [-] scholia|13 years ago|reply
So, what we learn from history is that people don't learn from history: they just repeat the same mistakes over and over.
[+] [-] lbotos|13 years ago|reply
These literal kids just want to build cool stuff and they have more power/freedom/resources than ever before. Give them time and the good ones will learn from their mistakes.
[+] [-] aeosynth|13 years ago|reply
[1]: https://github.com/mozilla/servo [2]: https://github.com/mozilla/rust
[+] [-] sfink|13 years ago|reply
There are other options too. My main ask for web devs would be to test on mobile Firefox and/or the Windows phone browser in addition to whatever webkit browsers you normally would. Actually, for now testing on Opera would probably be better than either of those; the general consensus seems to be that they're the best wrt standards.
It won't prevent the monoculture, but it will mitigate its effects and help keep the field open for competition.
[+] [-] sultezdukes|13 years ago|reply
[+] [-] mwcampbell|13 years ago|reply
[+] [-] sfink|13 years ago|reply
[+] [-] xenophanes|13 years ago|reply
[+] [-] sfink|13 years ago|reply
[+] [-] lgp171188|13 years ago|reply
[+] [-] flipstewart|13 years ago|reply
The entire article is written as though it's a parody, yet we still have to live with their inferior browser and cumbersome ignorance of what people want.
[+] [-] shardling|13 years ago|reply
As it stands, your comment is just... boring.
[+] [-] TwoBit|13 years ago|reply
[+] [-] rimantas|13 years ago|reply
[+] [-] slevcom|13 years ago|reply
[+] [-] octatone2|13 years ago|reply
[+] [-] frozenport|13 years ago|reply
[+] [-] btown|13 years ago|reply
[+] [-] itafroma|13 years ago|reply
Notwithstanding the other points made, how is rapid adoption of new features, and a competitor's ostensible inability to keep up, preventative of innovation?
[+] [-] kevingadd|13 years ago|reply
EDIT: Another great example is the stunt Intel pulled with AVX to intentionally sabotage AMD's ability to compete in the market, as documented here: http://www.agner.org/optimize/blog/read.php?i=25
Essentially, Intel published a proposed new instruction format, and AMD said 'that looks great, we'll be compatible with it'. After AMD announced this and had started preparing to ship their new chips, Intel suddenly announced that they had changed their instruction format from what they published - after it was too late for AMD to adapt. The end result was AMD shipping chips that were incompatible with Intel's despite AMD's best effort. Intel knew that as the majority market share holder, developers would prioritize Intel compatibility over AMD compatibility, and AMD would lose.
[+] [-] Ygg2|13 years ago|reply
[+] [-] bzbarsky|13 years ago|reply
But the premise of the article doesn't even require innovation in features. It just requires changes that change behavior that sites then depend on and that you have to reverse-engineer.
And reverse-engineering is very time-consuming and slow. If all possible competitors have to reverse-engineer to become viable, that puts in place a huge barrier to competition.
Note that WebKit already behaves this way in various cases: their transitions draft proposal was very vague (as in, what they described could have been figured out in a few afternoons by someone playing with the functionality and their developer docs) and then the editors (Apple employees, note) did nothing to improve it for a few years, forcing everyone else to reverse-engineer WebKit to implement this "standard"...
[+] [-] slajax|13 years ago|reply
In the case of having only one engine, obviously the standard suffers but in the case of multiple engines the developers suffer. Which is worse?
I feel like we as developers have done a good job to mitigate the suffering from having multi engine compatibility with frameworks to the point where it's still better to maintain the direction of multiple engines and code for the implementation rather then the spec simply for the sake of accountability.
At the same time it would be nice to fork everything off the best candidate and unify things but then we wouldn't have anything to compare it to in order to know it's STILL the best candidate.
[+] [-] johnmw|13 years ago|reply
[+] [-] just2n|13 years ago|reply
Though this post claims to be talking about WebKit, I see something like this:
> There’s a bug — background SVG images with a prime-numbered width disable transparency. A year later, 7328 web sites have popped up that inadvertently depend on the bug. Somebody fixes it. The websites break with dev builds.
And have to wonder if they're trying to project IE's issues onto WebKit. I used to have a lot of respect for Mozilla. But now that MDN is stagnating, Firefox is a much less inviting development environment than Chrome (oh how things have changed), and with Mozilla talking shit at every turn, I think I have to revoke all respect. Good luck, guys.
[+] [-] daleharvey|13 years ago|reply
[+] [-] jlongster|13 years ago|reply
[+] [-] pavs|13 years ago|reply
http://www.slashgeek.net/2013/02/16/use-webkit/
For some weird reason removed front the front page in short time. I have seen submissions with less votes and less discussions stay on the FP much much longer than this.
[+] [-] Offler|13 years ago|reply
[+] [-] jcroll|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] skatepark|13 years ago|reply
In fact, I think that a single OSS project is far more effecient than attempts at standardization across competing products when it comes to user-beneficial innovation.
Look at the open-source UNIXes. Nearly all the value-add has come from cross-pollination of "proprietary" and not-yet-standardized enhancements, which are consumed by users and application vendors targeting those platforms.
[+] [-] likeclockwork|13 years ago|reply
Being open source doesn't change the fact that it's the same codebase.
Why should there only be one browser engine? I'm a web developer and I hate cross-browser testing/compatibility, I prefer to use Chrome for it's devtools. I would hate for there to only be one browser in the world.
Duplication is not equivalent to standardization.
[+] [-] sequence7|13 years ago|reply
[+] [-] ubernostrum|13 years ago|reply