
Browser Wars, the game - nnethercote
https://blog.mozilla.org/sfink/2013/02/14/browser-wars-the-game/
======
anshargal
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.

------
Breakthrough
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 ;)

~~~
suhastech
I think this is not always true.

Read from: "The Ideology of Competition"
[http://blakemasters.com/post/20955341708/peter-thiels-
cs183-...](http://blakemasters.com/post/20955341708/peter-thiels-
cs183-startup-class-3-notes-essay)
[http://blakemasters.com/post/21169325300/peter-thiels-
cs183-...](http://blakemasters.com/post/21169325300/peter-thiels-
cs183-startup-class-4-notes-essay)

------
takluyver
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.

------
stuffihavemade
anshargal, you're shadow banned. His comment is:

"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
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.

~~~
azakai
> I can't think about a case that WebKit "bosses" won't like a change from
> another party, but that might happen.

Such things already happened, for example Google wanted to add changes to
WebKit to support another VM in the browser (for Dart). Apple devs blocked the
attempt for technical reasons, but some speculate political ones were relevant
as well.

------
scholia
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.

~~~
lbotos
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.

~~~
skatepark
When I started, there was no web. The historical context is quite a bit
broader, and it helps to understand what the state of the technology was.

When the browser war was fought (and won):

\- Netscape Navigator was actually a pretty terrible piece of software. I dare
say they deserved to lose. Towards the end, most Mac users were running IE5 --
it was a better browser
(<http://en.wikipedia.org/wiki/Internet_Explorer_for_Mac>).

\- There was diminishing market interest in supporting alternatives to Windows
because non-windows marketshare (Mac OS X, UNIX workstations) was plummeting.
This allowed Microsoft embrace-and-extend to succeed.

\- The web development field was nascent at best. Similar to how many web
developers are moving into the mobile space today (and bringing their ideas of
how to write apps with them), you had Windows-centric enterprises migrating
towards writing web sites (not apps!) and bringing their ideas of how to do so
with them.

I very much doubt that the web browser war would happen again in quite the
same way. Between the availability of open-source browser stacks, the genuine
viability of multiple platforms and vendors (iOS, Android, Mac OS X, Windows,
and even Linux), and the established web development community (which would
have to be co-opted), I don't think it would be quite so easy for someone like
Google to 'win' a browser war and then stagnate indefinitely.

~~~
yuhong
Yea, it is unfortunate Netscape 5 "Mariner" was cancelled.

------
aeosynth
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].

[1]: <https://github.com/mozilla/servo> [2]: <https://github.com/mozilla/rust>

~~~
sfink
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.

------
mwcampbell
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.

~~~
sfink
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.

