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?
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.
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.
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.
If everyone switched to one browser engine competition would surely rise again after a couple of months or years. Engine features will differ and WebKit forks will compete even more. The market would roughly be at the same point it is now, it just started off of one engine.
"IE6 never had any meaningful competition until Firefox came along, then lo and behold, all browsers started getting a lot better a lot quicker."
You don't think it had anything to do with the introduction of Safari and Webkit, more than a year earlier?
Also, the last version of Internet Explorer for Mac was v5.2, which by 2004 was getting pretty long in the tooth. Many Mac users had already switched from IE to other browsers by the time Firefox was released (let alone when it was halfway decent).
You don't think it had anything to do with the introduction of Safari and Webkit, more than a year earlier?
Safari was utterly irrelevant until the late 2000s, where it only gained relevance through the iOS devices. It did nothing to spur movement. Further from a history perspective, while Safari might have preceded the coining of the Firefox brand, Firefox was an offshoot of the Mozilla Suite (effectively splitting the browser out of the suite) with a history going back to 1998.
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."
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?
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.
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.
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.
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).
I'll have to admit, I could not for the life of me tell if the entry was sarcastic or sincere. He seems to think there is only one WebKit, which numerous articles following the news of Opera's switch has made clear isn't the case.
He is also assuming that because every major browser is using the same engine, everyone will suddenly magically agree with one another on how to do stuff. Chrome and Safari uses different versions of WebKit, and trust me, it won't be long before Opera will use its own version of WebKit as well.
"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."
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.
It's actually what's happening on mobile. Everyone uses webkit but they all have a different version, with their own set of patches and compilation options.
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.
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.
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.
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.
Remember Microsoft basically invented AJAX and XHR back in IE5/6. You could also run XSLT in the browser to easily transform the XML data to HTML presentation. No other browser had these capabilities for years.
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.
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.
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.
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)
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.
Firefox shot itself in the foot when they started breaking everyone's add-ons and plugins about three times per week (an exaggeration, but not by much).
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... and would be interested in hearing what others have to say.
> 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"?
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).
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?