[NinjaWarrior]

If you don't like monocultures, you shouldn't have hated plug-ins. And Firefox OS should allow users to install browsers other than Firefox.

I'm very sad that not only Flash 11 but also Silverlight and Unity Web Player are all doomed by the enthusiasm of the "open" standards. Therefore, I feel that current Mozilla is full of hypocrisy.

And Mozilla, you must implement the Web Audio API ASAP. Without this, all interactive "HTML5" demos with audio will be developed only for WebKit browsers. "We innovate early, often"? I don't think so.

[azakai]

> If you don't like monocultures, you shouldn't have hated plug-ins.

Plugins are each a monoculture. Flash, Silverlight, etc. - these are not multiple implementations of the same standard (like WebKit and Gecko are). Plugins are each a single implementation of non-standard.

> And Firefox OS should allow users to install browsers other than Firefox.

Firefox OS is really just the Firefox browser and minimal stuff around it to make it run. I'm not sure I see the point of allowing installation of another OS from it (replacing firefox there means replacing basically everything).

> I'm very sad that not only Flash 11 but also Silverlight and Unity Web Player are all doomed by the enthusiasm of the "open" standards.

None of those are doomed, except for Silverlight which Microsoft decided to discontinue. And the thing that is dooming Flash is not open standards, but iOS which did not allow it to run, which eventually made Flash irrelevant on mobile.

> And Mozilla, you must implement the Web Audio API ASAP.

Of course, work on this is well underway. You can follow here,

https://bugzilla.mozilla.org/show_bug.cgi?id=779297

[chadaustin]

You've given some specific plugins which are monocultures but plugins in general democratize the web by allowing things like Unity3D to flourish. Without plugins, web developers are limited to a blessed set of capabilities offered by the browsers, with no ability to extend the set of capabilities. Let's consider video codecs: without plugins or some way to run near-native code, innovation on the codec front must happen in the browser itself.

So I think there's truth to NinjaWarrior's argument that plugins protect from monoculture.

[azakai]

That's a different form of diversity, but yes, plugins do give more options. And they are helped by running in browsers.

