Yep, if Google implements DRM, no one can stop it. The web is a platform for big software vendors after all, because no other player can virtually implement and maintain this enlarged platform and browser runtimes. Evil browser vendors will take over the role of evil plug-in vendors. Game over.
I predicted this catastrophe when everyone was attacking Flash.
And the web highly relies on the native ecosystem. Since we have freedom of the native development on PCs, a number of browsers have been created and improving. However in mobile devices, that ecosystem is totally broken. When you have trouble with browsers on restricted OSs (such as iOS and Firefox OS), you can't do anything! I feel something like free riding is happening. This is far from "open" movement.
The web platform can't exist without native platforms after all, since browsers are native applications.
Sure, the Unreal Engine 3 demo (Epic Citadel) had been already ported to Flash one year ago.
http://www.unrealengine.com/flash/
Since ActionScript VM is far slower than JavaScript, I'm afraid I have to say the Mozilla's demo does not prove the performance of asm.js at all.
I know there are improvements on the web platform each year but I wish people would be very very cautious to say "we've achieved nearly native performance!".
To begin with, I think it's difficult to run 3D games (including Flash and Unity) on browsers because of the asset loading (and AOT compilation) time. If people must wait for seconds and even minutes to start a game, we can't do business with it. As many web developers says, immediate page loading is must. I'm personally running Flash and HTML5 games and I observe 80% people leave just in a few seconds loading.
To solve this issue, game stores (PS3, Xbox 360, App Store, Google Play, Steam and many others) are using the "reserve download and play it later" model. After all, traditional install apps are not that bad architecture...
> Since ActionScript VM is far slower than JavaScript
This is actually incorrect. While ActionScript is actually far slower than Javascript, the VM is actually really good at running C code compiled to it. Providing about a 30x speed up over Actionscript.
> I would imagine that people would rarely write asm.js code, but instead they would generate it from statically typed languages (TypeScript, Dart, Haxe).
Current asm.js is just for C/C++. Those altJS languages can't make use of asm.js (Haxe->C++->LLVM->Emscripten->asm.js might be possible but I think it's meaningless).
asm.js is the answer of Mozilla for "the web standards can't handle AAA games" but I believe this is far from an ideal solution. And I agree with the worry of the poster that this ugly hack makes JavaScript more ugly, both on the specs and VMs.
To be honest, I trembled when I saw the Math.imul proposion to see how some people are so obsessed with JavaScript...
As others have mentioned, I don't see asm.js as being fundamentally tied to C/C++. Please correct me if I'm wrong. Memory management could be addressed in future versions, but even if it is not, there are still ways of getting the performance benefit of asm.js using altjs.
How about evaluating both (asm.js and PNaCl)? Looks like we are stuck in the "monoculture" you said you dislike. And this IS the reason I never love web standards. I don't like monocultures too.
I feel you are biased to preserve JavaScript because you are the creator of JavaScript. IMO, asm.js might beat Flash but has a clear dead-end to beat native. We all are in a local optimum trap, I think.
Do we all buy two significantly different and expensive cars to "evaluate" both? Most people can't afford to do any such thing.
Nor do we all buy the same make and model of car. That's implementation monoculture.
Monoculture of implementation (WebKit, which I pointed out is fragmented in practice) is not the same as a single vocabulary for each kind of language at the primitive level of the web standards layer cake.
Yes, we are stuck with the web platform bottoming out at a certain set of languages. That's not monoculture, rather: termination without too much redundancy in something not so complex that multiple browsers can hope to implement interoperably. The platform has to stand on certain primitives.
Remember XHTML2 vs. HTML5 back in 2005? It was going to be one or the other, even if browsers such as Firefox parsed both (but XHTML2 slowly and without incremental layout).
Maybe a Microsoft or Google could have "done both" well (but IE didn't, except by treating text/xhtml as error-corrected HTML!).
Without a single dominant browser vendor with enough cash and willpower to pull off more than the minimum set of semantically sufficient/complementary primitive languages, we were likely stuck with HTML/CSS/JS. SVG and MathML as HTML5 polyglot languages eventually were rationalized into the stack but still see too little use to be optimized well (and didn't Chrome turn off MathML recently?).
So the primitives have to be minimized against competing browsers' ability to implement them all interoperably. Browsers weren't going to do equally well at both the 2005-era XML languages (XHTML/SVG/XSLT) and the competing incremental plan (HTML5).
Arbitrary native code has been falling out as a part of the primitive layer for a while. Plugins such as Flash and Silverlight are in decline. You could say we had a plugin polyculture, but it was a security nightmare and also bad for users just in terms of updates and cross-browser/plugin UX consistency.
Pepper is an attempt to mediate plugins' access to OS and browser APIs, but too tied to chromium and too large for Google to standardize or for other vendors to swallow.
Consider also how Dart support (2nd VM, in particular GC barriers required for cross-VM-heap cycle collection) bounced off WebKit:
I'm mostly being descriptive so far, but let me prescribe:
Based on the hard multi-vendor specification and software engineering problems of doing well with a roughly minimized set of primitives that we have today, I do not believe it's "better" for anyone, especially for web developers, to over-extend the primitive set with things like NaCl and Pepper.
That applies even if one vendor could, e.g., add SIMD primitives quickly. That just fragments the picture for developers, and misdirects some energy that could be spent on adding SIMD to JS.
Same goes for Dart. It was so important to do as a "replacement" (see leaked Dash memo) and not wait for the standards bodies, but that started in 2010 (or earlier? I knew only for certain in spring 2010). It's 2013 now and Dart is not going cross browser. Things it wanted, e.g. bignums, could have been put in ES6 by now and implemented in leading JS engines.
I do not agree we are in a local optimum trap, not with Unreal 3 running within 2x of native unsafe code speed.
> Pepper is an attempt to mediate plugins' access to OS and browser APIs, but too tied to chromium and too large for Google to standardize or for other vendors to swallow.
You keep repeating this, but I don't see how you can be remotely serious about it.
Compared to JS, DOM, HTML, and CSS, Pepper is downright simple:
As an external developer, Pepper is something I could actually implement independently for a reasonable amount of money ($2M or less) in a reasonable amount of time (1 year or less), if I could rely on Google's existing (P)NaCL toolchain.
Would there be ambiguity? Yes. Google has already said they're willing to work with implementors to resolve any design or ambiguity issues.
On the other hand, I can't even imagine trying to write a full browser stack, including HTML(5), CSS, JS, et al, in one year for <= $2M? Not a chance.
Yet you call Pepper "too big" and "too complex". Meanwhile, the enormous weight of the mess that is the web stack creates a huge barrier to entry for anyone that might want to meaningfully contribute new ideas to the space.
We're already seeing interesting development occur around (the much more approachable) NaCL/Pepper:
> That just fragments the picture for developers, and misdirects some energy that could be spent on adding SIMD to JS.
This is rich coming from the CTO that's refused to collaborate with Google and instead is going off and "misdirecting" energy on alternative approaches.
> It's 2013 now and Dart is not going cross browser.
You know, you might have something to do with that? You're not exactly a powerless or disinterested third party in this dialog.
> As an external developer, Pepper is something I could actually implement independently for a reasonable amount of money ($2M or less) in a reasonable amount of time (1 year or less), if I could rely on Google's existing (P)NaCL toolchain.
But what's the point? You'd be stuck running some subset of "things that can run on the web", and the vast expanse of existing HTML content would be inaccessible. If you want to use NaCL/PNaCl for non-web applications nobody is stopping you. Writing a "browser" that doesn't implement HTML+JS is just nonsense.
> Would there be ambiguity? Yes. Google has already said they're willing to work with implementors to resolve any design or ambiguity issues.
We have no basis to know whether "attempt to specify all out the ambiguitity in the Pepper API, using the Chromium implementation as the standard" is harder than "implement the already-fairly-well-specified set of web technologies". We know web technologies can be implemented fairly interoperably, we have multiple interoperable implementations.
> You know, you might have something to do with that? You're not exactly a powerless or disinterested third party in this dialog.
And yet we're not the only game in town, either. None of the other browser manufacturers has expressed any interest, so it's not like we're alone on this. Why should we have to carry Google's banner? We've got enough stuff on our plate.
> But what's the point? You'd be stuck running some subset of "things that can run on the web", and the vast expanse of existing HTML content would be inaccessible. If you want to use NaCL/PNaCl for non-web applications nobody is stopping you. Writing a "browser" that doesn't implement HTML+JS is just nonsense.
Unless you consider the possibility that:
- Web apps versus web documents are two very different things
- You see this as a way by which we could escape the mess and massive size of the current web stack by standardizing on a much smaller base.
- Simplifying the core stack could open the door to new competition and innovation in the field.
Personally, I'd love to see WebKit and/or Gecko and all the browser chrome implemented on top of NaCL and/or asm.js, with only the most minimal runtime, such that you're not sitting in a privileged position of running native code while the rest of us are stuck in JS/HTML/CSS hell.
> We know web technologies can be implemented fairly interoperably, we have multiple interoperable implementations.
We also know that it's ridiculously expensive and difficult, in no small part due to the resistance to enforcing things like formal validation of HTML in the browser itself, creating a problem that's as much art as it is science.
> And yet we're not the only game in town, either. None of the other browser manufacturers has expressed any interest, so it's not like we're alone on this. Why should we have to carry Google's banner? We've got enough stuff on our plate.
Apple and Microsoft have no interest in undercutting their own vertically integrated platforms.
Only you and Google have an strong interest in furthering the web, and yet, you refuse to work with Google despite them expending considerable time and money on furthering the web, while sharing their work freely.
We at Mozilla don't have $2M and a year to spare, but you're wrong: we've assessed doing Pepper with high fidelity (not porting chromium and duplicating all the DOM and other browser API implementations). It's more like $10M and multiple elapsed years to get to Chrome parity, assuming Chrome doesn't keep evolving and put us on a treadmill.
But then, I'm just the guy managing engineering and worrying about budget at Mozilla. Maybe you have greater skills. Where do you work?
Anyway, Pepper is big, with over a thousand methods among all the interfaces that are "specified" only by C++ implementation code we cannot port. We have a DOM implementation already, for example. So you cannot escape the fact that Pepper is "and also", not "instead of" -- there's no savings, it is purely added-cost, and significant cost.
I'm almost the only guy who will say this on HN, but as far as I can tell, Microsoft and Apple are on the same page. Maciej Stachowiak of Apple has agreed on HN, for what it's worth:
Also, Epic is just the first big game publisher we are working with. Epic folks have confirmed again just this week that they won't do NaCl, there's no benefit to something CWS-only. But they are super-excited about cross-browser web-wide reach with asm.js and browser-hosted C++-sourced games. That's the PNaCl output format and runtime for Google to collaborate on.
> It's more like $10M and multiple elapsed years to get to Chrome parity, assuming Chrome doesn't keep evolving and put us on a treadmill.
So you don't believe Google's offers to work with external implementors?
> But then, I'm just the guy managing engineering and worrying about budget at Mozilla. Maybe you have greater skills. Where do you work?
I run a systems programming consulting shop. We focus on low-level OS/driver and VM projects, with application development making up the remainder of our work.
In theory, reliable estimates are my livelihood, and I have a very vested interest in the future of the platforms that we will have to develop for. I'm very concerned about the market requiring us to develop apps for a Mozilla platform.
> Microsoft and Apple are on the same page
What reason do they have to roll out something that helps Google undercut their vertical platform/app markets?
If NaCL is 'too good', then it threatens their business. Take that for what it means in terms of asm.js optimization adoption.
> Epic folks have confirmed again just this week that they won't do NaCl, there's no benefit to something CWS-only.
CWS-only and Chrome-only are again, oddly, something you have a hand in. Google pushed out beta PNaCL tools, and CWS-only has primarily been (rightfully) pending PNaCL.
> So you don't believe Google's offers to work with external implementors?
I wasn't born yesterday.
Microsoft is patching WebKit to support Pointer Events. Strange days, but even this "help" does not mean Pointer Events should win (or lose -- it's neutral in standards terms, at most helpful to show implementation feasibility and quality, if possible).
Why do you distrust Apple and Microsoft and ascribe bad motives to them based on their commercial interests, but fault Mozilla for not jumping on Google's Pepper treadmill like a good little-brother caricature? Google has commercial interests too, and they have spent >$1B a year on Chrome -- including advertising and bundling that directly targets Firefox users. (It's amazing we are still alive, and possibly even growing desktop share.)
You are surely right that some amount of competitive pressure will be required to get asm.js optimized in all engines. Ditto for WebGL in IE, and enabled in Safari. But cooperation between Chrome and Firefox is already happening on both asm.js and WebGL, so between these "coopetition" pincers, I bet we'll prevail.
Anyway, let's assume everyone has equally good motives, since Google is not any less commercial than Microsoft or Apple these days. Pepper is still too costly for others to swallow even with offers of "help", and therefore losing -- it is not even in the race.
asm.js and evolved Web APIs (which developers need anyway) are winning.
Evil-me on my Throne of Skulls didn't ordain this outcome. It is unfolding before our eyes across browsers, developers, and very pragmatic third parties including big game/game-engine publishers.
(But I am laughing a Dr. Evil laugh, on my Skull island. :-P)
> Why do you distrust Apple and Microsoft and ascribe bad motives to them based on their commercial interests, but fault Mozilla for not jumping on Google's Pepper treadmill like a good little-brother caricature?
I don't distrust them, or ascribe bad motives. I ascribe motives that align with their economic interests -- it doesn't matter if they're bad or good.
> Google has commercial interests too, and they have spent >$1B a year on Chrome -- including advertising and bundling that directly targets Firefox users. (It's amazing we are still alive, and possibly even growing desktop share.)
How much does Google spend on Firefox's search deal? What do you see as Google's commercial motive with Chrome?
My reading (in the context that I have some family that works on Chrome) is that their primary interest was ensuring that they could help push the web forward, and not be beholden to external interests in doing so. They have an interest in open platforms insofar as it gives them leverage over the much more strongly established platform players (eg, Microsoft, Apple).
> asm.js and evolved Web APIs (which developers need anyway) are winning.
The interesting thing is that if asm.js has sufficient adoption, the 'web' part of the equation may very well not matter at all.
If Google maintains their efforts on (P)NaCL and can provide better performance, end implementors may target both asm.js and NaCL, with shims for platform-specific functionality (not unlike most game development today). Once you're doing that, you can also target other native platforms with the same code and tooling.
So I don't think asm.js is all bad. Ironically, it could very well be the escape route from JS/HTML/CSS/DOM that we've all been praying for ever since the idea of the web app came into being. Not because it's the best technical solution, but since when has technical correctness outweighed market forces?
> Evil-me on my Throne of Skulls didn't ordain this outcome.
Of course not. But "evil you" certainly has a hand in it. There are only 4 real players in the browser market, and you're one of them.
In fact, you're the one that decided to ignore what Google has been doing and invest in asm.js to begin with, so divesting any claim in the role of asm.js's possible ascendency is a bit of a stretch.
My use of "bad" and "good" about your relative judgments of Microsoft, Apple, and Google could be "purple" and "shiny" for all it matters.
The point is you seem to treat Google as more benign and non-commercial. That's not credible based on many pieces of evidence, including their public company performance scrutiny by Wall Street. I admire Google for some things they do, and believe they do not over-optimize their share price, but they cannot ignore it, either. Also, they are a house divided, with many conflicting agendas not directly related to business goals.
> How much does Google spend on Firefox's search deal?
That's not something I can comment on, per our contract stipulated by Google, but the rumors are online and if you believe them, they show a commercial partnership, nothing more.
Numerate folks have estimated the value and cost of various search deals, see e.g. Jeremy Wagstaff of Reuters. I won't comment, except to say that Mozilla was underpaid for a long time, something we chose early on in order to avoid being greedy and triggering a bad reaction from search partners.
> What do you see as Google's commercial motive with Chrome?
Lots of motives, some mixed. It's complex, and the "make the web better" motive is still there and all to the good. Some shift away from standardization toward "works in Chrome/CWS" -- and not due to anything I did -- is evident lately, and disturbing. At the limit, it's Microsoft-y.
Again, if Google as a whole were to standardize early and often, just to take one example as we've done with the missing device and sensor APIs for mobile via Firefox OS (with Samsung patching WebKit for Tizen to match), we'd have a better web, faster. Some of the delays there can be blamed on Android, but not all.
> The interesting thing is that if asm.js has sufficient adoption, the 'web' part of the equation may very well not matter at all.
No, for Emscripten/ASM.js, you still need a C or C++ runtime, not just libc/stdio/stdlib stuff but various graphics, audio, and other APIs.
> In fact, you're the one that decided to ignore what Google has been doing and invest in asm.js to begin with, so divesting any claim in the role of asm.js's possible ascendency is a bit of a stretch.
Here you show your bias. I didn't "ignore" what Google has been doing, I estimated it as too costly to risk.
Now you tell me why the shoe isn't on the other foot. Why did Google "ignore" what we've been doing to advance JS for the last two years, and move all its Aarhus talent onto Dart, at some cost to V8? And at the cost of Epic, a "sale" we won that Google could have, had it only invested a bit more in JS.
You really do have a pro-Google, anti-Mozilla animus -- good/bad or purple/shiny, I don't care.
> The point is you seem to treat Google as more benign and non-commercial. That's not credible based on many pieces of evidence, including their public company performance scrutiny by Wall Street. I admire Google for some things they do, and believe they do not over-optimize their share price, but they cannot ignore it, either. Also, they are a house divided, with many conflicting agendas not directly related to business goals.
Absolutely not; I consider Google to be an organization whose commercial interests are ultimately far more aligned with my own than Apple's or Microsoft's. It has nothing to do with being benign or non-commercial -- my interests are in no small part commercial.
> No, for Emscripten/ASM.js, you still need a C or C++ runtime, not just libc/stdio/stdlib stuff but various graphics, audio, and other APIs.
Sure, but we (the systems/games development community) are well equipped to create common runtime libraries, especially on a platform that provides an anemic set of platform standards and components, in which case custom libraries won't suffer from QT or Swing's uncanny valley problem.
> Now you tell me why the shoe isn't on the other foot. Why did Google "ignore" what we've been doing to advance JS for the last two years, and move all its Aarhus talent onto Dart, at some cost to V8?
It seems to me that Google made a rational decision that JavaScript is not a technologically sound foundation upon which to build, and made the first moves to find alternatives.
> You really do have a pro-Google, anti-Mozilla animus -- good/bad or purple/shiny, I don't care.
It's actually an anti-JavaScript animus. The idea that JavaScript ought to be the foundation of the next generation of modern computing platforms runs counter to everything I know about language and runtime design.
It seems to be an entirely market-driven solution, not a technologically-driven one -- but those market circumstances are something you have far more influence over than I do.
You just wrote that I "ignored" Google's NaCl and Pepper work. That is not true, and yet you didn't hold Google to account anywhere on this thread (or others) for "ignoring" opportunities such as asm.js which were latent in Emscripten (in spite of their commercial support for Mandreel-compiled CWS games).
There's more to what you wrote than just anti-JS animus. But let's not get stuck on this dispute; let's be unstuck like JS :-P.
> It seems to be an entirely market-driven solution, not a technologically-driven one -- but those market circumstances are something you have far more influence over than I do.
Look deeper. The market is responding to cost structures ultimately based on how hard it is to do PNaCl + Pepper vs. Emscripten + asm.js + (Web APIs that devs need anyway).
This is not about "best tech" or "marketing" or "market power". (Firefox doesn't have Google's marketing budget, and we definitely do not have decisive market power, as Netscape and then IE did -- but neither does Chrome.)
This is about "shortest path" or "worse is better" -- who gets adoption first with something "good enough" wins, and can keep winning if the good-enough thing keeps evolving and doesn't get stuck.
JS is "good enough" and manifestly capable of evolving cross-browser via the Ecma TC39 standards process and some coopetition to be even better.
Anyway, at the asm.js level, apart from syntax aesthetics, why do you care how an int32 cast or type annotation is encoded? The semantics are sufficient, as proven by UE3 in Firefox. They only get richer as we do SIMD, task ||ism, etc.
> This is about "shortest path" or "worse is better ...
I think we're in agreement there.
> JS is "good enough" and manifestly capable of evolving cross-browser via the Ecma TC39 standards process and some coopetition to be even better.
Perhaps in disagreement there, especially when you're competing against Apple's user-first focus, and especially when I'm on the receiving end of being forced to use a JS-based stack as a developer. I do mean the full stack, too -- instruction level profiling, debugging, failure reporting, consistent performance profiles, the whole nine yards.
> Anyway, at the asm.js level, apart from syntax, why do you care how an int32 cast or type annotation is encoded? The semantics are sufficient, as proven by UE3 in Firefox. They only get richer as we do SIMD, task ||ism, etc.
Well, as an implementor of systems software, I can't help but be wary that asm.js brings along with it the entire JS language and (in practice) web stack, too. It means that the likelihood that 'web' applications will ever be free of the enormous web stack is lowered, though alternative implementations (eg, NaCL) reduce some of that risk.
I share some concern about Apple, but less so in this "post Apple" era (Google, Samsung, up-and-comers from China).
On asm.js, the subset is verified at parse time and also as needed at link time, so there's no taint of "full JS" -- yet. We do expect the heaps to cross-connect, and want that. It won't make the parts of JS you dislike live much longer, from what I can tell.
To be perfectly candid, my goal is to evolve standardized JS, and therefore its implemented and widely distributed VMs, to be a good multi-language target language (and runtime).
This is eminently doable and closer than many people think. If it succeeds, then JS-the-handcoded-source-language can live or die on its (as evolved by then) language merits, and I won't cry if it dies.
But I wouldn't bet on its fan base dropping it even if they can choose other languages.
Math.imul is just an ad-hoc patch to improve the performance of Emscripten. It's totally for Firefox. Is there a motivation to standardize and implement such a thing for other browser vendors? I'll star the V8 issue though...
Yes, from the viewpoint of a game developer, the DOM is extremely, painfully, awfully, ridiculously slow and completely useless other than static HUDs. With the DOM, we can move only hundreds of sprites at 60 fps (on the latest Core i7!). HTML5 Canvas can achieve thousands but it's also far from native (and the function of Canvas is very poor).
WebGL can gain acceptable performance in many situations, but there is still much overhead.
I suspect today's most web developers don't know the true performance of computers they are actually using.
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.
> 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,
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.
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.
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...
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
HTML5 is not the only way to achieve cross-platform. In native world, HTML5 is just "one of them". There are many cross-platform frameworks and you can choose any one you like. Look this report.
Actually this is a big reason I dislike HTML5 (or I think HTML5 is wrong). Developers don't have freedom on languages and APIs. There are no healthy competition.
And don't forget that web browser itself is a multi-platform application. You can use Chrome and Firefox on Windows/Mac/iOS/Android. These are written in a "cross-platform language" C++.
In addition, most video games are written in C++ so many games are released on multi platforms (Xbox360/PS3/PC/iOS/Android). I suspect most web developers don't even know this...
> HTML5 is not the only way to achieve cross-platform.
Nobody here, as far as I could tell, was suggesting that.
> In addition, most video games are written in C++ so many games are released on multi platforms (Xbox360/PS3/PC/iOS/Android). I suspect most web developers don't even know this...
But wait, aren't iOS apps written in Objective-C using Cocoa Touch and Android apps written in Java? I don't think you can simply write your app in C++ and call it cross platform.
> Actually this is a big reason I dislike HTML5 (or I think HTML5 is wrong). Developers don't have freedom on languages and APIs. There are no healthy competition.
I've honestly never heard lack of freedom as an argument against HTML5. This argument is strange. How is iOS any more "free" than the web?
I predicted this catastrophe when everyone was attacking Flash.