From testing out my demos in Opera Next over the past few months, I've been really impressed with the quality of their JS runtime and the UI. Unfortunately, their hardware-accelerated canvas support doesn't really keep up and their WebGL is outright broken - it looks like they went so far as to disable both by default in 12, a disappointment to be sure - and they still have serious issues with HTML5 audio (to the point of causing hangs/crashes).
Given that my only real exposure to Opera is from trying to ensure my stuff runs well in it, it's easy to get the impression that everything about Opera is broken. I wish they had a public bug tracker so it was easier to tell which things are known issues, which things have known workarounds, and which things I should file bugs about.
In particular, the audio issues are a point of frustration: At present, if you test the latest builds of Firefox, Chrome, Safari, Opera and Internet Explorer, Firefox is the only one that actually has low-latency, functioning support for <audio> that doesn't crash or hang. It's ridiculous. Chrome at least has a custom webkit-only API you can use to get working audio, but the rest of the browsers are just flat out broken. And in each browser's case, they've had multiple versions to fix basic issues (limits on how many sounds you can load in a single page context; broken events and APIs; absurdly long playback delays, etc). Oh, and Firefox still doesn't support the loop attribute. :|
> I wish they had a public bug tracker so it was easier to tell which things are known issues, which things have known workarounds, and which things I should file bugs about.
While it's not possible to track the status of a bug, you can submit them:
I've submitted quite a few over the years. I've even gotten emails back asking for more information. For example, I submitted a report about an issue with their hardware acceleration detecting the wrong GPU in a multi-GPU system, which they fixed.
This is just an indicator that we need a proper native development environment. Devs who embrace new web technologies like WebGL, <audio> or <video> forget that those are just Javascript bindings to the technologies developed in C/C++. Can we please have native code instead, so developer controls the underlying system without having to rely on the wits of browser makers? Google Native Client is a step in the right direction.
> This is just an indicator that we need a proper native development environment. Devs who embrace new web technologies like WebGL, <audio> or <video> forget that those are just Javascript bindings to the technologies developed in C/C++.
That is technically true, but what is the point? The bindings can make things better, or they can make things worse. WebGL, for example, covers over a lot of issues with OpenGL (security and convenience), making the web version very nice to use.
> Can we please have native code instead, so developer controls the underlying system without having to rely on the wits of browser makers? Google Native Client is a step in the right direction.
Native code is by definition non-portable.
NaCl in a partial attempt at portability adds bindings of its own to native APIs. Ask people developing for it, like any environment it has bugs and issues.
> That is technically true, but what is the point? The bindings can make things better, or they can make things worse. WebGL, for example, covers over a lot of issues with OpenGL (security and convenience), making the web version very nice to use.
Last time I tried WebGL version of Quake3 on my machine which had the hi-end AMD graphics card at that time, it ran at less than 100FPS. For a game that's 10 years old that is a very poor result. The reason why I said bindings is because I want a language powerful enough to implement any technology I want in that language.
> There is no simple solution here.
Of course it's not simple. It doesn't mean it's not possible. Microsoft's WinRT is another example of coming closer to the native code apps.
> Last time I tried WebGL version of Quake3 on my machine which had the hi-end AMD graphics card at that time, it ran at less than 100FPS. For a game that's 10 years old that is a very poor result.
The Quake II port was extremely unoptimized in how it was performed. It's not a good benchmark of anything.
> Microsoft's WinRT is another example of coming closer to the native code apps.
What about just actual Android C++ apps, as an example of native code apps..?
What, wasn't the whole point of all web technologies to pile abstraction layers on top of abstraction layers so you never have to think about pointers ever again? :)
Native platforms and architectures were replaced by browser platforms, trading power and control for deployment headaches. And now you want to write for multiple browsers, multiple OSes and multiple architectures all at the same time while still battling heaps of restrictions any decent OS/antivirus would impose on binary blobs that can be run by a browser directly?
(disclaimer: I'm obviously biased towards native development :))
Given that my only real exposure to Opera is from trying to ensure my stuff runs well in it, it's easy to get the impression that everything about Opera is broken. I wish they had a public bug tracker so it was easier to tell which things are known issues, which things have known workarounds, and which things I should file bugs about.
In particular, the audio issues are a point of frustration: At present, if you test the latest builds of Firefox, Chrome, Safari, Opera and Internet Explorer, Firefox is the only one that actually has low-latency, functioning support for <audio> that doesn't crash or hang. It's ridiculous. Chrome at least has a custom webkit-only API you can use to get working audio, but the rest of the browsers are just flat out broken. And in each browser's case, they've had multiple versions to fix basic issues (limits on how many sounds you can load in a single page context; broken events and APIs; absurdly long playback delays, etc). Oh, and Firefox still doesn't support the loop attribute. :|