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?
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.
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.
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.
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.
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?