But they are security risks and cause lots of problems for browsers, as well as the monoculture issue (I can't run Flash on linux anymore because they decided to deprecate the flash linux NPAPI plugin).

So I don't think browsers should promote them. But native apps are still fine for them - Unity is flourishing especially on mobile, far more than on desktop browsers; Unity ships native apps on mobile.

[comex]

Arguably, if asm.js (and perhaps WebCL) takes off, you'll be able to implement custom codecs at near-native speed without any need for a download or the risk of plugins...

[padenot]

The Web Audio spec is more a user manual than a spec, to be fair. We are implementing the API at the moment, but the spec is so unclear that it is impossible to implement it properly. We have a couple things done and working, though.

And about "We innovate early, often", keep in mind that we had a counter-proposal to the Web Audio API, that we implemented. The W3C has chosen Google's instead of ours, and I believe that the fact we are late to implement this particular spec is quite normal.

[chipsy]

I happen to be working on my own implementation of Web Audio in Haxe(for easy portability into Flash or outside the browser). I'm still at an early stage and admittedly am heavily guided by the Webkit implementation - while working on parameter changes I had to stop and take notes on their code to see exactly what was going on. What parts of the spec do you find most difficult?

[graue]

So why did the W3C choose Google's audio proposal? Was there some kind of political wrangling going on there or were there purely technical reasons? I've wondered about that for a while.

[doublec]

The Google proposal was more full featured than the Mozilla Audio Data API. It provided more functionality baked in vs having to implement it in JS. This was considered important for mobile devices.

Mozilla countered with another proposal, the Stream Processing API (https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProc...) but this was a bit too late.

Another advantage of the Google proposal was they had a spec and implementation from the start. The Mozilla proposal had a wiki page write up and an implementation and I don't think there was as much effort put into promoting it as Google did into theirs.

[greggman]

Because it was the better API? Game devs all over the net have praised the Web Audio API

The Mozilla proposal required audio processing in JavaScript which in some ideal world is a great idea but in the real world where you want audio running on Intel ATOM and mobile processors and still have time to run other code is the not such a good idea.

[air]

Monoculture means here that everyone is running the same implementation. Flash 11, Silverlight and Unity Web Player are all examples of that.

Allowing opaque plugins encourages weakly specified technologies with just one defacto implementation and leads to monocultures.

[loudmax]

If Flash, Silverlight, and Unity Web Player were based on open standards and they each had as many competing implementations as there are web browsers, then they might be a real way forward. They're each useful in their own way, but their application is limited because they're each locked to a proprietary implementation.

Granted, Silverlight was "open" in the sense that it had defined specs, but the specs were clearly written by a single company, and competing implementations would be at a significant disadvantage.

[camus]

Adobe/Macromedia tried to take a step into standardisation for Flash ( ES4 ) it failed ,because some were pushing crappy alternatives ( Microsoft and Silverlight ) and Mozilla had cold feet ( tamarin ... ). Funny how some now try to shove you typescript when we could have had a better language back then. It doesnt mean that we will still be writing some javascript in 10 years ,hopefully we wont.

[kevingadd]

The Web Audio API is Chrome-only (or I guess it shipped on iOS 6 now? I still can't use it in Safari on my desktop PC) because Google wanted it that way. The API is incredibly poorly specified and poorly designed.

HTML5 games have been able to use <audio> to play sounds since before the Web Audio API existed, but Google never bothered to actually make it work right in Chrome. They were too busy coming up with their own thing.

[greggman]

Game devs all over the net have praised the Web Audio API. Abusing the audio tag was never the correct solution for games. The audio tag was designed for streaming long files, never for sound effects. Just because people were able to abuse it into game use doesn't suggest that was a good solution.

[kevingadd]

There's nothing fundamentally bad about 'new Audio("effect.wav")' and it performs stunningly well in both Firefox and IE and has for a long time. The one real 'downside' - prebuffering - is absolutely trivial to compensate for and the code to do it in JS is not any larger than the necessary scaffolding to make basic use of Web Audio.

Chrome was always the loser here; I won't speculate as to the reasons why, only state that for multiple versions, playing simple sound effects with Audio instances had severe latency, audio quality issues, and even crashes. Why wouldn't devs praise the Web Audio API if the only alternative was broken? I certainly was happy when I finally managed to get my HTML5 games to play audio in Chrome without crashing, but that doesn't mean the Web Audio API is well-designed or that it was a good idea for me to have to write Chrome-specific code just to play sound effects.

I'll acknowledge that Web Audio's design probably delivers better runtime performance in scenarios where you're playing dozens or hundreds of non-streaming sound effects, but I still question the motives of anyone who prioritized that over having basic support for audio working correctly.

EDIT: Because I forgot to mention this - I mean seriously, you put a method call in the Web Audio API that blocks the UI thread to synchronously decode audio? In 2012??? And didn't cover the documentation in 'don't use this' warnings?

[doublec]

The main point of the web audio api is for procedural generation of sounds rather than playing of pre-computed buffers or files. This is why "new Audio('effect.wav')" isn't a real alternative to it.

[chipsy]

More to the point: As soon as you want to mix audio levels, <audio> alone is completely insufficient. You need mix control in order to fade background music and loops. I consider this a basic need; the Mozilla API allows you to roll something yourself, but Web Audio is more clearly suited to the application.

[kevingadd]

Mozilla had procedural audio generation through <audio> with a simple, documented API back when Chrome couldn't even play non-procedural audio through <audio> properly.

http://phoboslab.org/log/2011/03/the-state-of-html5-audio

Procedural audio is also effectively a corner case compared to the vast majority case, which is playing static sounds.

[comex]

Simple, documented, and slower - you had to do everything in JavaScript. Web Audio API retains the ability to use JavaScript but provides a nice set of fast primitives.

[chadaustin]

The web audio API has sample-accurate scheduling which, in our games and this modern age of procedural audio, is critical.