I'm hoping eventually all the browsers will have something low level and fast enough to realistically do this kind of thing (e.x. Native Client)
A lot of things that need native speeds can be run in sandboxes with a few IO APIs (network, display, user input) just fine. Video codecs are a perfect example.
Imagine being able to link your app to the best available version of HTML6 immediately... or some other application development environment entirely.
I don't think Native Client is the solution. For technical reasons, the sandboxing mechanism there has a big cost to entering and leaving the sandbox. The worst case for that is something like a codec, where you constantly stream information in and out. NaCl works better when you have lots of computation and very little input/output.
Regardless, I think there are more suitable technologies for codecs on the web: A lot can be done in WebGL shaders (Broadway is starting to work on that), and proposed web standards like WebCL and RiverTrail look promising too.
Right now this demo is faster in Chrome it seems, while the original Broadway (H264 instead of WebM) is faster in Firefox, but the important thing is that the differences are not that big, and all JS engines are in very good shape and improving. We'll have even better performance a year from now.
I'm surprised it is much slower than Firefox and Chrome, though. Apple recently enabled the new JSC JIT on all platforms, I thought, which should be quite fast. Maybe typed arrays have not been specifically optimized yet or something like that.
I'd love to see WebKit inside NaCl, though.
 with the caveat that NaCl is not the best way to sandbox them, since video codecs often include hand-coded assembly for maximum performance, which can be run just fine inside an OS sandbox, but doesn't play well with the custom code demanded by NaCl's software fault isolation. To some extent, I don't understand why NaCl exists, as its advantages over such an sandbox are minimal, but that's a rant for another day.