[carsongross]

Surprise, surprise. Mr. Javascript thinks a VM for the browser would be a bad idea. Let's address his points:

Viewing source is a non-sequitor: the source code could be streamed down with the bytecode.

Standardizing a bytecode is no harder than standardizing a language and DOM, in fact, should be easier.

Versioning bytecode is no harder than versioning languages.

Bytecode does not imply an implementation any more than a language does, although it can imply semantics.

And then, at the end, he basically advocates a JS-specific bytecode. Hah. Oh, but they aren't working on it in committee. That says about all you need to know.

There is nothing about a bytecode spec that harder than a language and language spec.

Basically, he doesn't want any competition for Javascript. That was an incredibly weak podcast and he should have been shredded for it. People cut this guy way too much slack.

[ootachi]

The semantics are the hard part. Just making a bytecode for some language isn't hard. The problem is coming up with some semantics that allow all languages to be implemented efficiently on top of it. Turns out that's extremely difficult. The JVM and .NET certainly didn't achieve that; the Java-fied and .NET-ified versions of languages are typically slower and don't integrate well with their host languages.

[carsongross]

Slower and integrate less well than javascript?

C'mon.

[kirbysayshi]

The view source is not a non-sequitor. What would prevent a server from refusing to stream the source? It would have to be part of the VM spec that the source must be made available, and that seems unlikely.

I look at Flash, which I used to develop in (this is not meant to be a comment on Flash itself). There are amazing people out there doing amazing things, but because the source isn't right there, a blog post with code snippets is mandatory. Whereas with JS you can typically learn something even if it's obfuscated (to an extent).