In an email to the WebKit development mailing list[1] Håkon Wium Lie, the Opera CTO, mentioned that they've had engineers working on WebKit for a while now, and they'll soon be contributing their work on multi-column layout to the WebKit project.
At last. Opera used to be my favorite browser, thanks to their sophisticated UI. But I gave it up when HTML5 started coming in. I believe it had problems with Javascripts too.
Is mobile Opera very different from the desktop one? I see many Android users using it and being happy.
WebKit was the reason why I started using other browsers -- I'm very excited to see it in Opera!
I wonder what'll happen to Dragonfly, their integrated development platform? It was a neat project, although arguably inferior to Firebug/Chrome Dev Tools in many areas.
I was wondering that too. I assume Dragonfly will die and they will switch to WebKit/Chromium's dev tools instead. If that happens, I very much hope that they will rebuild Dragonfly's unique bits for WebKit's dev tools and submit them as patches, so nothing of value is lost.
High hopes for Servo[1], but it'll still be years yet until it's able to challenge any of those three. Webkit2[2] will probably be ready sooner, but it's less of a radical departure than Servo's intended to be.
Are you sure about that? When I read quotes like "web content (JavaScript, HTML, layout, etc) lives in a separate process from the application UI", that conjures images of a rather drastic and fundamental change. I'm not sure how you'd achieve that with just a new API layer.
Yes, I'm sure. The same core rendering engine, known as WebCore, is shared between both WebKit1 and WebKit2 on OS X. WebKit1 is used by most applications that use a WebView to display web content, while WebKit2 is used by Safari. The different API layers set up different delegate callbacks for WebCore so that they can tweak the behavior to fit their architecture (single process vs separate web and UI processes).
I'd like to see some serious work done on Dillo ( http://www.dillo.org/ ), which is much faster than chrome on low-end boxes and could be really good for developing countries.
At http://my.opera.com/ODIN/blog/300-million-users-and-move-to-... they state they're switching because they feel it is a waste of resources to maintain their own rendering engine. I'd be surprised if the JavaScript engine was a big factor in their decision. The vast majority of "JavaScript" problems encountered by web developers are either problems with the DOM implementation in general. A smaller portion are in the binding between the DOM implementation and the JavaScript language, and fewer still are in the JavaScript engine itself.
It is important to understand that when they said "javascript" they almost certainly meant "DOM". All mainstream javascript engines, including Carakan (the current Opera javascript engine), are very compatible with the standard and with each other.
On the other hand, DOM APIs are rather less interoperable across browsers for both historic (lack of clear standards until recently) and technical (larger surface area, faster pace of addition, lack of proper testsuites) reasons. Therefore they are by far the more likely place to run into an interoperability issue.
I have written a heavy JS proprietary Ajax app, and opera was very easy to get working.
Opera really follows the standards, and if I found any bugs they were often an indication of a fragile part of the code that needed fixing (Opera was very useful for finding dodgy areas of my code).
Of course it depends upon the features one is trying to use, not just the quality of the code :-)
I worked for Opera the summer of 2010 and I've also been using the browser the last couple of years.
Compared to Google, Apple, Microsoft - it is important to understand that Opera is a small, very small, company.
I'm very happy to see their resources better used to innovating and improve their exiting product, rather than trying to catching up to the other browsers.
A big loss for the general state of rendering platforms though, with now only Webkit, Trident and Gecko as serious contenders.
Considering they are switching to an open source rendering engine, I think there is likelihood they would have open-sourced presto already if that was possible. I suspect that like much proprietary software, there are too many licensed dependencies.
It's a pity, because it'd be very cool to get a source dump of the final presto engine. Even if it was never integrated into a new browser, the historical value alone would be significant.
Opera's response to Open-Sourcing always was, that they would have no business that way. Apple doesn't care I believe, Google/Microsoft are in it for search and ads, Firefox isn't a business (and they make all money from search I think). While Opera makes a lot of money from search, they have a lot of OEM deals that they are afraid to lose.
So if there was no legal constraint, Presto could see day of light. If nothing else, then in patches to webkit :)
I wonder if Opera is making an overture to get acquired by Google or Apple. Opera's innovative browser features have always been a bigger draw than the details of its Presto rendering engine.
What IP or userbase does Opera have that either Google or Apple would want? If either of the two of them wanted to copy Opera's browser features they would just go ahead and do so.
If anything this makes Opera less interesting as a potential purchase. Their rendering engine was a massive piece of original IP.
> If either of the two of them wanted to copy Opera's browser features they would just go ahead and do so.
They mostly do. Dozens and dozens and features. But it works other way around as well, and it's a great thing in the end. The most beneficial features are virtually on every browser.
As an aside, feature copying was one of the greatest sources of irritation my friends had when Opera was still this really weird, unique thing that I used and they didn't. It was quite regular to have them excitedly tell me to switch to Firefox because "Dude, there's tabbed browsing, it's SO great!" Uh, thanks, I've... I've had that for years. But I'm glad you're discovering it too!
If it runs faster, with less memory, or is easier to port to new platforms that the other browsers have problems reaching.
Do you remember how long it took Google to port Chrome to Android? There was a Firefox and Opera release for Android even before Google got their own browser ported to their own OS.
>>There was a Firefox and Opera release for Android even before Google got their own browser ported to their own OS.
That's why I installed opera on my phone. It works so good, I never bothered to install chrome on it. So it looks like I'm an Opera user. Granted I still use chrome/FF on everything else...
Opera is a huge hit in asia. And this is where Apple and Google struggle the most to get market share. That would make a lot of sense for either of them to try to acquire Opera.
No. There were rumours, and maybe something more than that (I know somebody whose hiring fell through because Opera went into the typical pre-acquisition "lockout mode", about a year ago), but in the end nothing happened.
I don't think it's a loss, I wouldn't mind if every browser switched to Webkit. Problems with cross-browser rendering differences would be gone, all browsers would use the same newest technologies and the engine would evolve much faster.
That's not really a problem. Experimenting by forking the dominant rendering engine is much more convenient than experimenting by building your own rendering engine from scratch. If your fork has advantages, it's also easier for other people to use your work.
There is a big difference between a standard and an implementation. If you only have one implementation (webkit), then developers will start being lazy and depending on certain quirks of that implementation. You reach a point where these quirks can't be changed, otherwise half the internet will stop working. Having multiple rendering engines means these quirks are more likely to be fixed, and not relied upon. It's also impossible to say if webkit will still be the dominant engine in 5-10 years.
For the same reason, this also leads to degradation, and slows down the evolution of the engine. A good example is gcc vs clang. For years gcc was the compiler for *nix, then clang comes along. This led to a new found enthusiasm to make parts of gcc better. The same happened for firefox when chrome came along. and works the other way. We even have half-decent IE releases now.
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.
No (though it will in fact do layout in parallel with JS execution by time-slicing its JS, last I checked, unlike other UAs).
My point is that it's bad if all browsers switch to WebKit and web sites absolutely require WebKit to work correctly, which is what the parent of my comment was suggesting should happen. This point is somewhat independent of what happens with Presto per se.
Because in this case it is open? I'm not for having a single implementation but I wouldn't complain if every single browser used the same engine. It still won't be ideal but this by default removes any incompatibilities (assuming the same branch of code is used--a potential problem that will crop up).
That's a couple hundred more than Mozilla has now (after Mozilla added a lot of employees in the past few years). OTOH, the numbers are no longer that significantly different.
It just matters that there are competing engines. As long as there are multiple implementations, we will have a formal standard for HTML and Co. If e.g. everybody (Microsoft,Mozilla) would adopt WebKit, then nobody would bother to extend the HTML standard. Just implement it in WebKit. Soon, HTML will be a mess like Office Open XML.
For historical reasons, Webkit has turned out to be much easier to work on than Gecko.
With Gecko you get heavy-duty OOP module system riding shotgun (XPCOM). That seems to be a sufficiently high barrier to contributors that only Mozilla are using Gecko with any seriousness.
Webkit has evolved out of a different history as a sorta-kinda standalone component of KDE to be much more approachable to outside contributions. Since Apple forked it from KHTML it's gone from strength to strength.
While I agree that webkit is a great piece of software, what happens when everybody switches to webkit? Will Google/Apple/developers simply ignore other engines and let it become the new IE of the decade?
Yes and no. Less work for frontend guys I believe. More choice for you, because you can get the same decent looking pages (theoretically) with a different UI of the browser.
And, IMO, here is where Opera wins - their UI is superior to Chrome's and Safari's.
Its ability to configure basically anything from user interface is far above any other browser. Chrome is a browser that I recommend to parents. It has dumbed down interface, zero options - perfect for average majority. It is still powerful when combined with dozens of extensions, but it still can't compete with Opera in this area.
It's like KDE vs Gnome3 if that makes more sense for someone.
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).
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.
> 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?
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.
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.
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'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.
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.
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.
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).
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.
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.
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.
> 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.
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.
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.
Nothing is as condescending to your customers as a smug "Sorry, we don't like your browser, go get a real renderer, then we'll talk" where 'real' is defined as "What I like to use".
And you're right, there seems to be a strong tendency towards mutual masturbation over the web. "Make what I want" is leading to this tiny little house of mirrors.
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.
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.
Interesting... I wonder if they'd now consider opening up their browser engine as an open source project?
Not for any reason other than, if someone in the future wanted to. They could fork it and extend it and perhaps make something awesome. Nothing may actually happen, but you never know if you don't give it a chance to...
As far as I hate monopoly and the things that happened years ago with IE6, I'm a bit afraid of what's going on here. I really appreciate the fact that coding a website with webkit bugs in mind will automatically include support of Opera browser now, but does this mean that the whole web will start to code exclusively for webkit engine? This doesn't feel good. I'm afraid webkit will start to dictate features and their bugs-workarounds such as [1] will remain untouched for years.
Besides the fact that I think Firefox is now actually a really great piece of software, this is a primary reason why I continue to use Firefox while everyone else in the office uses chrome.
Yes, you are right, I really love to hear that. But as a webdeveloper my first task after I write some code is to test it in a webkit browser. Webkit is everywhere iPad, iPhone, Chrome, Safari, ( now Opera ). I think bad developers will start to exclude other engines support if percentage of non-webkit browsers goes very low. And since a lot of websites are coded from amateurs ( there's nothing wrong to this ) there will be more and more webkit-optimized content. That's sad!
Note that there's some fragmentation in WebKit as well. I think that developers that assume it will make their lives a lot easier will be slightly disappointed in the end.
The "mobile" sites out there are overwhelmingly WebKit-only. We're talking sites from Google, Disney, Apple, various news sites, etc, not sites done by amateurs.
And they're not accidentally WebKit-only in many cases, but deliberately so.
Interesting move, but I guess it was pretty much inevitable considering how much WebKit has been surging ahead the last couple of years.
This might be wishful thinking, but I hope they'll expand the desktop team and spend more resources on UI and UX now that the UI basically is the only killer feature on the desktop. I'd love to see Opera on the innovation forefront once again!
I don't know a single web dev who tests on Opera anymore. I personally stopped worrying about it for any of my products when it hit 1.6% market share, and that was five years ago. They're essentially not supported by anybody, and haven't been for a long time.
... But that's never mattered, since they have always known it. And they went out of their way to make sure they rendered exactly like the dominant browser. For the longest time, they'd match Internet Explorer quirk for quirk, so if you supported that you supported Opera.
Now they see that Chrome is going to win, so they're switching to copying Chrome instead. And since Chrome has a nice drop-in "Chrome in a box" rendering engine they can use, it's going to be a lot easier to pull off this time around.
They'll continue to be the browser that nobody cares about (aside from six people who are no doubt here in this thread somewhere), but your site will probably render fine on it.
EDIT: Looks like those aforementioned Opera devotees have arrived. This comment went from 6 points and the top slot down to 1 point in the last ten minutes. Funny, since it's not actually an anti-Opera comment (or of course the sort of thing that down-votes here are usually reserved for).
"I don't know a single web dev who tests on Opera anymore."
Hi, I'm a dev who always develop for Opera. The reason: if it works in Opera it almost is working in all other browsers. And I ofcourse like Opera very much. I think it has one of the best interfaces and toolsets.
"They'll continue to be the browser that nobody cares about."
This is a very stupid statement. 300 million monthly users care about Opera.
The HN "community" != the rest of the world.
I run a site that is not technical at all, it's a legal site related to divorcing fathers. Last year the site had 1,111,795 total visits and 5429 of them were from Opera. So I'm not sure who is this community that cares that much about Opera but they are not in the US.
...running the current version of Opera. Most other people I know that use opera do the same thing to get around silly sites that won't even try to display their content.
It's moves like that which mean Opera has dug its own grave of irrelevancy. They should have given you the tools to enable spoofing on a per-domain basis only, not browser-wide.
You don't have to test for it if you are in a market where it has 1.6% share. There are a lot of markets where Opera has 10, 20, or 30% share.
As for the second paragraph, Opera was actually strict pro-standard.. sometimes for their own bad.
Third paragraph is total bullshit. If anything, Chrome is the one copying from Opera. Webkit isn't "Chrome in a box" either. And pull of what this time?
As mentioned in my first paragraph, Opera has and had users, just not in your market probably. I written several times why Opera has users in certain markets, so just tl;dr: Opera was the best browser but was paid. Anything East from Germany didn't really care for paying for software (since it was insanely expensive), so they used the best browser out there. When FF was born, west switched to it (since it was better than IE). Opera went free too late, but managed to hold quite a big user-base in certain areas despite Google pouring billions into advertisement and producing chrome-only features. (another big contributor is Turbo and slow internet speeds, but I think it was a secondary factor).
ad EDIT: cry me a river. While I don't feel the need to downvote you, your comment did sound pricky enough to convince someone to do so.
Also, Mobile browsers are not insignificant market: (whole) Europe 24% (50%)
Numbers from statcounter.com as of January 2013 (January 2010). I picked 2010 as it was about the time Chrome started it's push around here (I'm in Czech Republic at the moment) - ads in radio, tv, outdoors, on homepages of google.com, youtube.com; Opera was often blocked from accessing gmail, apps,; was deprived of features (by user-agent sniffing) google-wide. And FF was well established at the time, so it didn't carve much to the Opera's share.
Those are all immature web markets. By the time the majority of web users in those countries spend a significant amount of money online, they probably wont be using Opera anymore. If you're looking for more file-sharing users, sure, target these markets. But if you want to make money today then don't waste your time. (I've lived in, started/run businesses, and produced web products in Eastern Europe).
thank god for people like you who spread the word about how you can't make money on the web in those markets :) all I can say that you did not try hard enough :)
Not what I meant at all. I just meant that in my experience, the counties listed have relatively low median disposable incomes, and are generally not inclined to pay for web products.
>I picked 2010 as it was about the time Chrome started it's push around here (I'm in Czech Republic at the moment) - ads in radio, tv, outdoors, on homepages of google.com, youtube.com; Opera was often blocked from accessing gmail, apps,; was deprived of features (by user-agent sniffing) google-wide
I think by far the biggest impact was bundling Chrome and autoinstalling it with Java and Flash updates. Google must have paid top dollar for it which Firefox and Opera had no chance of matching.
Opera was actually strict pro-standard.. sometimes for their own bad.
Possibly. But they're also the only browser I'm aware of apart from IE that supports "document.all". And (at least as of 2007), they were still using IE's quirks mode box model if you didn't specify a doctype.
As I said, they did a good job of trying to please everybody. You could code for Firefox or IE and have a reasonable expectation that it would work on Opera too.
Either you agree that Opera implemented standards as strictly as possible (really the only way when you your own rendering engine with such a small market share) while aiming for compatibility at the same time (which is implemented by copying certain quirks--and O isn't the only one that does that--as well as having a large database of popular sites that are fixed with bits of custom JS), or you disagree that Opera aimed and successfully did implement web standards (which is provably false).
Saying "possibly" makes it sound like you don't really know. Did you consider, while typing that remark about the downvotes (bad form, and doesn't add anything to the discussion, except for polarizing it even more), that it might actually be caused by your self-admitted lack of knowledge on the subject?
Sure thing, those people may be "Opera devotees", because those are the people that know what they're talking about maybe?
You claim that top post was "not actually an anti-Opera comment". What about your remark that "They'll continue to be the browser that nobody cares about"? That was you baiting all of those European and Russian Opera users, that you may or may not have noticed are also here on HN. If you had said "the browser nobody in the US actually cares about" then yes, I could not have disagreed. But this general claim is a tad ignorant, the global 1.3% market share is not at all geographically evenly spread, and goes up to 47% in certain countries. That's a long shot from saying nobody cares about it.
(BTW I may be an Opera devotee--a little bit less than I was a few years ago though--but I'm not downvoting you)
>Either you agree that Opera implemented standards as strictly as possible (really the only way when you your own rendering engine with such a small market share) while aiming for compatibility at the same time
Noble aim but that doesn't work in the consumer world. I am pretty open-minded, so I am seriously trying to use Opera every 2 or 3 years. And each time I really start to enjoy using it but after one or two days I get horribly disappointed: a significant number of websites I like just doesn't work. Not just loss in function, they are completely unusuable, for instance I get a white page.
Last time I did this try is probably 2 years ago. Last time I observed this behaviour with another non-IE-browser: at least 5 years ago, probably more like 8.
There was a time when certain websites only worked with IE. Somehow Mozilla and friends adapted... but what happened to Opera? I cannot stop thinking that Opera somehow got stuck in the 90s. They are certainly innovative, they were the CSS pioneers, everybody copied tabs and other cool features.
But still... When your rendering is incompatible to the real world, nobody will use you. So I can only agree: smart move. Maybe this will make Opera a serious competitor in the Browser market again.
Anyway, I also agree, Opera still has a user base. I work on an in-house tool and we have users using Opera, so I test against it.
> Noble aim but that doesn't work in the consumer world. I am pretty open-minded, so I am seriously trying to use Opera every 2 or 3 years. And each time I really start to enjoy using it but after one or two days I get horribly disappointed: a significant number of websites I like just doesn't work. Not just loss in function, they are completely unusuable, for instance I get a white page.
You're saying that's the fault of Opera when it's possibly the fault of lazy devs.
You used to (still have?) devs testing for Opera and then preventing users going any further. Users would spoof the agent id string. So then devs started doing more tests, and rejecting Opera.
>You're saying that's the fault of Opera when it's possibly the fault of lazy devs.
Obviously it's "hobby devs" breaking the standards and Opera having low tolerance for that. As a matter of fact, a large part of the web's success is due to hobbyists. The hobbyists were only able to contribute to the success because it was and still is so easy. You don't have to be a HTML or JS guru to create a dynamic web page. On the other hand this allows for many devs that never even heard of HTML validators, JS linters etc.
I think it's good that most HTML/JS implementations are very fault tolerant. It's good and the decline of XHTML, XSLT and friends underlines that.
>You used to (still have?) devs testing for Opera and then preventing users going any further. Users would spoof the agent id string. So then devs started doing more tests, and rejecting Opera.
>(https://groups.google.com/group/alt.sysadmin.recovery/tree/b...)
In 2003 Mozilla and friends had the same problem sometimes too.
Except that is not true. Opera has a high tolerance, probably much higher than any other browser (out of necessity). But that doesn't help much if you're being blocked or sites constantly find new bugs in other browsers they decide to work around and thereby breaking it in any browser that is not one of the top 3.
It is true that Opera tried to reverse engineer more of the IE DOM than most others, for example we were the only ones to have attachEvent and friends. But in recent years that caused problems with sites that made false equivalences like "has attachEvent -> must be IE" and so non-standard features were being actively removed.
It is also true that Opera has been heavily involved in the standards process; both in codifying the legacy and in more forward-looking initiatives to add novel functionality to the platform. For example Hixie was working at Opera when he started work on what became HTML5. Opera's Simon Pieters wrote a spec for CSS quirks mode [2]. We have also been involved in numerous other specs, and in the beginnings of the effort to produce a comprehensive vendor-neutral testsuite for web platform technologies.
>I don't know a single web dev who tests on Opera anymore.
Hello. Now you know at least one. :)
Of course FF, Chrome/ium, Safari, IE take priority, but I still run everything by Opera too. I just love Opera and have since I discovered MDI > tabs in the early 2000s, among other things.
This change will make all that easier though, so nice to see it.
PS - I didn't downvote you, though don't consider your comment particularly worthy of upvotes either.
You are not being downvoted because of Opera devotees. You are getting downvoted because of your passive aggressive tone, similar to every single reddit comment which starts with "I know I'm going to be downvoted for this", nobody like the martyr argument.
And assuming your own use case and global world stats to decide what browser to support is not a smart way to do things. Just look at the CIS market and it will tell you another story for Opera, not supporting Opera there "because it only has 1.6% worldwide" would be a dumb reasoning. What matters for your choice is the market share on your properties, not on others' properties.
That's all in the interpretation. I saw nothing passive aggressive about what he said. He just stated his opinions (and what I believe to be many facts too) in a very mater-of-fact way. There's a difference between that and passive aggressive.
As far as Opera goes though, you both have a point. If you really want to drill down into the data then your argument stands but generally speaking, without being oh so concerned and preoccupied with complete and totally accuracy (like we often are on HN and miss the forest for the trees because of) Opera really isn't much to worry about. It's a great browser and all but you can bet that if you're building a new web property you're not going to see a lot of Opera users with 1.6% market share worldwide. Sure, you might get lucky (or unlucky depending on how you see it) and somehow get a swarm of Opera users but I also might win the lottery this week too.
Implies that Opera never innovates or has anything interesting to offer, and implies that instead they follow the market leader like-for-like. They were one of the first browsers to have tabs and supported many CSS3 properties without prefixes first. Just because they didn't support WebSuperFlySpeedySocketRockets the day the draft standard was out doesn't mean they don't innovate.
>copying Chrome
They're standards compliant, Chrome is standards compliant. Not "copying" Chrome.
No one's saying Opera hasn't innovated. Only that it's not very popular and that, in addition to their innovations, they follow trends. That's not a passive aggressive statement.
> They're standards compliant, Chrome is standards compliant. Not "copying" Chrome.
The commenter was suggesting that Opera is now choosing to be "standards compliant" because the current most popular browsers are, as opposed to Opera's choice in the past to be non-standards compliant to copy the top browser of that time, IE. If the top browser is standards compliant, and you want to copy it, what would your browser end up being?
No, they're literally copying Chromium. They're forking the source tree and including it as the rendering engine in their browser. That is a verbatim copy. There's nothing wrong with that, and I think it's a smart move and does not speak anything less of Opera (in fact it speaks probably a lot more), but it is a copy.
Before, Opera "copied" Trident by implementing the same quirks so pages behaved the same way. They were not standards compliant, and Trident was not standards compliant. Trident failed at certain implementations, and Opera deliberately failed at those same implementations to achieve the desired effect.
> No, they're literally copying Chromium. They're forking the source tree and including it as the rendering engine in their browser. That is a verbatim copy.
This is misleading nonsense. You led people to believe that they would just make a copy of Chrome, but they will obviously not just compile Chromium and give it a new name. They will most likely bring the entire Quick framework and their existing UI to the Chromium framework.
>I don't know a single web dev who tests on Opera anymore
You don't know very good web devs then. By far the easiest path as a developer is to develop for opera, then test the rest. You end up with far few problems that way. If you develop for firefox or chrome it is easy to write a bunch of stuff that works in that browser, but not in the other, and then you have way more work dealing with fixing it. Opera is strict enough that if it works there, it is almost certainly going to work everywhere else (not old IEs obviously).
Amazing how communities that railed against monolithic implementations and stagnation in the past are perfectly happy with it when it's "their team" that's becoming the monolith.
I'm not perfectly happy, there's not not much impact being unhappy is likely to have. Once a company makes a huge announcement like this, displeasure from the customer base is unlikely to cause them to change their minds until either they discover the change was a HUGE mistake and upsets lots of their customers and they lose significant market share OR they're forced to change because they go bankrupt.
Being unhappy isn't likely to change Opera's decision, of course, but... the reaction to Opera's decision is likely to influence other players.
For example, the difference between "bring on the monoculture" and "this is a sad day for web standards" is likely to influence Mozilla's future direction, both directly and indirectly (via the choices web developers make in supporting or not supporting Firefox).
How so? Like Chrome copied Safari because they're both using Webkit?
> They'll continue to be the browser that nobody cares about (aside from six people who are no doubt here in this thread somewhere), but your site will probably render fine on it.
That's the problem for you Opera bashers. It will now have room to grow and get a much bigger user base on PCs.
Here's a scenario: As a network provider I wish to subsidise the hardware on my tariffs further still. I can shape traffic, sell advertising and analytic's to achieve this. Now if only I could get a capable proxy service compatible with the common browsers on iOS and Android.
Is Opera's core proposition a browser or a service? What differentiates them from their competitors? I read this announcement as a candid admission that they can compete better with their proxy service than with their browser.
I suspect the future of Opera is as a SaaS proxy that happens to have a client ready too. A proxy for shaping or sniffing (mobile) traffic has many advantages to those in emerging markets and those who wish to push advertising down our throats coughcough Facebook and Google.
That's going to make them less competitive in my opinion, although it's an understandable move considering their size. I am wondering about the timing though - now that HTML5 is finally a standard and browser developers can stabilize their rendering instead of playing catch-up with the latest draft features, it's a bit late to switch. They would have benefited more by switching 2-3 years ago.
Wow, that's a huge step. Being the #4 rendering engine was really hurting Opera though. Most people use WebKit or Gecko during development and then make it work in IE as well, but never get to Opera. One of the main reasons I stopped using Opera for browsing was that, despite having some great features (always loved their gestures), so many sites just didn't work properly.
I hope this will only make them contribute more to pushing the web forward, as they have always done.
A win for web developers, in my humble opinion, as the rendering engines converge. With open source projects like WebKit, why do we need so many proprietary engines competing with each other? It creates more target environments for all the web developers and designers around the world to repetitively test.
This is a great example of how platforms, when open sourced, can beat proprietary silos which fuel the engine of capitalism. While the competition between proprietary silos, together with the copyright + patent protections they require, does drive innovation forward, it does it at great cost (in the amount of litigation required to protect the IP, in the lack of interoperability, and the increased cost for everyone producing for multiple platforms). By contrast, an open source project can develop much more similar targets that have incentive to interoperate and accept contributions from others. For example Linux variants, and now WebKit and its derivatives.
This is how it works - open source quality created by enthusiastic community wins proprietary crap produced by wage coders counting hours and lines of code.
This is how the end of the era of proprietary software (NOK, MSFT, ORCL, SAP, even AAPL) will look like.
This is complicated. Google tries to create (or emulate) something like community of individual engineers which rests on principles like "do no evil" or whatever. An order of some kind. It works. So, we could say that contributions are of individuals, not of Google. Even if contributors get paid for full-time, it is their own intention in the first place. At least it is what they want things to look like.
As for Apple, there are probably just programmers on a payroll. Apple has a different culture. It is a Steve's workshop, where they "invent" things, or whatever they think these days.
294 comments
[ 0.20 ms ] story [ 255 ms ] thread[1]: https://lists.webkit.org/pipermail/webkit-dev/2013-February/...
Is mobile Opera very different from the desktop one? I see many Android users using it and being happy.
http://www.whatwg.org/specs/web-apps/2005-09-01/
back then it was called Web Forms 2 and Web Applications 1.0.
I wonder what'll happen to Dragonfly, their integrated development platform? It was a neat project, although arguably inferior to Firebug/Chrome Dev Tools in many areas.
Good luck Opera!
Which will happen first, the death of one of (WebKit, Gecko, Trident) or a new popular rendering engine not related to any of them?
[1] https://github.com/mozilla/servo
[2] http://trac.webkit.org/wiki/WebKit2
Oh yeah also, while I guess it's missing a lot, the code is actually very, very readable. That's nice.
https://github.com/mozilla/servo/tree/master/src/servo (the actual layout engine part)
http://en.wikipedia.org/wiki/Safari_(web_browser)#WebKit2
A year ago I worked on an app with heavy JS frontend and frontend guys told that they can't make it work properly on Opera.
I'm sort of including dom<>js relations as part of the js problem tho.
On the other hand, DOM APIs are rather less interoperable across browsers for both historic (lack of clear standards until recently) and technical (larger surface area, faster pace of addition, lack of proper testsuites) reasons. Therefore they are by far the more likely place to run into an interoperability issue.
Opera really follows the standards, and if I found any bugs they were often an indication of a fragile part of the code that needed fixing (Opera was very useful for finding dodgy areas of my code).
Of course it depends upon the features one is trying to use, not just the quality of the code :-)
Compared to Google, Apple, Microsoft - it is important to understand that Opera is a small, very small, company.
I'm very happy to see their resources better used to innovating and improve their exiting product, rather than trying to catching up to the other browsers.
A big loss for the general state of rendering platforms though, with now only Webkit, Trident and Gecko as serious contenders.
But on the same note, I understand that using webkit will be better for Opera as a browser.
It's a pity, because it'd be very cool to get a source dump of the final presto engine. Even if it was never integrated into a new browser, the historical value alone would be significant.
So if there was no legal constraint, Presto could see day of light. If nothing else, then in patches to webkit :)
opera:about
and look at the list of Third Party Software...
What IP or userbase does Opera have that either Google or Apple would want? If either of the two of them wanted to copy Opera's browser features they would just go ahead and do so.
If anything this makes Opera less interesting as a potential purchase. Their rendering engine was a massive piece of original IP.
They mostly do. Dozens and dozens and features. But it works other way around as well, and it's a great thing in the end. The most beneficial features are virtually on every browser.
How can it be worth anything when the competition is free?
Do you remember how long it took Google to port Chrome to Android? There was a Firefox and Opera release for Android even before Google got their own browser ported to their own OS.
That's why I installed opera on my phone. It works so good, I never bothered to install chrome on it. So it looks like I'm an Opera user. Granted I still use chrome/FF on everything else...
It definitely feels like the winds of change.
EDIT: Found the article: http://www.arcticstartup.com/2013/02/12/opera-founder-sells-....
For the same reason, this also leads to degradation, and slows down the evolution of the engine. A good example is gcc vs clang. For years gcc was the compiler for *nix, then clang comes along. This led to a new found enthusiasm to make parts of gcc better. The same happened for firefox when chrome came along. and works the other way. We even have half-decent IE releases now.
It's not as if the browser vendors simply do a 'git pull && make' every couple of weeks.
But your point is taken.
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.
My point is that it's bad if all browsers switch to WebKit and web sites absolutely require WebKit to work correctly, which is what the parent of my comment was suggesting should happen. This point is somewhat independent of what happens with Presto per se.
That's true, but those companies also make much more products. Mozilla has significantly less employees than Opera.
What gives Google, Apple and Microsoft power is that they also own the platforms. (And now you'll understand why Firefox OS is a thing)
Hu, really? Would have thought the opposite as Mozilla gets 100 million dollars a year from Google.
That's a couple hundred more than Mozilla has now (after Mozilla added a lot of employees in the past few years). OTOH, the numbers are no longer that significantly different.
It just matters that there are competing engines. As long as there are multiple implementations, we will have a formal standard for HTML and Co. If e.g. everybody (Microsoft,Mozilla) would adopt WebKit, then nobody would bother to extend the HTML standard. Just implement it in WebKit. Soon, HTML will be a mess like Office Open XML.
With Gecko you get heavy-duty OOP module system riding shotgun (XPCOM). That seems to be a sufficiently high barrier to contributors that only Mozilla are using Gecko with any seriousness.
Webkit has evolved out of a different history as a sorta-kinda standalone component of KDE to be much more approachable to outside contributions. Since Apple forked it from KHTML it's gone from strength to strength.
That's a nice spin. Less rendering engines, more choice!
And, IMO, here is where Opera wins - their UI is superior to Chrome's and Safari's.
It's like KDE vs Gnome3 if that makes more sense for someone.
Of course, only desktop Firefox.
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'.
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).
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.
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.
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?
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.
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?
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.
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.
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.
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.
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.
So now you have a fixed WebKit that nobody else uses.
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.
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).
WebKit can be maintained, forked etc as the world pleases.
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.
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.
Their February 2013 results are at: http://gs.statcounter.com/#mobile_vs_desktop-ww-monthly-2013...
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.
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.
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).
How does one follow from the other? Technical monopolies are good if they're opensourced? I couldn't disagree with this more strongly.
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.
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.
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.
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.
And you're right, there seems to be a strong tendency towards mutual masturbation over the web. "Make what I want" is leading to this tiny little house of mirrors.
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.
EDIT -- from http://wtfjs.com:
parseInt('06'); // 6
parseInt('08'); // 0
Your language is bad, and you should feel bad.
parseInt('08', 10); // 8
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.
Sure you can. Read the Fine manual: https://developer.mozilla.org/en-US/docs/JavaScript/Referenc...
tldr: parseInt("08", 10);
> parseInt("08", 8);
returns 0 instead of NaN
https://lists.webkit.org/pipermail/webkit-dev/2011-December/...
Not for any reason other than, if someone in the future wanted to. They could fork it and extend it and perhaps make something awesome. Nothing may actually happen, but you never know if you don't give it a chance to...
[1]: http://stackoverflow.com/questions/14773587/possible-or-misu...
Bad developers are already ignoring everything except whatever single browser they [might have] tested in.
This move certainly is unsettling, but I think you can come up with a better argument about why.
The "mobile" sites out there are overwhelmingly WebKit-only. We're talking sites from Google, Disney, Apple, various news sites, etc, not sites done by amateurs.
And they're not accidentally WebKit-only in many cases, but deliberately so.
This might be wishful thinking, but I hope they'll expand the desktop team and spend more resources on UI and UX now that the UI basically is the only killer feature on the desktop. I'd love to see Opera on the innovation forefront once again!
I don't know a single web dev who tests on Opera anymore. I personally stopped worrying about it for any of my products when it hit 1.6% market share, and that was five years ago. They're essentially not supported by anybody, and haven't been for a long time.
... But that's never mattered, since they have always known it. And they went out of their way to make sure they rendered exactly like the dominant browser. For the longest time, they'd match Internet Explorer quirk for quirk, so if you supported that you supported Opera.
Now they see that Chrome is going to win, so they're switching to copying Chrome instead. And since Chrome has a nice drop-in "Chrome in a box" rendering engine they can use, it's going to be a lot easier to pull off this time around.
They'll continue to be the browser that nobody cares about (aside from six people who are no doubt here in this thread somewhere), but your site will probably render fine on it.
EDIT: Looks like those aforementioned Opera devotees have arrived. This comment went from 6 points and the top slot down to 1 point in the last ten minutes. Funny, since it's not actually an anti-Opera comment (or of course the sort of thing that down-votes here are usually reserved for).
Hi, I'm a dev who always develop for Opera. The reason: if it works in Opera it almost is working in all other browsers. And I ofcourse like Opera very much. I think it has one of the best interfaces and toolsets.
"They'll continue to be the browser that nobody cares about."
This is a very stupid statement. 300 million monthly users care about Opera. The HN "community" != the rest of the world.
I'd also love to know where 300 million is coming from, as it seems extremely high.
edit: Also, what is up with the throwing around of the word "irrelevancy" on HN lately. Usually in snarky contexts as well.
As for the second paragraph, Opera was actually strict pro-standard.. sometimes for their own bad.
Third paragraph is total bullshit. If anything, Chrome is the one copying from Opera. Webkit isn't "Chrome in a box" either. And pull of what this time?
As mentioned in my first paragraph, Opera has and had users, just not in your market probably. I written several times why Opera has users in certain markets, so just tl;dr: Opera was the best browser but was paid. Anything East from Germany didn't really care for paying for software (since it was insanely expensive), so they used the best browser out there. When FF was born, west switched to it (since it was better than IE). Opera went free too late, but managed to hold quite a big user-base in certain areas despite Google pouring billions into advertisement and producing chrome-only features. (another big contributor is Turbo and slow internet speeds, but I think it was a secondary factor).
ad EDIT: cry me a river. While I don't feel the need to downvote you, your comment did sound pricky enough to convince someone to do so.
The Chromium Embedded Framework (http://en.wikipedia.org/wiki/Chromium_Embedded_Framework) isn't too far from that. I'm not sure if Opera is using this project in particular, but they do mention using Chromium.
As there are so many would you mind listing a few?
Edit: my bad, the graph probably didn't refresh properly
Ukraine 20% (36%), Slovakia 6% (13%), Poland 7% (12%), Czech Republic 5% (10%), Russia 14% (32%), Belarus 32% (45%), Kazachstan 32% (16%)
Also, Mobile browsers are not insignificant market: (whole) Europe 24% (50%)
Numbers from statcounter.com as of January 2013 (January 2010). I picked 2010 as it was about the time Chrome started it's push around here (I'm in Czech Republic at the moment) - ads in radio, tv, outdoors, on homepages of google.com, youtube.com; Opera was often blocked from accessing gmail, apps,; was deprived of features (by user-agent sniffing) google-wide. And FF was well established at the time, so it didn't carve much to the Opera's share.
Why do you think Google is desperate to enter these markets right now?
I think by far the biggest impact was bundling Chrome and autoinstalling it with Java and Flash updates. Google must have paid top dollar for it which Firefox and Opera had no chance of matching.
Possibly. But they're also the only browser I'm aware of apart from IE that supports "document.all". And (at least as of 2007), they were still using IE's quirks mode box model if you didn't specify a doctype.
As I said, they did a good job of trying to please everybody. You could code for Firefox or IE and have a reasonable expectation that it would work on Opera too.
That's a good thing, by the way.
Either you agree that Opera implemented standards as strictly as possible (really the only way when you your own rendering engine with such a small market share) while aiming for compatibility at the same time (which is implemented by copying certain quirks--and O isn't the only one that does that--as well as having a large database of popular sites that are fixed with bits of custom JS), or you disagree that Opera aimed and successfully did implement web standards (which is provably false).
Saying "possibly" makes it sound like you don't really know. Did you consider, while typing that remark about the downvotes (bad form, and doesn't add anything to the discussion, except for polarizing it even more), that it might actually be caused by your self-admitted lack of knowledge on the subject?
Sure thing, those people may be "Opera devotees", because those are the people that know what they're talking about maybe?
You claim that top post was "not actually an anti-Opera comment". What about your remark that "They'll continue to be the browser that nobody cares about"? That was you baiting all of those European and Russian Opera users, that you may or may not have noticed are also here on HN. If you had said "the browser nobody in the US actually cares about" then yes, I could not have disagreed. But this general claim is a tad ignorant, the global 1.3% market share is not at all geographically evenly spread, and goes up to 47% in certain countries. That's a long shot from saying nobody cares about it.
(BTW I may be an Opera devotee--a little bit less than I was a few years ago though--but I'm not downvoting you)
I'm guessing OP meant possibly for the "sometimes for their own bad" part of the comment.
Noble aim but that doesn't work in the consumer world. I am pretty open-minded, so I am seriously trying to use Opera every 2 or 3 years. And each time I really start to enjoy using it but after one or two days I get horribly disappointed: a significant number of websites I like just doesn't work. Not just loss in function, they are completely unusuable, for instance I get a white page.
Last time I did this try is probably 2 years ago. Last time I observed this behaviour with another non-IE-browser: at least 5 years ago, probably more like 8.
There was a time when certain websites only worked with IE. Somehow Mozilla and friends adapted... but what happened to Opera? I cannot stop thinking that Opera somehow got stuck in the 90s. They are certainly innovative, they were the CSS pioneers, everybody copied tabs and other cool features.
But still... When your rendering is incompatible to the real world, nobody will use you. So I can only agree: smart move. Maybe this will make Opera a serious competitor in the Browser market again.
Anyway, I also agree, Opera still has a user base. I work on an in-house tool and we have users using Opera, so I test against it.
You're saying that's the fault of Opera when it's possibly the fault of lazy devs.
You used to (still have?) devs testing for Opera and then preventing users going any further. Users would spoof the agent id string. So then devs started doing more tests, and rejecting Opera.
(https://groups.google.com/group/alt.sysadmin.recovery/tree/b...)
Obviously it's "hobby devs" breaking the standards and Opera having low tolerance for that. As a matter of fact, a large part of the web's success is due to hobbyists. The hobbyists were only able to contribute to the success because it was and still is so easy. You don't have to be a HTML or JS guru to create a dynamic web page. On the other hand this allows for many devs that never even heard of HTML validators, JS linters etc.
I think it's good that most HTML/JS implementations are very fault tolerant. It's good and the decline of XHTML, XSLT and friends underlines that.
>You used to (still have?) devs testing for Opera and then preventing users going any further. Users would spoof the agent id string. So then devs started doing more tests, and rejecting Opera. >(https://groups.google.com/group/alt.sysadmin.recovery/tree/b...)
In 2003 Mozilla and friends had the same problem sometimes too.
Except that is not true. Opera has a high tolerance, probably much higher than any other browser (out of necessity). But that doesn't help much if you're being blocked or sites constantly find new bugs in other browsers they decide to work around and thereby breaking it in any browser that is not one of the top 3.
It is true that Opera tried to reverse engineer more of the IE DOM than most others, for example we were the only ones to have attachEvent and friends. But in recent years that caused problems with sites that made false equivalences like "has attachEvent -> must be IE" and so non-standard features were being actively removed.
It is also true that Opera has been heavily involved in the standards process; both in codifying the legacy and in more forward-looking initiatives to add novel functionality to the platform. For example Hixie was working at Opera when he started work on what became HTML5. Opera's Simon Pieters wrote a spec for CSS quirks mode [2]. We have also been involved in numerous other specs, and in the beginnings of the effort to produce a comprehensive vendor-neutral testsuite for web platform technologies.
[1] http://software.hixie.ch/utilities/js/live-dom-viewer/saved/... [2] http://quirks.spec.whatwg.org/
Not quite. They always made every effort to be as compatible as possible with real world sites.
Hello. Now you know at least one. :)
Of course FF, Chrome/ium, Safari, IE take priority, but I still run everything by Opera too. I just love Opera and have since I discovered MDI > tabs in the early 2000s, among other things.
This change will make all that easier though, so nice to see it.
PS - I didn't downvote you, though don't consider your comment particularly worthy of upvotes either.
And assuming your own use case and global world stats to decide what browser to support is not a smart way to do things. Just look at the CIS market and it will tell you another story for Opera, not supporting Opera there "because it only has 1.6% worldwide" would be a dumb reasoning. What matters for your choice is the market share on your properties, not on others' properties.
As far as Opera goes though, you both have a point. If you really want to drill down into the data then your argument stands but generally speaking, without being oh so concerned and preoccupied with complete and totally accuracy (like we often are on HN and miss the forest for the trees because of) Opera really isn't much to worry about. It's a great browser and all but you can bet that if you're building a new web property you're not going to see a lot of Opera users with 1.6% market share worldwide. Sure, you might get lucky (or unlucky depending on how you see it) and somehow get a swarm of Opera users but I also might win the lottery this week too.
>the browser that nobody cares about
>Now they see Chrome is going to win
Implies that Opera never innovates or has anything interesting to offer, and implies that instead they follow the market leader like-for-like. They were one of the first browsers to have tabs and supported many CSS3 properties without prefixes first. Just because they didn't support WebSuperFlySpeedySocketRockets the day the draft standard was out doesn't mean they don't innovate.
>copying Chrome
They're standards compliant, Chrome is standards compliant. Not "copying" Chrome.
It doesn't actually imply any of that.
No one's saying Opera hasn't innovated. Only that it's not very popular and that, in addition to their innovations, they follow trends. That's not a passive aggressive statement.
> They're standards compliant, Chrome is standards compliant. Not "copying" Chrome.
The commenter was suggesting that Opera is now choosing to be "standards compliant" because the current most popular browsers are, as opposed to Opera's choice in the past to be non-standards compliant to copy the top browser of that time, IE. If the top browser is standards compliant, and you want to copy it, what would your browser end up being?
Before, Opera "copied" Trident by implementing the same quirks so pages behaved the same way. They were not standards compliant, and Trident was not standards compliant. Trident failed at certain implementations, and Opera deliberately failed at those same implementations to achieve the desired effect.
This is misleading nonsense. You led people to believe that they would just make a copy of Chrome, but they will obviously not just compile Chromium and give it a new name. They will most likely bring the entire Quick framework and their existing UI to the Chromium framework.
You don't know very good web devs then. By far the easiest path as a developer is to develop for opera, then test the rest. You end up with far few problems that way. If you develop for firefox or chrome it is easy to write a bunch of stuff that works in that browser, but not in the other, and then you have way more work dealing with fixing it. Opera is strict enough that if it works there, it is almost certainly going to work everywhere else (not old IEs obviously).
For example, the difference between "bring on the monoculture" and "this is a sad day for web standards" is likely to influence Mozilla's future direction, both directly and indirectly (via the choices web developers make in supporting or not supporting Firefox).
How so? Like Chrome copied Safari because they're both using Webkit?
> They'll continue to be the browser that nobody cares about (aside from six people who are no doubt here in this thread somewhere), but your site will probably render fine on it.
That's the problem for you Opera bashers. It will now have room to grow and get a much bigger user base on PCs.
Is Opera's core proposition a browser or a service? What differentiates them from their competitors? I read this announcement as a candid admission that they can compete better with their proxy service than with their browser.
I suspect the future of Opera is as a SaaS proxy that happens to have a client ready too. A proxy for shaping or sniffing (mobile) traffic has many advantages to those in emerging markets and those who wish to push advertising down our throats cough cough Facebook and Google.
I hope this will only make them contribute more to pushing the web forward, as they have always done.
http://www.pocket-lint.com/news/49375/opera-ice-new-webkit-b...
http://www.theverge.com/2013/1/19/3892646/opera-shows-off-ne...
(those were posted here but didn't get any discussion so I won't bother linking)
This is a great example of how platforms, when open sourced, can beat proprietary silos which fuel the engine of capitalism. While the competition between proprietary silos, together with the copyright + patent protections they require, does drive innovation forward, it does it at great cost (in the amount of litigation required to protect the IP, in the lack of interoperability, and the increased cost for everyone producing for multiple platforms). By contrast, an open source project can develop much more similar targets that have incentive to interoperate and accept contributions from others. For example Linux variants, and now WebKit and its derivatives.
This is how the end of the era of proprietary software (NOK, MSFT, ORCL, SAP, even AAPL) will look like.
As for Apple, there are probably just programmers on a payroll. Apple has a different culture. It is a Steve's workshop, where they "invent" things, or whatever they think these days.
I've always loved Opera for its features, but really disliked the rendering engine.