------
xenophanes
Next time you title your thing "X Wars, the game" please provide an actual
game to play, not an article. False advertising :(

~~~
lgp171188
That is the exact reason why I opened the Hacker News page from my feed
reader!

------
flipstewart
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.

~~~
TwoBit
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.

~~~
just2n
It wasn't because of the monopoly.

It was because IE had a HORRENDOUSLY SLOW development cycle with minimal
resources committed. It was impossible to get all of those issues fixed in a
timely manner. If they can be fixed within a few months, it won't be 5+ years
of entrenching people in egregious bugs before a new version comes out that
breaks all of those if/elses in everyone's code.

We develop ONLY for Chrome. It (and WebKit especially) has bugs, too, and we
report them regularly. But the development cycle is rapid enough that we can
put a TODO in the code, file a bug against it, and a few months later we
actually get to fix the code because, oh my gosh, it's fixed on Chrome stable.

~~~
sequence7
IE only had a horrendously slow development cycle with minimal resources
committed after it became a monopoly. Up until that point it was regularly
updated with features and bug fixes.

I doubt that Chrome/WebKit will stagnate if it becomes the de facto standard
but I'd rather it didn't have the chance and I'm constantly amazed that so
many comments on HN seem desperate for one browser to rule them all.

~~~
just2n
IE was always that way, actually. Please check their release dates. They were
very slow by standards we expect today. After 6, they did suddenly disappear
for years, but again, this is a Microsoft problem.

It was also closed source, so nobody who found a bug could just go fix it. You
had to ask Microsoft, nay beg Microsoft, to fix it for you. And they didn't.

These effects compound one another. The result is that MAJOR bugs become
features.

~~~
scholia
IE development was pretty rapid up to IE6: please check their release dates.
Microsoft out-developed Netscape.

How do you think it got from IE1.0 in August 1995 to IE6 in October 2001?
(That included the IE5.5 release as well.)

~~~
just2n
I did check their release dates. I don't consider multi-month releases of
minor versions "rapid", and major versions were shipped yearly.

That rate of development with the resources Microsoft had to get the best
developers available is really unacceptable.

~~~
scholia
You're wrong, but I guess you're too young to remember and can't be bothered
to learn anything.

The IE team produced 7 versions in six years and there were some very
substantial advances, including a new layout engine (Trident). They also did
Mac and Unix versions, a mobile version, and a tabbed version for MSN (before
iE had tabs).

IE certainly developed a lot faster than anything else on the market in the
1990s, bearing in mind that Netscape took three years to get from 4.7 to 4.8.

Safari entered the market late (2003) and still took the best part of seven
years to make it to version 4.

Nobody shipped major versions "yearly".

------
rimantas
So, would Mozilla folks write these posts if Opera were to announce switching
to Gecko?

~~~
daleharvey
I would (saying that, I havent even written about the switch to webkit), but
it would be similarly disappointing (albeit understandable).

I think a lot of people project some war between browser vendors that doesnt
reflect reality. Only speaking for myself (as a Mozilla employee) but I want
what I believe to be the best for the web, not for Gecko / Mozilla (luckily
Mozillas entire goal is to do the best for the web, so we have joint
interests)

~~~
scholia
Google wants what's best for Google, Apple wants what's best for Apple and
Microsoft wants what's best for Microsoft. Since all three are grasping multi-
national capitalist corporations with a fiduciary duty to shareholders, that's
to be expected.

Since "Mozilla is a proudly non-profit organization dedicated to keeping the
power of the Web in people’s hands" then it is able to do things differently.

However, users are basically self-interested and short sighted (basically "how
fast does a tab load") so just being morally superior isn't a win ;-)

~~~
Me1000
Exactly, being morally superior gets you no where, and being morally inferior
doesn't hurt you either. You said yourself that users only care about "how
fast a tab loads." Well, if Google ships a browser that's terrible, people
will switch to something else. That's why competition still exists! Firefox
was in a position to dominate the desktop browser market, but then Chrome came
alone and ate their lunch! There's nothing stopping Mozilla from regaining
that market share, but they're going to have to ship a better browser!

~~~
yodaiken
Let's not forget that Google, unlike Mozilla, is able to tell over a billion
users "Download a faster, better browser now"

~~~
elbear
Yes, that counts, but in the end it's also the performance of the actual
browser that counts and keeps people as users.

------
slevcom
I'm liking Mozilla more and more these days. I'm seriously considering
thinking about trying out this wacky browser of theirs. ;)

~~~
octatone2
I hear by 2015 they will finally implement these new fangled information
windows called "Desktop Notifications".

------
frozenport
We forget the most monolithic mono-culture: x86.

~~~
btown
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.

~~~
skatepark
The big difference is that nobody insisted that ARM stay instruction-level
compatible with x86.

------
itafroma
_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?

~~~
kevingadd
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.

------
slajax
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.

~~~
johnmw
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' ;)

------
just2n
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.

~~~
daleharvey
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

~~~
just2n
I disagree entirely. This is an inflammatory piece that is factually full of
nonsensical claims that don't and haven't held up. It makes HUGE assumptions
that have direct contradictions in practice. I don't see how anyone could take
it seriously. As for not "talking shit" about WebKit, let's look at that one
claim:

> Backwards bug compatibility

This is obviously pointed at what IE did after years of maintaining the same
bugs that people relied on. The article actually figured out WHY this
happened: taking a year to fix a MAJOR issue results in people relying on it.
IE was always updated very, very slowly. Nobody else really had this problem,
and IE is the one who instilled major flaws as "features" and refused to
correct them later on. This very much describes exactly what Microsoft did
with IE.

But then they try to ascribe that, somehow, with major handwaving as a problem
that will be seen if everyone uses the same code base. This coming on the
heels of Opera deciding to use WebKit. It's very clear they are making the
claim that the same problems IE was having would be caused by WebKit. This is
called talking shit.

The problem is that these problems were caused by a well known phenomenon:
taking years to fix major issues. Google has maintained a PHENOMENAL rate of
development on their own browser, and they aren't even competing with Mozilla
anymore, they're way out in front. Pushes to stable are slower but Canary is
updated almost daily. I've seen major bugs and regressions get fixed in HOURS.
And I've seen independent players issue patches to fix problems.

This is a picture that is antithetical to IE. It is the POLAR OPPOSITE of the
scenario under which this problem initially became so egregious. There is no
basis for this claim. And to the point that we "NEED" multiple implementations
of a standard to find where things are ambiguous, please feel free to peruse
the discussion groups at your leisure. Not only are these ambiguities
discussed without referencing Firefox, IE, or anyone else, but they're often
resolved with changes in the implementation or, rarely, in the spec. This
would be an impossibility if we all worked on 1 code base, clearly.

~~~
mwcampbell
You say that Chrome is way out in front of Firefox. Can you please back up
this assertion?

~~~
just2n
I don't want to start a browser flame war, but for me these are clear
victories and explanation is unnecessary. Their combination is sufficient for
me to vote that Chrome > Firefox, and this as a person who used to use Firefox
religiously until Chrome completely changed the game.

Usability (configuration, ease of migration of configuration, etc): win

Developer tools: win+++++

Extensibility: win

Speed: win (JS + speed of rendering, though this is a lot closer than it used
to be)

System footprint: win

Availability of experimental features in beta: win (though from time to time
Firefox does some crazy awesome shit in beta builds, Chrome is more
consistent)

I've long said the only browser remotely close to Chrome is Firefox, but for
me, they are a clear leader. It's unfortunate to see Mozilla behaving this way
in public. I take Opera's choice of using Chromium as a validation of my
assertion, and I really believe if they had chosen to use Mozilla's software
instead of Google's, that Mozilla would be fairly silent right now.

~~~
bzbarsky
> System footprint: win

Defined how?

~~~
Ygg2
There is some merit to this claim. Firefox on my 4GB 1GhZ laptop is somewhat
sluggish (it could be down to several factors), especially when it comes to
Flash. Chrome flies, but Nightly is actually on par with Chrome.

------
pavs
Probably in reply to this: <http://news.ycombinator.com/item?id=5231665>

<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
Yes, it's a conspiracy! They're out to get Webkit.

~~~
pavs
No reason to be condescending. I was simply pointing out how unusual it was.

------
jcroll
I want to care, I definitely want to care; but can I care?

------
skatepark
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.

~~~
likeclockwork
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.

Duplication is not equivalent to standardization.

~~~
skatepark
No, I'm saying that open-source solves most of the issues with a monoculture,
while also being more effecient than vendor standardization when it comes to
pushing forward innovation.

~~~
likeclockwork
Saying that every software project in a specific domain should use the same
codebase is madness.

