Comment by kirbysayshi | Hacker News Reader

Comment by kirbysayshi | Hacker News Reader

Parent Full thread

Brendan Eich has talked about why bytecode + VM is a bad idea for a browser: http://www.aminutewithbrendan.com/pages/20101122

If you really want a VM, it already exists. It's called JavaScript, assembly language of the web.

I would hate for sites to start saying, "Requires the PyJSVM v0.8 or better to function, download it now!"

EDIT: in hindsight, this post was careless. I was wrong about the "PyJSVM" point, and I posted the minutewithbrendan link to provide commentary, not "Eich said it, so it must be true."

What I should have said:

JavaScript is so widely used today, that anything that comes along purporting to be better (such as bytecode, Dart, whatever) must be so much better as to provide a clear reason for developers and users. If it's just "better", then JS will remain dominant because it's good enough. Therefore, it makes sense to target JS from other langs. It's definitely not getting slower, and we're on the cusp of some great APIs!

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.

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.

Slower and integrate less well than javascript?

C'mon.

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).

"Requires the PyJSVM v0.8 or better to function, download it now!"

WTF is that? The whole point is that you'd target the bytecode standard. This would be just like targeting javascript today, but it wouldn't require hacks to deal with the broken aspects of javascript and maybe tools like cliend-side debugging would be useful.

It doesn't have anything to do with individual VMs per language.

Yes, you're right. Sorry, I was mistaken, confusing how Dart has its own VM, and how the browser has to have explicit support for said VM. (And yes, I know Dart can also compile to JS, that's not my point).

You wouldn't, you would do server side compilation, if we could require users to install a plugin we would already do it today and not bother with JS.

Reply on news.ycombinator.com