

Why All Browsers Should Move to WebKit - pavs
http://www.slashgeek.net/2013/02/16/use-webkit/

======
lmkg
1\. Multiple browser engines are the only reason most webdevs code to the
standards.

2\. If people don't code to the standards, it's much more difficult to make
new and better browser engines.

1, expanded: All browsers have quirks, or bug, or specific ways of handling
ambiguous situations. IE6 has more than most, but even modern browsers do have
their edge cases and unsupported features and whatnot. If there's only one
browser, people will code to the quirks, not the browser. Historically, the
single largest category of implementation-dependent behavior that people rely
on is how an implementation handles erroneous input. That's why malformed HTML
is now standardized.

No, not you of course, but all those _other_ web developers. Look, standards
are nice, but to many developers (especially hobbyists), and to most suits,
it's just a bunch of hot air. And the hard part is, they're right, at least in
the short term. Coding to standards costs time, and coding to browsers
produces a pixel-perfect functional site.

Multiple, disagreeing browsers are what make standards practical. Coding to
standards is a best-practice, low-cost way of dealing with the real problem of
divergent browser implementations. If that problem becomes theoretical, but
the cost does not, then the sensible path is to code write pages that work in
Webkit, standards be damned.

2, expanded: The more that existing code relies in the quirks of one
implementation, the harder it is for a new implementation to arise. The
surface area of features they have to match is expanded. Furthermore, these
new "features" are more constraining to match because they are undesigned, not
always consistent, and often closer to the metal.

Not only does this make it harder to write a new engine, it constrains the
ways in which new engines can be better. The easiest example is how having to
match another implementation's order-of-evaluation can limit the benefits of
concurrency.

