User: Password:
|
|
Subscribe / Log in / New account

Opera moves to WebKit and V8

Opera moves to WebKit and V8

Posted Feb 15, 2013 22:33 UTC (Fri) by philipstorry (subscriber, #45926)
In reply to: Opera moves to WebKit and V8 by Company
Parent article: Opera moves to WebKit and V8

Except this is an engine that can be fixed by anyone when it's broken.

I'd agree that the software monoculture aspect of it is less attractive - webkit is going to have to be very secure!

I've been using Opera for years. (Since v3, and I paid for several versions.) I'm typing this in Opera right now. It's a great browser. But there are some websites that it still doesn't quite work with.
Nothing major - and often worked around by simply using Site Preferences to spoof the user-agent. But it's not perfect.

Neither is Chrome, nor is Firefox. They all have either rendering behaviour or an interface quirk which bugs me. Opera just bugs me the least.

This at least means that Opera will be feeding back code to WebKit. Perhaps WebKit will get an option to handle zooming in Opera's much better way. Perhaps some of the excellent work on reflowing that Opera has done over the years will slip into WebKit.

Overall, this looks like a good thing for all concerned...


(Log in to post comments)

Opera moves to WebKit and V8

Posted Feb 15, 2013 23:16 UTC (Fri) by josh (subscriber, #17465) [Link]

> Except this is an engine that can be fixed by anyone when it's broken.

When "broken", sure; however, that doesn't stop sites from saying "best viewed in a WebKit-based browser". Already a fair number of sites only work on Chrome or other WebKit-based browsers; most commonly, mobile sites that just break, and supposedly "HTML5" demo sites that use -webkit-* prefixed CSS and otherwise only work in WebKit-based browsers.

Opera moves to WebKit and V8

Posted Feb 15, 2013 23:58 UTC (Fri) by philipstorry (subscriber, #45926) [Link]

Oh, here you'll find no disagreement from me.

Idiot web designers will be idiot web designers. And they'll assume WebKit means Safari, or that it means a mobile device. And they'll code for prefixed CSS but do it incompletely and sloppily.

I can't really do anything but condemn that.

But on the other hand, if these idiots can't even handle Chrome also using WebKit, then why does it matter if Opera is using Presto or WebKit?

They were going to support Opera badly either way. Just like they were going to support Chrome badly, or non-mobile WebKit instances badly.

Idiot web designers will be idiot web designers. :-(

Opera moves to WebKit and V8

Posted Feb 16, 2013 0:12 UTC (Sat) by josh (subscriber, #17465) [Link]

It matters because they can get away with it more easily if WebKit has a larger market share. Similarly, the larger the market share of Linux and OS X, the less easily people can get away with exclusively targeting Windows.

Opera moves to WebKit and V8

Posted Feb 15, 2013 23:57 UTC (Fri) by jke (guest, #88998) [Link]

I don't know that there's a one-size-fits-all category of "monoculture." We know the extreme example, IE6, but does webkit deserve to be put in that bracket?

For one it's not solely influenced by one "culture." Adding Opera developers adds to the mix, doesn't it?

It also differs from the IE6 extreme because there doesn't seem to be a lot of evidence (so far) that we're getting stuck on one version of it. Is it going to be the case that we'll need to go dig up some ancient unmaintained version to keep compatibility with some mission critical junk that no one can fix? From what I see everyone's updating to newer versions of webkit Willy-nilly and not looking back much.

Maybe I'm not buying into the right paranoia but is monoculture an overstated problem with open source software in active development?

Opera moves to WebKit and V8

Posted Feb 16, 2013 0:06 UTC (Sat) by philipstorry (subscriber, #45926) [Link]

My main monoculture concern is simply the security one - that a sufficiently bad WebKit flaw could expose a huge number of users.

Otherwise, I don't disagree with you - the monoculture of an open source project is far preferable to a closed source one.

I also think that such monocultures - like the Linux kernel itself, of which there is only one but which is used by many different distributions - has shown that it can be reactive enough and diverse enough that the security concerns aren't much more or less worse than any other monoculture.

Which brings us back to the fact that Opera's action is effetively trading off the strengths of diversity for a hopeful strengthening of a monoculture. It's kind of easy to see why some people are a little uneasy about it.

(But as I've said, I'm for it - providing I lose no features in Opera!)

Opera moves to WebKit and V8

Posted Feb 16, 2013 19:27 UTC (Sat) by kripkenstein (guest, #43281) [Link]

> I don't know that there's a one-size-fits-all category of "monoculture." We know the extreme example, IE6, but does webkit deserve to be put in that bracket?

An open source monoculture is better than a proprietary one, for sure. But it's still bad.

Aside from security issues, there is the concern for standards. Standards are meaningless with a single implementation. And without standards, making additional implementations is extremely hard. Right now, it is possible for someone to write a new web browser with new technical improvements - they would implement the standards. If WebKit is the new IE6, then a new browser would have to do "what WebKit does."

> For one it's not solely influenced by one "culture." Adding Opera developers adds to the mix, doesn't it?

Not much. Opera is going to be shipping a rebranded Chrome - they aren't even taking WebKit, they're taking Chromium. Opera will differentiate through UI, it appears - hard to see what else they can.

Opera moves to WebKit and V8

Posted Feb 17, 2013 18:13 UTC (Sun) by khim (subscriber, #9252) [Link]

Standards are meaningless with a single implementation.

And this is a bad thing… exactly why?

Standards only raison d'etre is interoperability (well, some companies think it's PR - see OOXML, but let's ignore these aberrations for now). If you have just one implementation then interoperability is achieved automatically. In fact most languages achive interoperability this way: perl, tcl, python… they all have one "canonical" implementation which defines what the language is. Why is it such a bad thing to have for HTML or JavaScript?

Opera moves to WebKit and V8

Posted Feb 17, 2013 18:53 UTC (Sun) by viro (subscriber, #7872) [Link]

One name: srb. The situation when language is defined by "how does this one interpretation work" can suck _very_ badly.

It boils down to this: unless the damn thing includes strong AI, you need interoperability of sorts, at least with the mental models in the heads of programmers writing in that language. Learning a language means building such a mental implementation, just to be able to reason about the expected program behaviour. Without that people are reduced to cargo-culting their way through every problem and that's *not* a way to write well.

sh(1) sucked well before there had been other implementations (not that they had helped when they appeared) and in large part it had been caused by lack of predictability...

Opera moves to WebKit and V8

Posted Feb 17, 2013 19:23 UTC (Sun) by pboddie (guest, #50784) [Link]

Indeed, singular implementations of supposed standards (or mere descriptions of how something is supposed to work) can really drift away from the documentation to the point that those implementations actively conflict with the documentation (or folklore) of what is supposed to be going on under the cover.

It also doesn't help that in some projects, comments and documentation strings are seen as superfluous fluff, meaning that one has to get into the exact mindset of the developers to first of all discover what they were trying to do, and only then to figure out what they meant to do.

Standards can be fairly awful things that are mostly exercises of formalising various vendor implementations, and I perceive Opera Software to be yet another vendor in this respect, even though the various Web standards involved have been fairly comprehensive and coherent. But they do serve a genuine purpose.

Opera moves to WebKit and V8

Posted Feb 17, 2013 22:02 UTC (Sun) by anselm (subscriber, #2796) [Link]

Having just one »canonical« implementation of a programming language doesn't imply interoperability across all platforms where that implementation runs. There are lots of things that can go wrong even so unless whoever maintains that implementation is very careful indeed. The case in point would be Java, whose tag-line, famously, is »write once, debug everywhere«.

In general, it is very useful to have a notion of what programs in a language mean which is independent of a particular implementation of that language – even if there is only one implementation. Otherwise it is impossible to distinguish actual intentional properties of the language from quirks of the (albeit »canonical«) implementation.

Opera moves to WebKit and V8

Posted Feb 17, 2013 22:56 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

>The case in point would be Java, whose tag-line, famously, is »write once, debug everywhere«.
Yeah, "a witty saying might allow your name to live forever" (c) anonymous.

But in reality Java works pretty fine across all supported platforms. People routinely use Windows to develop and debug Java software that is later deployed on Linux (or earlier on Solaris).

Opera moves to WebKit and V8

Posted Feb 17, 2013 23:50 UTC (Sun) by anselm (subscriber, #2796) [Link]

But in reality Java works pretty fine across all supported platforms.

Yep. They have had 20 years or so to get their act together, after all.

The fun observation when Java was new was that Java basically claimed to do, as a big innovation, what many other languages (including Tcl, Perl, and Python) were already doing as a matter of course – while Java failed abysmally. The »everywhere« in »run everywhere« essentially meant »Windows and Solaris«, and that was only if you knew what you were doing.

Java got to where it ended up because Sun spent millions in the 1990s marketing it to suits; based purely on its technical merits it would have sunk like a lead balloon.

Opera moves to WebKit and V8

Posted Feb 18, 2013 3:13 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

Come on. I realize that it's popular now to bash Java, but remember 90-s.

There was NO fast cross-platform language in 95-97. Python was still very young, Perl was not fast (and, well, Perl), C++ was not nearly cross-platform (for GUI, in particular).

Java provided a way to create programs that run without large changes pretty much on all major platforms (even classic Mac OS).

Opera moves to WebKit and V8

Posted Feb 18, 2013 7:51 UTC (Mon) by anselm (subscriber, #2796) [Link]

Come on. I realize that it's popular now to bash Java, but remember 90-s.

Java was well worth bashing even then. As I said, it became popular only because Sun was flogging it to the suits. Eventually it had had so much money poured into it that it had to become a half-way usable language despite itself, but at least for the first five years of its existence it really, really sucked. Few technical people wanted anything to do with it if they could help it at all – the big use case it was being touted for (browser applets) never really got off the ground, and for most everything else, many folks thought of Java as a kind of C++ with non-removable training wheels and abysmal performance.

There was NO fast cross-platform language in 95-97.

That didn't really matter with respect to Java because Java at the time was by no means »fast«, either. In fact, compared to other interpreted languages of the time it was pretty slow. Just-in-time compilation for Java – which was the technique that eventually did make a difference – became popular only later.

Java provided a way to create programs that run without large changes pretty much on all major platforms (even classic Mac OS).

So? Other popular languages did, too.

Opera moves to WebKit and V8

Posted Feb 18, 2013 14:51 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

>Few technical people wanted anything to do with it if they could help it at all – the big use case it was being touted for (browser applets) never really got off the ground, and for most everything else, many folks thought of Java as a kind of C++ with non-removable training wheels and abysmal performance.
You're projecting.

A lot of technical people were thrilled with Java, because it FINALLY allowed to write large programs without spending hours compiling stuff or waiting for Perl interpreter to muddle through the code.

Java has never become successful on the client side, but on server-side it was an instant hit. A great explosion of OpenSource Java projects in 90-s attests to that.

> So? Other popular languages did, too.
Which ones (with cross-platform GUI frameworks)?

I know only of Tcl/Tk which requires, shall we say, quite a bit of getting used to.

Opera moves to WebKit and V8

Posted Feb 18, 2013 15:42 UTC (Mon) by anselm (subscriber, #2796) [Link]

A lot of technical people were thrilled with Java, because it FINALLY allowed to write large programs without spending hours compiling stuff or waiting for Perl interpreter to muddle through the code.

Yes, because Java in the 1990s gave you the joint benefit of both spending hours compiling stuff and waiting for the JVM to muddle through the code.

Now you're projecting.

I know only of Tcl/Tk which requires, shall we say, quite a bit of getting used to.

Tcl/Tk is a lot better than its reputation. It is safe to say that if Sun had spent all that money they spent pushing Java on pushing Tcl/Tk instead (which would have been quite feasible given that Java was a SunLabs project at the time) the world would be a different (and arguably better) place. Remember that in the 1990s Tcl/Tk was a language that actually had serious commercial users all over the place, while Java was a language desperately in search of something – anything, really – it could make itself useful for. Set-top boxes, web applets, you name it.

It is probably telling that Tcl/Tk, while never having had much of a marketing force behind it, is still popular in many places – and not unimportant ones, either.

Opera moves to WebKit and V8

Posted Feb 18, 2013 16:50 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

> Yes, because Java in the 1990s gave you the joint benefit of both spending hours compiling stuff and waiting for the JVM to muddle through the code.
Java compilation was fast enough not to care about it. And JVM has had a JIT compiler since 96.

> Tcl/Tk is a lot better than its reputation.
Blergh. I remember hours of debugging trying to find where it concatenated strings incorrectly. Thanks, but no thanks.

Now, Smalltalk (and Strongtalk) might have been more widespread. That might have been more interesting.

> It is probably telling that Tcl/Tk, while never having had much of a marketing force behind it, is still popular in many places – and not unimportant ones, either.
Thankfully, it's getting used less and less.

Opera moves to WebKit and V8

Posted Feb 18, 2013 17:19 UTC (Mon) by anselm (subscriber, #2796) [Link]

And JVM has had a JIT compiler since 96.

For the record, HotSpot came out in 1999 and became the default in Java 1.3, which was released in 2000. The HotSpot JVM was also not a particularly portable program, so the performance benefits of JIT were by no means universal to all Java platforms. (Which was fine by Sun because it meant that for reasonable server-side performance you pretty much had to be running Solaris.)

Opera moves to WebKit and V8

Posted Feb 18, 2013 17:28 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

For the record, JIT compiler (not a HotSpot compiler) become available in JVM 1.1 in 96. This JVM actually had a pluggable JIT interface, so there was a couple of custom JITs.

The first HotSpot JIT was present in JRE 1.2 (that's why it was called 'Java 2') later in 97.

Opera moves to WebKit and V8

Posted Feb 18, 2013 21:23 UTC (Mon) by pboddie (guest, #50784) [Link]

I suppose that adding a JIT that finally delivered on the research done previously on Self at Sun Microsystems probably did merit a major version bump, but Sun (and coincidentally Oracle) were masters at a bit of version bumping to warm over products getting a lukewarm reception.

For the record, I stumbled upon Java, Tcl/Tk, Python and a bunch of other languages at the same time, in around 1995. Java was the only one that needed me to get a disk quota upgrade and an account on a flaky Solaris server (whereas the others all ran on SunOS and a multitude of other platforms). I recall a colleague during my summer job showing me Java for the first time: Duke the Java mascot waving in an applet; premium UltraSPARC workstation required.

To be fair, I did get some mileage out of Java for a university project, doing a bit of graphics in AWT instead of using Xlib like everybody else, but a few months later I would saved myself the hassle of the dubious AWT implementation and used something like Python and Tk instead.

Sorry, how did we get onto this again?

Opera moves to WebKit and V8

Posted Feb 21, 2013 4:40 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

> Which ones (with cross-platform GUI frameworks)?

Qt was started in 1991. I don't know when QtGui popped up.

Opera moves to WebKit and V8

Posted Feb 24, 2013 11:51 UTC (Sun) by Jandar (subscriber, #85683) [Link]

> But in reality Java works pretty fine across all supported platforms.

Only if you restrict the jre to a specified version and test the programm on all used platforms.

Up to now this "runs everywhere" is total bogus. Everytime a new jre version is rolled out by a customer reports about changed behaviour starts rolling in.

Opera moves to WebKit and V8

Posted Feb 19, 2013 3:47 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link]

If you have just one implementation then interoperability is achieved automatically.

Not really. Fred Brooks goes into some detail of the drawbacks of implementation as specification in The Mythical Man-Month. The problem is that you never have just one implementation. Every version is a subtly different implementation from the previous version. If you define the implementation to be the specification, there are no such things as bugs. Every quirk of your implementation is part of the API, and any attempt to fix what you see as bugs may turn out to be eliminating a feature that somebody has come to depend on. Even if you have just one implementation, it can still be useful to have a formal specification to prevent yourself from getting stuck with that kind of problem.

effect on open web

Posted Feb 17, 2013 20:53 UTC (Sun) by pjm (subscriber, #2080) [Link]

"Implement the standard" only works to the extent that there is a written specification of the behaviour. In practice, CSS specs already have a problem with insufficient reporting of bugs in the specs, perhaps in part due to insufficient resources for fixing reported bugs. One fewer rendering engine means both fewer bug reports, and (I suppose) fewer person-hours available for fixing bugs.

As for "What's wrong with having only one implementation", the problem is that not all uses of HTML/CSS are for web browsing: you want your word processor to be able to read & write HTML/CSS, and publishers want to use HTML/CSS for writing books, but there are fundamental conflicts between the needs of an interactive web browser and the needs of printing. (One needs to be fast and support interactive technologies, the other needs to look good: well-chosen page breaks, line breaks, float placements, table column widths etc.)

Opera moves to WebKit and V8

Posted Feb 16, 2013 1:00 UTC (Sat) by Company (guest, #57006) [Link]

> Except this is an engine that can be fixed by anyone when it's broken.
Just like XFree86!
Or gcc's failure to be a library!

Fixing a monoculture is bad, in particular when that monoculture defines an interface. It usually takes forks (Xorg) or reimplementations from scratch (LLVM) to get things moving again. Both of these usually take a while before they happen and they take a huge amount of effort. No matter of the original was open or closed.

Opera moves to WebKit and V8

Posted Feb 16, 2013 12:14 UTC (Sat) by marduk (subscriber, #3831) [Link]

> Except this is an engine that can be fixed by anyone when it's broken.

Yeah, except when it comes to web engines it seems that they go by their own law:

Given enough eyeballs, all bugs are features.

These browsers become so non-compliant/forgiving of errors because more and more users ( popular web sites) depend on them.

Opera moves to WebKit and V8

Posted Feb 16, 2013 19:50 UTC (Sat) by robert_s (subscriber, #42402) [Link]

>Except this is an engine that can be fixed by anyone when it's broken

If that were true then there wouldn't be any odd quirks of behavior specific to WebKit. And there are plenty.

It's not so much about going by the core specifications - browsers have become better at that - it's about all the tiny pieces of behavior around the edge that aren't in specifications. And with a monoculture of browser engines it's far more likely that a piece of unspecified behavior *becomes* a de-facto standard because "most browsers" "do it like that".

And that's where you start entering dangerous territory, standards-wise.

Opera moves to WebKit and V8

Posted Feb 18, 2013 16:36 UTC (Mon) by maderik (guest, #28840) [Link]

This is silly -- s/Webkit/Linux kernel/ -- anyone can fix bugs yet there are also plenty of quirks, some of which get standardized into features. Does that mean the Linux kernel as the most popular *nix implementation is a bad thing?

Opera moves to WebKit and V8

Posted Feb 19, 2013 18:30 UTC (Tue) by sorpigal (subscriber, #36106) [Link]

As long as it's not the only *nix implementation of note there's no problem.

I can graph Linux adoption and project an inaccurate date in the future when there will be no notable other *nix implementations. Whether everything will continue to be as okay as it is now is debatable; I'd say that we've already reached "only one notable implementation" land when it comes to certain categories of use. It will get worse and I just hope that nothing really bad happens as a result.

Opera moves to WebKit and V8

Posted Feb 16, 2013 21:52 UTC (Sat) by elanthis (guest, #6227) [Link]

> I'd agree that the software monoculture aspect of it is less attractive - webkit is going to have to be very secure!

WebKit is already the de facto standard mobile browser. Opera switching is affecting only a tiny fraction of the market. WebKit already needed to be super secure to keep safe 80+% of the mobile market. Safari has 60% of the market and Android Browser has 25%. Third place is held by the Java browsers on feature phones.

Opera moving over only makes sense as a business, and barely affects the mobile browser space; they are tiny and wasting a lot of resources just trying to stay compatible with WebKit browsers as is.

Opera moves to WebKit and V8

Posted Feb 18, 2013 23:51 UTC (Mon) by Drongo (guest, #60513) [Link]

I agree. It is easy for us diehard Opera fans (user since 1997) to overlook the fact that we are among -- what? -- 1% of brower users. I value Opera for its features, not its rendering engine. Whenever I use Firefox or Chrome it is not as if I end up thinking "Gee, these pages sure look odd." More common, I find certain javascript scripts not working in Opera, necessitating (if I care) opening the page in an alternative.

My concern, justified or not, is just how isolated the MVC elements are from each other, and thus whether the rendering engine conversion will blow back to the interface in ways I regret. We will soon see.

Webkit not well taken care of

Posted Feb 18, 2013 11:03 UTC (Mon) by job (guest, #670) [Link]

"Can be fixed by anyone when it's broken", sure, but do they?

According to the JQuery developers, they have more bug workarounds in their codebase for Webkit than for any other browser(!). If anybody knows these things it's probably them.

That leaves me skeptical about how well Webkit is taken care of. Especially since Google and Apple keep piling new features on it. That can never be be a suitable reference implementation of the HTML standard, which some people purports it to be.

One less rendering engine is not something to celebrate.

What to do about it

Posted Feb 26, 2013 1:19 UTC (Tue) by pjm (subscriber, #2080) [Link]

It's one thing to worry about this development, but we also need to think about what we can actually do about it.

Regarding bugginess: Among the comments in that jQuery-related page is a WebKit developer asking whether these workarounds are for bugs still present in current WebKit, or whether they're just for old versions of WebKit. Another couple of comments ask whether the jQuery developers made any attempt to have the bugs fixed (even if only by filing bug reports). So far there's no reply to any of these queries, so it's not clear to me that current WebKit (as adopted by Opera) is more buggy than other browsers.

As noted both here and in the comments to the referenced blog post, many (or even most) differences between WebKit and Gecko are where the specs aren't clear what the right behaviour is. Opera switching to WebKit will surely only make this problem worse.

Opera adopting WebKit says that the CSS specs (and other, not-yet-specified, expected browser behaviour) are too onerous not just to implement to begin with, but even just to keep up with when you already have an implementation.

These two observations do not bode well for the future of an open web, given that not everyone's HTML/CSS-related needs can be met by a single implementation.

If we want an Open Web, then it has occurred to several people (independently) that we need a different approach to providing advanced functionality, making more use of Javascript polyfills and providing useful basic building blocks. Tab Atkins, who works on both WebKit and spec development, is one person thinking along these lines.

LWN readers might compare HTML/CSS interoperability with (La)TeX interoperability. In TeX, the usual way of adding functionality is with a package file. I don't remember having to upgrade the latex binary to read a document, I've only needed to install packages. For web pages, "installing packages" is even easier, because the browser does it automatically from the URIs in the referring document. With proper versioning, implementers could even implement native versions of commonly-used libraries that prove to be performance costly.

The limiting factor for a polyfill approach is what hooks CSS provides for changing functionality, and what building blocks are available. A lot of polyfills today work well enough in common cases, but fail once there's a user stylesheet or the document gets viewed in a medium other than screen, or the content uses a layout feature beyond the basics.

The challenge, then, is for each new CSS feature to think how it could be implemented with a Javascript polyfill, and what changes to CSS (hooks and building blocks) would make a polyfill implementation more practical; and to get these generally useful extensibility changes implemented instead of once-off features.

Comments, suggestions?


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds