Yes, but only on WebKit-derivates. To use your analogy, it's sort of like trying to make better dinosaurs and deciding that we might as give up on apes at this point, because they don't seem as powerful and get eaten by the dinosaurs anyway.
Well, that's how evolution works. Some species DO get extinguished.
This Opera species wasn't adaptive enough.
If we want web engine evolution happening somebody should build a BETTER than Webkit engine (e.g the Mozilla Rust/Servo team).
Keeping not-that-good engines for the sake of "competition" is not evolution, it's life in "life support".
Yeah, and I'm pointing out it's the ones with more hope for the future, rather than the ones that are obviously doomed in the very long run.
If we want web engine evolution happening somebody should build a BETTER than Webkit engine
Yes, and as already explained, this will become near-impossible if there is no standard, but just a bunch of webpages that need the renderer to do "whatever WebKit does".
A big factor in Operas decision was already that for mobile webpages, any renderer that isn't WebKit is already dead. Not that they thought their own engine sucked.
This is stopping evolution, not helping it.
>>Yeah, and I'm pointing out it's the ones with more hope for the future, rather than the ones that are obviously doomed in the very long run.
I don't understand what this means. If you want to use evolution as an analogy, you should accept the fact the those that get extinguished were simply inferior to adapt and LESS "hope for the future".
>Yes, and as already explained, this will become near-impossible if there is no standard, but just a bunch of webpages that need the renderer to do "whatever WebKit does".
We got the Canvas and AJAX DESPITE the standard (one from Apple, the other from MS) not because of it. Those were only standardised after the fact.
Contrary to what you claim, evolution doesn't play well with standards -- then you wouldn't have competition, just some committee deciding what the spec should be and several implementations. Implementing the same predetermined spec is hardly "evolutionary".
>A big factor in Operas decision was already that for mobile webpages, any renderer that isn't WebKit is already dead. Not that they thought their own engine sucked.
Well, it kind of helped that it also kind of did suck. Opera was forever dragging behind the other engines.
Not at all, it's a phenomenon called "getting stuck in a local optimum" (as opposed to the global one).
Contrary to what you claim, evolution doesn't play well with standards -- then you wouldn't have competition, just some committee deciding what the spec should be and several implementations. Implementing the same predetermined spec is hardly "evolutionary".
You seem to have an incorrect understanding of how W3C standards appear. Browsers implement a new feature (through prefixing), often competitively, and if it's considered generally useful the browser vendors get together and try to agree on a common API that is most useful and sane. After a while the prefix goes away and the standardized API is used. There's been some complaints about WebKit refusing to do the latter, which surely is a contributing factor to Opera's decision.
Without this common API, you'd have no chance in implementing the same features independently. Without vendor competition, there's no incentive to standardize the API, which precludes future competition.
The current web and especially WebKit itself thank their existence to such a spec.
In the case of canvas, not really. Apple created canvas for Dashboard widgets. Were it not standardized, canvas would never have been a web technology.
How does one follow from the other? Technical monopolies are good if they're opensourced? I couldn't disagree with this more strongly.
If both of those companies are working on the same product, then it might follow that 2X units of effort would lead to the implementation of feature Y and feature Z. Or that feature Y is implemented in less time.
It depends a lot upon the talent of the people involved, their past experience, their knowledge, and so forth. It also depends on the systems in question.
The amount of effort needed to build some particular functionality can vary immensely between two experienced developers working for the same organization on the same system. It usually varies even more so when multiple organizations are involved, or multiple systems are involved.
As pointed out elsewhere in this thread, a WebKit monoculture will stifle technical innovation in web rendering engines, because they'll be constrained with being (bug-)compatible with WebKit.
webkit routinely gets breaking changes, it was never constrained because of compatibility concerns over non-standard features. Wouldn't having a load of developers in different environments, working on the same codebase actually accelerate innovation? Something could go from W3C/WHATWG draft to implementation in a matter of weeks, then we wouldn't have things like css3 gradients or flexbox syntax changing completely after years prefixed in the wild.
Seriously? You should go read the www-style archives or public-html archives or the relevant W3C bug databases sometimes for all the things the WebKit folks refused to implement (and still do) precisely because of such concerns.
> accelerate innovation?
Innovation and feature addition are not the same thing.
Please explain to me how building a rendering engine that scales well to 64 cores would be accelerated by starting with WebKit as a base, for example.
I don't know enough about the webkit architecture to say anything, but I guess it wouldn't be any faster if it started with Presto.
So my point wasn't that one would build such a UA by starting with Presto. My point was that there are distinct advantages to competition over everyone using the same rendering engine.
Real innovation is far more drastic and disruptive. When it comes along, it often meets heavy resistance from those who are entrenched, especially when these people may not benefit from it. This is true even within open source projects. Unorthodox ideas will often be brutally crushed, even if the benefits they provide are immense.
So the question is is a fork "true" competition or more of a "suggestion" for a feature change?
Or to put it another way, instead of evolution happening (as in the best win and the worst die) we now have a situation where the winners and losers are decided by subjective individuals (i.e. some project manager somewhere decides to import a forked branch back into their main branch).
In the case of web rendering engines, for example, I don't see "evolution" getting us to a rendering engine that can usefully parallelize over, say, 64 cores starting from the engines we have right now. And monoculture would ensure that we never get there.