Mixed emotions here. I think it makes every sense for Opera to do this. The cost of maintaining their own rendering engine must have been huge and the advantages it brought were slender.
It's also good to have another major player contributing to webkit.
On the other hand it's a step closer to an unhealthy monoculture in rendering engines. It's already the case for the mobile web that people are starting to define standards as 'whatever webkit does'.
I wonder if, ironically, rendering engine diversity is something where the slow, incoherent Android update mess is actually a good thing.
To the extent that "whatever WebKit does" gets defined as "whatever ugly, lowest-common-denominator thing that works in the stock Gingerbread browser" that might help other rendering engines stay in the race. In other words, legacy Android browsers might help by slowing down the spread of new WebKit-specific features (that they also don't support).
Is a monoculture as bad as it might seem though? Front end web development is a clusterfuck. Webkit is open source, unlike the almost monoculture that ie6 represented. It can be forked and evolution can continue. Ditch -webkit -mos and -o. Like when the dinosaurs experienced a mass extinction event and mammals bloomed from a shrew into cats and humans.
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.
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.
>>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.
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".
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.
> 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.
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.
Not quite, you need 2 elements for evolution, (1) variation and (2) selection. Selection comes from anything in the environment, it can and often does come from climate, geology also, data suggest the rate of change through evolution increases when populations are lower as variation is more significant. Such analysis of natural selection can break down when applied to market forces as the continued existence of an intity is sometimes of secondary interest to the controlling party, which does not happen with species.
The current monoculture is much worse. It's a monoculture where the developers are not supporting the popular thing because it's popular, but also because it's what they themselves prefer. This is much more dangerous and it spills over to other areas. If you walked into a coffee shop in San Francisco you'd be hard pressed to see anything other than macbooks, iphones, and chrome (maybe safari a little bit). So forget about WebKit, there are plenty of sites out there that specifically target iOS and iOS only. This is not going to get any better.
Since webkit is opensource and largely a collaborative effort, I think the monoculture will be a good thing. Instead of having multiple vendors working on multiple competing products, they can now work on multiple competing features.
My line of thinking was that it takes X units of effort to implement feature Y. If two companies develop competing products, then 2X units of effort have been used to accomplish 1 feature Y.
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.
Those kind of assumptions are highly idealistic and theoretical, usually don't hold true in the real world.
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.
A monopoly is bad for competition, but do we need competition in a market where pricing is irrelevant? It's better to have all vendors collaborating on a standard engine than multiple proprietary ones. What are the negatives?
You need competition for technical evolution. Pricing has nothing to do with this.
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.
Why? how is competition better than collaboration?
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.
> it was never constrained because of compatibility concerns over non-standard features.
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.
While likely true, the value of multiple UAs as opposed to a monoculture is that it increases the likelihood that a revolutionary implementation that _can_ scare well to large number of cores would be able to get any traction at all instead of just being stillborn because it doesn't duplicate all the bugs of the monoculture.
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.
What you're describing is "innovation" in its weakest form. It's basically incremental improvement, rather than real innovation.
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).
The problem with evolution is that it's slow and can never reach parts of the problem space that require too large a leap.
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.
Well, webkit being something open and contributed to by many players in collaboration, couldn't we think of it as part of the standard itself? There isn't some evil monopoly to be had in only having one rendering engine, as much as there isn't so in having web standard technologies such as HTML5 and CSS3.
I think this is right on for Opera, it has always set itself apart by it's usability and features and I think browsers need to get innovating more on that front.
The problem of having the standard defined by an implementation is that it makes it almost impossible to have another implementation.
This is fine if we agree here and now in 2013 that WebKit is the only rendering engine we'll ever need.
That just doesn't seem like a smart bet to make. Opera was in some ways better than the WebKit browsers on mobile devices, except for broken Webkit only sites. That ain't going to get better now.
It's even worse. You're letting the standard be defined by a specific version of an implementation. It would impede progress for future versions of the same implementation.
For example today I just browsed my Internet provider's customer area. Their online invoicing page only works on Firefox and IE7, but not IE8, IE9, Opera and Chrome. Urgh.
> That just doesn't seem like a smart bet to make. Opera was in some ways better than the WebKit browsers on mobile devices, except for broken Webkit only sites. That ain't going to get better now.
But a de facto standard (ie one defined by a popular implementation) forces sites to be compatible or be ignored. More monolithic standard => stronger coding conventions => more robust web. Or am I being totally idealistic?
Robustness does not come from more rigid standards. For instance, it doesn't matter how standardized JavaScript is, it will still be a bad language in so many ways. If anything, standardization locks in the bad feature set, making is far harder to remove or fix.
Robustness often comes from the opposite approach. It's the willingness to throw out ideas and code that are observed to be broken. Replacing JavaScript with a more sensible scripting language like Lua or Python would increase the robustness of the web, while standardizing it further only entrenches the problem deeper.
A lot. The problems should be quite apparent to any developer who has used any mainstream programming languages aside from JavaScript and PHP. But for those who don't have such experience, a few quick Google searches should turn up more than enough information indicating the problems with JavaScript. There's no need to rehash it here.
No, it's not quite apparent at all, and no, a few Google searches did not yield any useful information. (I do however like the high horse you're on, very nice breed indeed.)
I call on your "no need to rehash it here." Without even one good example, I'd say you're just trying to be elitist.
I'm sorry to hear that you've had so much trouble with this very simple exercise.
Let me help set you on the right path. Google for "javascript semicolon insertion". After reading about it, it should be very apparent to you how it's a very large flaw with the language, and how it can be extremely harmful.
Do some research into JavaScript's equality operators. Any good programmer will be sick to his or her stomach after reading about how broken such basic, yet essential, functionality like that is.
And that's just the start, my friend. I encourage you to do further research on your own. You'll find no shortage of serious issues to learn more about.
But a de facto standard (ie one defined by a popular implementation) forces sites to be compatible or be ignored.
No, it's totally the opposite. They only have to be "compatible" with this one implementation, and are free to rely on all implementation-specific bugs or implementation defined behavior when doing so.
Think IE box model around the IE5/6 age. Or hell, supporting Office Documents. Even if you'd have the source, being compatible certainly wouldn't have gotten much easier.
Note that WebKit is open source and Opera is having problems being bug-compatible with it.
Indeed - in principle. But that was back when MS handed down IE binaries from the mountaintop whenever it wanted and most people ran different proprietary OSes. WebKit is open source and it runs on every major platform.
Although there is a chance here for the -prefix-rabbit-hole to yawn wide, there's also an opportunity for a (nearly-)universally-supported rendering engine to emerge that could, one day, get into bed with the standards committee. Surely this would be a good endgame for the browser wars?
The only worry here, as always, is that an implementation will come to define the standard rather than the other way around.
Note that coding to an implementation rather than a standard does stifle innovation, because when you code to target the implementation you inevitably rely on bugs in the implementation, without ever knowing or trying to. From the perspective of an implementor, would you fix a bug even if it meant breaking an unknowably large number of websites? If not, you've adopted that bug for the rest of time, and every subsequent implementation, ever, will be forced to implement the bug as well when they could be busy implementing new features. Now compound this by thousands of bugs, and reflect on all the time spent implementing Quirks Mode in every browser engine that exists today.
I do agree with you that in a perfect world we wouldn't need multiple implementations, because bugs would not exist and the lone implementation would track the standard perfectly, and because the standard would be controlled by neutral third-parties. But I think it's much too soon to declare the current era the browser endgame.
Yes, because when IE was the dominant browser that was totally the case.
Don't forget that on mobile platforms, not including Windows Phone, WebKit is already the standard engine. Safari, Android's stock browser and Chrome all use WebKit and developing for mobile is a ghetto, especially because each version has their own quirks and bugs (and there are dozens of Android stock browser variations in active use at any given time).
Yes, but just because there is one engine, doesn't mean there is one standard. Just like during IE's monopoly there were several versions of the browser to deal with (each with their own quirks), an engine monoculture (Webkit or otherwise) does not guarantee ease of development at all.
I agree that if there is to be a rendering engine monoculture, it might as well be open source, but that in itself guarantees nothing.
IE was dominant on one OS. It wasn't dominante on anything else than Windows world. Please, and that dominion lasted no more than 10 years. It ended with Android and iOS.
Windows was (and still is) the dominant desktop OS. Until recently, it was a very dominant dominance, with competitors usually making up less than 5% of the market share.
Even today, mobile users typically account for only about 10% to 15% of a site's traffic, for sites that don't directly target mobile users. Mobile just isn't as important or widespread as a lot of people think it is.
I don't know wich sites you are watching. All the sites I do control mobile is rocketing away from the desktop. Last year it duplicated. This year looks like it will be higher.
It gives a good sense of the current situation. Mobile browser usage is under 15%. It's nothing compared to the usage of desktop browsers. The growth from 2011 and 2012 isn't even that impressive, given the all of the hype and attention surrounding mobile.
That's the most scary thing of all. Although open-sourced webkit is mostly developed by big companies ( Apple, Google, Adobe .. ). Webkit is not perfect. There are a lot of bugs that nobody cares and will care less. Imagine what will happen if there are no competitor and webkit core engineers do whatever they want and still people use their engine. Prefixes like '-webkit-animation' will remain forever and w3c specs will not be a significant for them.
If there's bugs you care about, then you patch them. WebKit is open source, so anyone can fork it and build their own version with any fixes or changes they like. I don't see anything but positive news from this.
> WebKit is open source, so anyone can fork it and build
> their own version with any fixes or changes they like.
You're committing an error here. Say you find a bug in Webkit. You patch it, but Apple declines to accept it upstream. You fork the project. Now how do you get your fork into the hands of your users? Unless you're secretly Google in disguise, you're SOL.
But it's not that easy. It's one thing to add a missing feature to a Ruby gem or event to jQuery, but WebKit is a much bigger beast. Most geeks can't realistically patch things in a big heap of C++ code like that...
The codebase is pretty big... and I think you're right that someone can pop in and contribute to smaller projects much more easily. But I've poked around in it and it's not that bad. If you put a week into understanding it, it's not nearly as daunting.
It's about the same as when you start at a company with a large existing codebase. You're not going to get much done until you've read and understand the chunks of the code that relate to what you need to do. This spinup time is definitely bigger than the hour it can take to fix a bug in a small project that you previously had no experience with, but it's definitely within the realm of the possible.
Unhealthy? I've been longing for the day that all browsers are based on WebKit, because it means a real web programming language will be that much closer to replacing kiddiescript.
This comes up every now and then. That code makes perfect sense. You write octal numbers by prefixing them with a zero, the same way you write hexadecimal numbers by prefixing them with a '0x'.
C wasn't bad for making that design decision in 1973, to include syntactical space for octal numbers. Programmers actually used octal notation then. It made sense in an environment where contemporary tech included the PDP-8's 12-bit words (four octal glyphs) and displays of seven-segment numeric readouts (where octal is useful, as letters for hexadecimal can't be displayed and base-10 needs conversion logic.)
Javascript was bad for making that design decision in 1995, when nobody seriously used octal for anything, so the leading zero was vastly more likely to introduce a class of WTF bugs instead.
No, because strtol gives you the ability to see that the parse failed and where. You chose to give it NULL there, but you could choose to use the function correctly. You can't do it correctly in the javascript and PHP cases. In the PHP case, it is actually just a bug in the PHP codebase that octal digits are supported at all, and they don't use strtol correctly. Note that perl, python and ruby all support octal digits correctly, there really is no excuse for PHP and javascript not to.
We're not talking about parsing in base 10, we're talking about parsing in base 8. I need to be able to tell if the parse succeeded or not, silently hiding errors is bad. The correct behaviour demonstrated in perl and python:
$ perl -le 'print 07'
7
$ perl -le 'print 08'
Illegal octal digit '8' at -e line 1, at end of line
Execution of -e aborted due to compilation errors.
$ python -c 'print 07'
7
$ python -c 'print 08'
File "", line 1
print 08
^
SyntaxError: invalid token
Returning 0 makes perfect sense. parseInt matches an integer from the beginning of the string, so it reads the 0 and then stops at the 8 because 8 is not a valid digit in base 8.
It's also good to have another major player contributing to webkit.
On the other hand it's a step closer to an unhealthy monoculture in rendering engines. It's already the case for the mobile web that people are starting to define standards as 'whatever webkit does'.