There's a big difference between "my use case" and "all use cases".
Sure, JavaScript is fast enough for a lot of things.
But it's also too slow for many things that reasonable people would like to do on the web.
See Mozilla's pdf.js: it makes perfect sense to have a PDF viewer written in JavaScript (and not a blob of insecure C++ code in the form of the plugin).
pdf.js would not be possible at all "long, long time ago", even though JS was adequate for your use cases at that time.
pdf.js is barely possible today - it works for simple documents but its performance on more complex documents is still so much worse than what C++ plugin gives that many people go back to plugins.
Performance is one of the most important competitive aspects of software. Given 2 products with similar features, people go for the faster, which is a big reason why Chrome was so successful.
We're still far away from making JS speed covering all the important use cases.
Until JavaScript can decode mp4 in JavaScript (at speeds not much slower than optimized C++), JavaScript is not fast enough.
> There's a big difference between "my use case" and "all use cases".
Yes. This is an appropriate response to a significant fraction of the complaints on this site and all other tech sites. I usually think of it as "your experience is not universal".
Given the direction of gaming and streaming, your mp4 example seems apt... I think being able to do a 1080p stream at 30-60fps in JS is an appropriate goal for both hardware, and software. Canvas+JS is likely to be the "thin" client structure or the future... I think if it were possible to do this in JS, we wouldn't need ignorant plugin points for DRM.. encrypted streaming could "just work" on any platform, not that I want more DRM.
I like that we are finally at a point, where legacy emulators in JS are a reality. I do think some attention to worker interaction, and perhaps locking say a canvas, or audio channel to a worker should be something able to be done.
I think being able to do a 1080p stream at 30-60fps in JS is an appropriate goal
Why is that an appropriate goal? How about a video element -- which the browser implements in the ideal manner (which is usually a thin layer over hardware decoding) -- that handles h264? Why in the world would you want to do that in JavaScript, besides as a "because I can" challenge?
Further your notion that DRM would "just work" is really unclear. I don't think you understand the concerns of the DRM folks if you think that you'll just do it in decrypt.js and all will be good.
Sure, JavaScript is fast enough for a lot of things.
But it's also too slow for many things that reasonable people would like to do on the web.
See Mozilla's pdf.js: it makes perfect sense to have a PDF viewer written in JavaScript (and not a blob of insecure C++ code in the form of the plugin).
pdf.js would not be possible at all "long, long time ago", even though JS was adequate for your use cases at that time.
pdf.js is barely possible today - it works for simple documents but its performance on more complex documents is still so much worse than what C++ plugin gives that many people go back to plugins.
Performance is one of the most important competitive aspects of software. Given 2 products with similar features, people go for the faster, which is a big reason why Chrome was so successful.
We're still far away from making JS speed covering all the important use cases.
Until JavaScript can decode mp4 in JavaScript (at speeds not much slower than optimized C++), JavaScript is not fast enough.