So the sum of this is that Webkit wins now, it will be incredibly difficult to
get anything better than Webkit in the future (note that this applies equally
to forks of Webkit--they're still limited in how much they can differ). Not
that Webkit's bad or anything, but I think it's myopic to say that we won't
ever want anything more.

Servo, of course, is right now the most concrete example of something that we
might want in the future, with its promise of a fundamentally concurrent
architecture. But even aside from that, the future has a way of surprising us,
and I wouldn't like the be stuck with outdated tech in 2018 because webdevs in
2013 got a bee in their bonnet about webkit vs gecko.

~~~
ajross
Not to be glib, but... most webdevs code to the standards? News to me. Most
webdevs code to their favorite API. And their favorite APIs code to an insane
list of quirks. No one but book authors seems to care about standards.

~~~
BiosElement
Your web devs must suck then dude. I don't know a single web dev who doesn't
go out of their way to provide the best range of browser support possible.

~~~
marcloney
I would consider that a contradictory statement. In order to provide the best
range of browser support it is usually necessary to not code to web standards
to support older browsers (that do not support latest web standards) or to
support newer features (vendor specific CSS, etc).

------
AshleysBrain
Isn't the main point about competition? IE6 never had any meaningful
competition until Firefox came along, then lo and behold, all browsers started
getting a lot better a lot quicker.

I don't see why WebKit-everywhere would be different. If they become lazy and
slow at implementing features, what's going to make them get their act
together other than a competing engine that's beating them in some regard?

~~~
michael_miller
The reason that WebKit is different from Trident (IE's rendering engine) is
that WebKit is open source. If a company comes along and says "hey, it would
be really cool if we had an NFC API for the web", they're not stuck in a rut.
They can hire some developers and submit a patch. So I'm not worried about
lack of feature development.

The thing I'd be most worried about with a single engine is lack of compliance
with the standard. If multiple people are implementing the standard
independently, there are bound to be some differences (for example, if an SVG
line is rendered at 0px, with a 1px stroke width and crispEdges, do you snap
to [-1px, 0px], or [0px, 1px]?) People run into these issues in practice, and
report them; it causes clarifications in the standard to be made, and ensures
there is an accepted standard of behavior for pages. This ensures we don't end
up in a situation like Ruby, where Specs ran on the official compiler dictate
language rules. It means that WebKit is allowed to change its implementation
details without anyone crying foul when the maintainers change undefined
behavior.

~~~
dkuntz2
You're working on the assumption that one of the biggest fallacies of open
source software, which is that anyone can make any change they like and it'll
be rolled back into the main branch.

Just because it's open source doesn't mean that the gatekeepers of WebKit will
accept your patch.

~~~
zaphar
Webkit gatekeepers may not accept your patch but they can't stop you from
forking it. If you maintain a fork and you're feature becomes popular then
eventually your fork will get merged into mainline webkit. If it doesn't
become popular then it probably didn't need to get merged into webkit. This is
how open source works and it's a good thing. It allows ideas to compete.

And while we are on the subject it seems like people are talking past each
other in this debate.

1a. Web standards are good because they provide a baseline of combatibility
for browsers. 1b. Webkit forks on all browsers could be good because it would
provide a baseline of compatibility for all browsers.

2a. Web standards could be good because they prevent any one browser from
setting defacto proprietary standards that lock other browsers out of the
market. 2b. Webkit on all browsers could be good because it would prevent any
browser from setting defacto proprietary standards that lock other browsers
out of the market.

3a. Having webkit on all browsers would hurt standards by becoming a defacto
standard providing a baseline of compatibility between browsers and still
allowing competition. 3b. Having webkit on all browsers would provide a real
baseline of compatibility between browsers while still allowing competition.

It's a little bit funny to watch actually.

------
daleharvey
Its a shame to have something so ill informed so highly voted, but ignoring
the whole fact that there is no 'webkit' and people will still need to deal
with these nightmares (hello safari)

This comment I felt gave a good practical example of the more handwavey
'competition is good' argument

"Doing this would mean being forever stuck in single-threaded land for
rendering (e.g. nothing like Mozilla's Servo project could ever happen).

People have tried to parallelize WebKit and failed: too entangled, too much
code making too many assumptions... Parallelism is one of those things that's
just incredibly hard to bolt on after the fact.

So if you want browsers to never really scale well to large number of cores,
by all means try to get them to all switch to WebKit."

<http://news.ycombinator.com/item?id=5213200>

------
Isofarro
Be careful what you ask for. NetFront have switched to using WebKit as a basis
for their rendering engines, finding their way to various gaming gadgets, both
console and hand-held.

Unfortunately, due to memory limitations of some of these devices, they don't
really score well on automated compliance tests as "nice-to-have" features are
trimmed in an effort to get a workable browser on constrained devices. Have a
look at <http://console.maban.co.uk/> about the capabilities of these devices.
Remember, there are more game consoles and handhelds than iphones and Android
device.

Surely we've learned from IE6 why a defacto standard is worse than an open and
implementable standard?

Monoculture is a terrible price to pay. Don't forget South Korea's 99%+ IE6
dominance. [http://blog.mozilla.org/gen/2012/11/15/2012-update-to-
the-20...](http://blog.mozilla.org/gen/2012/11/15/2012-update-to-
the-2007-cost-of-monoculture-in-korea/) \-- such a lock-in that it becomes a
political topic: [http://blogs.wsj.com/korearealtime/2012/11/13/ahn-pledges-
to...](http://blogs.wsj.com/korearealtime/2012/11/13/ahn-pledges-to-end-
outdated-encryption-standard/)

------
J_Darnley
I'm sure that won't cause a situation similar to the stagnation we saw when
IE6 was the dominant browser!

To anyone who says "you can fork it": If you aren't using the same features as
everyone else, how is the situation then different to what we have now?

~~~
derefr
"You can fork it" is pretty outdated as a concept. Today, with DCVS, we have
"you can create a branch, then both continuously rebase from upstream, while
continuously submitting pull requests _to_ upstream."

~~~
Thrall
It does still depends a bit on which direction the 'fork' goes in and whether
it remains compatible with upstream's intentions. So a minor feature branch
can often be merged back into upstream, but significant changes to the core
code may not be accepted upstream.

What I'm trying to say is that while it is much easier than it was to create a
branch and merge all or some of the modifications back into master, the
concept of a fork, where development diverges because different parties want
to do different things with the project, which can't easily coexist in the
same codebase, is still relevant.

------
kryptiskt
Opinions like this makes me want to create a new browser engine just to be
contrary. And because the web deserves something better than C++.

~~~
LeonidasXIV
So you mean Servo and Rust? Actually, I just installed the Rust compiler to
tinker with Servo.

~~~
kryptiskt
I follow Rust a bit (not Servo yet). It seems a smidgen complex, lots of
features there, but as long as it has pattern matching and ADTs I'm happy. I
hope it stabilizes soon.

~~~
steveklabnik
It has both, and, if I remember correctly, 0.6.0 is going to be syntax final.

> It seems a smidgen complex,

The thing about Rust is that it seems that way, but that's because things that
are library features in other languages are language features in Rust. For
example, C++ has one kind of pointer. Unless you count smart_ptr<> and
friends, in which case it has just as many as Rust does.

~~~
kibwen
> 0.6.0 is going to be syntax final

That's a tentative "final" though. No guarantees until 1.0.

~~~
steveklabnik
Of course. 0.5.0 was supposed to be, too, until Things Happened. It's all
good.

------
adulau
Diversity is good not only for competition but also for security.

For more information, I would recommend to read the article from Dan Geer
about diversity and security - Monopoly Considered Harmful:

<http://users.ece.gatech.edu/~dblough/8813/geer.pdf>

------
jeffjose
I read the article intently up until the point where he unceremoniously
dismissed the entire IE6 team as "lazy".

~~~
Offler
Indeed, 'terrible', 'evil' but not 'lazy'.

Nothing could cause such pain without a lot of hard work.

~~~
dmethvin
I invite you to submit your work from 14 years ago and have it judged by 2013
standards.

~~~
Scramblejams
IIRC IE6 was considered a pretty nasty piece of work by discriminating minds
at the time (e.g. more of embrace, extend, extinguish[1]), so no need to time
travel.

<https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish>

~~~
simanyay
Back in the days, IE6 was the best browser out there.

~~~
Scramblejams
Whether it was a good browser or not doesn't change the fact that it was also
a crafty attempt at manipulating web standards in such a way as to promote
vendor lock-in for the entire web, which supports Offler's post.

------
snambi
If we had only webkit, they would eventually become like IE. IE had no
competition from 1998-2005(?), until Firefox came. I think that ~5 years of
dominance killed IE.

~~~
khuey
It was more like 2001-2004 from when Netscape 6 launched to when Firefox 1.0
launched.

------
sergiotapia
Currently on my all of my websites, combined, Chrome accounts for 79% of
traffic at the moment. It's good they're off IE (not because it's Microsoft,
but because it doesn't follow standards), but they're just switching one
single pony for another.

In an ideal world the split would be even throughout all major browsers. I
feel uneasy seeing Chrome so high. Even makes me a bit melancholic to see
Firefox at a measly 17%. (again: for MY websites)

~~~
zaphar
I don't think it's possible to have what you describe. It would require
roughly equivalent performance and features in multiple browsers. That won't
happen unless you inhibit or penalize browsers for improvements above a
certain level. Eventually someone will outdo Chrome and the web will switch
over but there will always be a top dog.

------
steveklabnik
Monoculture is bad, no matter what the monoculture.

The web's strongest feature is that it's not tied to one particular
implementation: that's why it's been able to grow, change, and sustain itself
for so long.

~~~
andraconda
Unfortunately when it comes to mobile browsing, with the market share that the
webkit based browsers have,h its already a monoculture of sorts.

~~~
steveklabnik
For certain very loosely defined values of 'monoculture.' But yes, I agree: we
need even more engines. I'm glad Mozilla is sticking to their guns. I
personally installed Aurora today.

------
brianfcoleman
WebKit is a great technology but we really need viable alternatives such as
Gecko as used in Firefox to guarantee a healthy future for the web. The
situation ten years ago where most websites targeted IE 6 led to a stagnant
period in the history of browser and web technologies. The past few years have
seen enormous progress directly as a result of the competition between
Firefox, Chrome, Safari and even IE. It would be sad if we were to return to a
browser monoculture. It makes me sad that Apple and Microsoft restrict the
development of third party browsers for their phone OS's. I would love to be
able to use Firefox on iOS just as I can for Mac OSX. Mobile Safari is great
but the risk of web developers ignoring standards and targeting mobile
websites at WebKit alone is worrying. I have a more detailed argument at
[http://compile-link-run.blogspot.co.uk/2013/02/why-john-
grub...](http://compile-link-run.blogspot.co.uk/2013/02/why-john-gruber-is-
wrong-about-webkit_16.html) and would be interested in hearing what others
have to say.

------
Sunlis
> So when I heard Opera was switching its rendering engine to WebKit, a first
> major browser to do so among many other Opera firsts, ...

What? There top 5 browsers are IE, Firefox, Chrome, Safari and Opera. Chrome
and Safari already use WebKit, so how would Opera moving to WebKit be "an
Opera first"?

~~~
guptaneil
Chrome and Safari started with WebKit, Opera is the first to drop their own
engine and _switch_ to WebKit.

------
jakub_g
There was an article [0] in the very top of HN two days ago from Brendan Eich
why Mozilla won't move to WebKit. TL;DR: 1) it would require enormous amount
of work, 2) add-ons compatibility would be in danger, and add-ons are the
heart of Firefox.

I also doubt that Microsoft will move after heavily investing in IE9 and IE10
standard compliance (apart from that it wouldn't be MS style).

And basically that's end of "everyone should move" topic. The other top
browser apart from Firefox and IE already are Webkit (or will become, as Opera
announced).

[0] <https://brendaneich.com/2013/02/why-mozilla-matters/>

------
lignuist
All browsers? Even Lynx?

