> Also, problem with NaCl is it forces developers to move away to a different toolchain. Most developers would feel more comfortable and productive in developing in the browser, rather than moving to a IDE.

So make a toolchain that runs in the browser. There's nothing stopping you from building NEXE modules at runtime; you could compile LLVM itself for NaCl and embed the whole toolchain in the browser and compile at runtime.

There's audio processing stuff that I'd love to do in web browsers, but I refuse to touch Javascript with a ten-foot pole. I am the kind of person that would like NaCl to be adopted outside of Chrome. If you are the kind of person that is more interested in building the "app" part of some application of that kind of program, you have nothing to fear from NaCl -- just think of it as opening up the "standard native code" (native browser code, like video codecs, gzip decompression, etc) part of the web browser to everyone. You don't really care about what's going on under the hood when your users decompress some data you served to them, as long as everything works properly, right? That's pretty much the definition of something that most web developers couldn't care less about, and that people who do (for lack of a better term) "fast computing" care desperately about.

To give a recent example, what if you'd like to start serving Opus audio to all your users? The standard response to that idea now is "that's funny, Internet Explorer will never even support Vorbis, and that's over a decade old." If safe native code execution was a standard part of the browser right now, it would be trivial to distribute an Opus decoder alongside the "web app" you implemented in Javascript. Opus would just be your competitive advantage, not something you need to beg people to implement. It would already be ubiquitous.

Before anyone mentions X implementation of Y audio codec in Javascript in an attempt to discredit the value of native code execution, just stop. I highly doubt it will work acceptably on my mom's computer (the average computer that accesses your site is almost surely a hell of a lot less powerful than you may assume it is), and I highly doubt you'll ever be able to rival the performance of native code for processing on the order of video codecs anyways. Not to mention the fact that the majority of the nontrivial Javascript audio demos you've heard were made possible in no small part due to standardized, native code linear filtering and convolution.

"Frustration" would be the word that sums up the whole "web app" movement to me. When I see that someone's made a client-side GIF animating "web app," all I can think about is how it would have taken two seconds to hook an existing highly performant C GIF encoder up to some Javascript, and instead we had to wait for someone who knows Javascript to hack a painfully slow (and therefore useless for the vast majority of users) alternative together. You know how ubiquitous similar server-side services are? That's because all it takes to make one is a simple Javascript/HTML form (or HTTP, if you want to get trivial)-based interface to an existing C program. Just think of where client side web apps could be right now if the same were true for them.

I've been doing audio processing in Flash for a while (most recently, sample-based synthesis implementing a decent portion of SFZ and SF2, with 64-voice polyphony and filters) and I did have to push an unusual degree of effort into optimizing the sample copying code, with a Haxe macro that generates an optimal inlined loop for each combination of parameters. It can still use up most of a core when maxed out...

...however, I did some math and some extrapolation and determined that within the next three to five years this domain will be completely reasonable to approach from JS, driven by a combination of technologies:

-access to GPGPU from the browser. DSP work can generally be defined in terms of a shader, although it's still a very poorly understood area.

-more general-purpose cores, faster JIT performance, and possibly single-threaded hardware improvements as well. These things compound easily, so we could end up with a 50-100x larger JS performance envelope for this domain without even considering the GPU.

-maturation of the existing and planned audio APIs for common tasks. As you point out, this isn't interesting from a "ground-breaking tech" perspective, but in covering typical application needs, it's as important as the others since it's both convenient and optimized out of the box.

-maturation of cross-compilation technologies, smoothing over the "code has already been written" issue.

In a lot of ways, all JS has to do to be competitive is the "catch-up" work. It takes quite a while in tech time, but in human time, most of us will be around in the next decade.

You're right. Browsers are constraining innovation to a top-down approach, where browser vendors try to design and implement alternatives to things like TCP, POSIX.

What would be better is if browser vendors exposed a core low-level API to trusted installed web apps (as opposed to web pages) and then let open source build on that.

For example, instead of coding up IndexedDB and leaving no alternative, just provide proper POSIX, and let the database community do its thing.

Because there's more interest in improving the (publicly accessible) web as a platform than improving installed web apps.

Regardless, to expose such a low-level API would eliminate one of the big advantages of the web: given a browser, I can use any web app on any device. Given, for example, given a TV (which are typically closed platforms, but increasingly often include a fully featured browser), you likely wouldn't be able to install anything that a certain web app depended on (and even if you could, what are the odds that it's been tested on a big-endian platform?).

No, it would not eliminate the big advantage of the web as you say, merely deepen it.

See Tim Berners-Lee: http://lists.w3.org/Archives/Public/public-webapps/2012JanMa...

None of what timbl said in that post (nor what anything, from memory, in that thread said) covered shipping native code to the browser: it was merely talking about privileged web apps, which is a very different problem area (and one that should definitely be explored!).

Yes, my comment was concerning the top-down approach taken by browser vendors, and that web apps need to be empowered with low-level APIs such as TCP and POSIX. I don't think I said or TBL said that we need to ship native code to browsers to do this. We don't. We don't need another language. Javascript is fine. We do need better low-level APIs. We do need to get away from relying on browser vendors to spec and implement everything correctly, because with such a massive surface like they're targeting they won't. We do need to push this responsibility out to the edges. We need to drastically reduce the standard API and move the functionality from high level (as in IndexedDB) to low level (as in POSIX). We need a strong powerful stable small core and OSS must do the rest. That's the general idea. The finer details can be nitpicked and that won't invalidate the general idea. Browser vendors are simply doing way too much.

How would you expose POSIX on Windows?

POSIX is an interface not an implementation.

> but I refuse to touch Javascript with a ten-foot pole.

Why? Honest question here: what are the problems that are making you unwilling to even try it? Is performance the main problem?

> just think of it as opening up the "standard native code"

As long as the browser is running on a small set of target hardware architectures. And everyone else gets locked out, right?

If PNaCl ever happens, that might change, but at the moment that's how NaCl works: you tie your "web page" to a particular set of hardware architectures when you use it.

I don't think NaCl is targeted at web devs that are comfortable developing in the browser. It's targeted at the other devs that aren't comfortable with JS and who write C++ (or other) code (like in games or other graphic-intensive stuff).