Opera joins Chrome & Safari in using Webkit for Web-browsing

This is good news. Will no doubt improve the Opera browser share. Heck I'll even give it a try when it's out.
 
Wow, this is incredibly interesting news. As a web developer, though, it's also very welcome news - one less browser I'll have to test on! :D In more serious terms, having more hands on the same code must be good for WebKit as a whole - more developers hopefully means more bugs squashed, and possibly better standards compliance (and fun new toys :D)
 
Now hopefully Firefox and Internet Explorer will do the same. :)

Definitely don't want this.

Gecko is slow no doubt, but has the only canvas implementation that can actually run a couple of my creations without looking awful. Presto comes a close second in this regard.

And IE has always had unprecedented speed at traditional 'DHTML' (moving absolute elements around by mouse movements or otherwise), even before the hardware acceleration fad. Way ahead of Chrome etc. still in real applications of this
 
I'm not sure if it is Gecko that is slow. Someone remembers K-Meleon? It was pretty fast with a then-current Gecko built while Firefox was way slower. I tend to think Gecko is the best engine out there, but Firefox sucks more and more... Sadly.
 
There can be 5,000 browsers for all I care... I just want them to all render the same (or at least close) when I design web stuff. :)

Actually, I'd be fine with just Firefox adopting IE's rendering engine even. Firefox is like the new IE... It seems like all the browser-specific stuff I have to do now is because stuff works fine in all browsers except Firefox. Kind of sad really what happened to Firefox.
 
Kind of sad really what happened to Firefox.

Indeed, and the thing I find frustrating is that with all the effort I went to convincing my non-technical family members to move from IE to Firefox a few years back, do you think I can get them to move from Firefox to Chrome or something else now? :rolleyes:
 
You are seeing black helicopters. What problems there are with Firefox?
FYI, Chrome's linear-gradient function isn't as stable as Firefox'. At least I encountered issues in this regard with Chrome.
 
What problems there are with Firefox?
Let's see here... recent issues I've run into.

Rendering engine is slower (noticeably jumpy when resizing window).

Doesn't support zoom CSS property (all other major browsers support it). Pending issue for 5 1/2 years now. https://bugzilla.mozilla.org/show_bug.cgi?id=390936 Real world effect for me: Retina graphics are supported for all browsers on my site except Firefox.

Can't display SVG image unless it's embeded in HTML. Pending issue for 3 years now. https://bugzilla.mozilla.org/show_bug.cgi?id=544685

There are some other CSS attributes that are not supported, but I forget what they are off the top of my head, but I know I ran into them the other day.
 
You are seeing black helicopters. What problems there are with Firefox?
Spinning Wheel of Death on OS X when memory usage gets above 1.5 GB. And it is 1.5 GB when Firefox restores my tabs on startup. Well, that's kind of my only problem with Firefox.
 
Hopefully not. If there's only one engine out there, we have the same setting we had 10 years ago when MSIE had 90+% market share... I wouldn't like that.
I've heard this argument repeated a few times. Sorry... but it's completely incorrect and inaccurate.

IE is a single proprietary web browser, owned by one corporate entity. Webkit is an open-source project for a web rendering engine, overseen by a consortium, and also available for anyone to use or modify. It's effectively public property (and it's not a web browser)

Using webkit to power our browsers is absolutely no different to everyone using zlib as a standard compression library. A webkit-monoculture will only serve to evolve the web more rapidly, instead of pointless fragmentation across browsers and platforms.

Right now, having completely different engines with varying feature-sets and functionality is only holding us back and delaying progress.
 
Its great news.

Opera's engine has been falling behind for a while, its share is too small for web developers to care about adjusting websites to work with Opera, so using outdated engine can only result in users switching to different browsers. I used to love Opera interface when I was working on Windows, if it switches to WebKit engine, I'll probably use it as my main browser on laptop once again.
 
There's actually markets where Opera has 10-30% share.

Opera is a small, very small, company, so it's nice to see their resources better used to innovating their existing product, rather than trying to "catch up" to other browser.

It's still a big loss for the general state of rendering platforms though, with only Webkit, Trident and Gecko as serious contenders. If this trend continues, standards will become largely irrelevant (not a particularly great thing). Hopefully, they'll open source Presto, rather than let it bitrot in some SCM somewhere, but there's probably too many problematic dependencies to make that worthwhile.
 
I've heard this argument repeated a few times. Sorry... but it's completely incorrect and inaccurate.

IE is a single proprietary web browser, owned by one corporate entity. Webkit is an open-source project for a web rendering engine, overseen by a consortium, and also available for anyone to use or modify. It's effectively public property (and it's not a web browser)

Using webkit to power our browsers is absolutely no different to everyone using zlib as a standard compression library. A webkit-monoculture will only serve to evolve the web more rapidly, instead of pointless fragmentation across browsers and platforms.

