Hacker News Reader

Comment by trothamel | Hacker News Reader

As much as I like Python, I don't think this is the right approach.

What browsers need to do is to have a machine-level bytecode, so that they can download whatever interpreters are needed to run the scripting code the page uses. Then pages can be written in whatever language the developer feels is best.

This is the real potential of something like Native Client - although it doesn't look like that potential will be achieved any time soon.

View on HN

There's no such thing as a language-agnostic bytecode. A bytecode is just a compressed source encoding of some language.

I take it you never heard of the JVM, or Microsoft's CLR.

I don't think that it's the right approach only ever to allow JavaScript (just because every time anything else is mentioned, we inevitably go off on this tangent).

There is no indication that browsers are going to standardize on a VM (let alone NaCl) any time soon.

If someone just stopped bikeshedding and did Python in the browser, there's no reason a machine-level bytecode or whatever couldn't be implemented later.

As much as I don't like Microsoft, I actually think the .NET CLR would be an excellent choice for such a runtime. NaCl not so much; target architecture-dependent compiled code is a major downside.

There's PNaCl: http://www.chromium.org/nativeclient/pnacl/building-and-test...

What about pnacl?

http://www.chromium.org/nativeclient/pnacl/building-and-test...

I had no idea about that, thanks

Pages downloading and executing things just reminds me of ActiveX from the late 90s. I think South Korea still relies on the technology for their home-grown version of SSL.

Pages download and execute things all the time. The problems with ActiveX was that it was tied to the Windows API, and that it wasn't sandbox - it wasn't the idea of downloading code.

Reply on news.ycombinator.com