Any language could. Javascript's ubiquity is just an accident of history. Nobody planned for it to be this way. It's not even the best way.
Why not a C applet in the browser with access to native hardware? Let the OS handle access to memory and system call interception. Why not CL? Or Python? Or anything else? Why do we have to let JS continue to be the de facto language and tack on all of these monstrosities upon it?
An important reason is security. The security of any web language is of vital importance, for obvious reasons. When you go low level or introduce umpteen different languages, maintaining the same level of security becomes increasingly challenging.
But I agree with you that JS is an unfortunate language to be stuck with (although many people appear to be content with it). I especially dislike that it's weakly typed.
Isn't Google's NativeClient something like what you're suggesting though?
I'm not suggesting anything, the paper I linked just described one such method for executed untrusted binary code through the browser.
At a cursory glance it looks like NativeClient is built on a sandbox and doesn't allow arbitrary binary applications to run natively on the OS. It doesn't allow system calls and looks like some sort of run-time manages memory on behalf of the application.
If you're at all interested, it cannot hurt to read the paper I linked to. It was written in 1997 and requires a little bit of historical forgiveness but the ideas are rather quite interesting.
Any language could. Javascript's ubiquity is just an accident of history. Nobody planned for it to be this way. It's not even the best way.
Why not a C applet in the browser with access to native hardware? Let the OS handle access to memory and system call interception. Why not CL? Or Python? Or anything else? Why do we have to let JS continue to be the de facto language and tack on all of these monstrosities upon it?