Right now, having completely different engines with varying feature-sets and functionality is only holding us back and delaying progress.

There's alternatives to zlib (though they may not all achieve as good of a compression ratio), so that analogy doesn't quite hold up.

If everyone shares the same underlying implementation (this webkit-monoculture you speak of), then standards are meaningless: The standards body can say whatever they want, but in practice all that will really matter is what actually runs on the single implementation.

Does that matter? Perhaps not in the short term. But the only reason Webkit could achieve what it has was that there was a strong standard. IE's dominance was broken and multiple browsers existed, and Webkit could render the same pages by supporting the same standard. It was hard to break IE's dominance, and if Webkit becomes that new single implementation, it will be similarly hard to make it possible for a new rendering platform (read browser) to emerge.

If someone wants a better browser than the Webkit offerings, especially if developed in another language, that will only be possible if there are standards for web content; otherwise, they'll be chasing after Webkit specific bugs and features. Bug partity is extremely difficult to achieve, and will become harder as the web includes more and more content -- making it that much harder to break Webkit dominance.
 
There's alternatives to zlib, so that analogy doesn't quite hold up.
Perhaps not the best analogy, but you can see where I'm coming from. I was more just trying to illustrate the difference between browser and engine, which I'm sure you've noticed some people have trouble with.

... If this trend continues, standards will become largely irrelevant (not a particularly great thing).

Webkit would effectively become the engine and standards body which everyone adhered to. IMO, this makes far more sense than the current mess we're stuck with. The standards bodies are ineffective and molasses slow at getting anything done. The distinct differences and vendor-specific features between modern rendering engines demonstrates how irrelevant these organisations really are.

There's room in our world for plenty of different browsers and interpretations for what the browsing experience should be, but using a different engine should not be optional for anyone expecting mass acceptance.

If someone wants a better browser than the Webkit offerings, especially if developed in another language, that will only be possible if there are standards for web content; otherwise, they'll be chasing after Webkit specific bugs and features.
They'll be stuck hacking on Webkit if they want anyone to really use their product. The world doesn't need another Presto or Gecko. If their changes are worthwhile, it would become integrated within webkit or used for subsequent versions.

I'm still not seeing how a single, dominant rendering engine (run by an open-source consortium) could ever be a bad thing. :)
 
Webkit would effectively become the engine and standards body which everyone adhered to. IMO, this makes far more sense than the current mess we're stuck with. The standards bodies are ineffective and molasses slow at getting anything done. The distinct differences and vendor-specific features between modern rendering engines demonstrates how irrelevant these organisations really are.

There's room in our world for plenty of different browsers and interpretations for what the browsing experience should be, but using a different engine should not be optional for anyone expecting mass acceptance.


They'll be stuck hacking on Webkit if they want anyone to really use their product. The world doesn't need another Presto or Gecko. If their changes are worthwhile, it would become integrated within webkit or used for subsequent versions.

In a mono-culture you have no predators thus no evolution.

There's a big difference between a standard and an implementation. If you only have one implementation (e.g. WebKit, or more specifically, WebCore), developers will undoubtedly start depending on certain quirks of that implementation. You reach a point where these quirks can't be changed, otherwise half the web will stop working. Having multiple rendering engines means these quirks are more likely to be fixed, and not relied upon.

Now, everyone switching to WebKit probably wouldn't matter much in the short term, but that seems awfully short-sighted. We don't need a single rendering engine, but new standards bodies. I'd be perfectly okay with WHATWG stepping into this role. What you're describing is "innovation" in its weakest form. It's basically incremental improvement, rather than real innovation, and I can't help but think that's the wrong approach.

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 within open source projects too. Unorthodox ideas will often be brutally crushed, even if the benefits they provide are immense. It's impossible to say if WebKit will continue in a direction most agree with in 5-10 years. Sure, one could always fork if that happens, but then how do you get that into the hands of your users? Needless to say, it isn't a compelling argument for a single rendering engine either.

There's other reasons to be concerned with WebKit becoming the defacto implementation, as well, that have more to do with its architecture, and not simply the rendering engine. For example, if you want parallelism, WebKit is a non-starter (too entangled, too much code making too many assumptions). Also, nothing like Mozilla's Servo project could happen.

I'm still not seeing how a single, dominant rendering engine (run by an open-source consortium) could ever be a bad thing. :)

I'll agree that if there is to be a rendering engine mono-culture, it might as well be open source, but that in itself guarantees nothing. Apple still has quite a bit of control over the project, and it's mostly developed by Apple, Google and RIM (full disclaimer: I work for one of those companies). There's nothing preventing them from getting a bit heavy-handed just because it's open source.
 
Top Bottom