undefined | Better HN

0 pointsbunderbunder13y ago0 comments

It'd have to be bootstrapped the same way other Web standards such as CSS had to be, which admittedly might take a while.

Java and Flash are no-gos because they're not open enough - they're owned by companies that want to maintain tight control over the platforms. They're also too heavily built around their own private APIs; what would really be needed is something that sticks to the same APIs and DOM that JavaScript interacts with, in order to ensure a reasonable migration path for existing technologies.

My guess is that the easiest option would be to base such a standard on a VM and bytecode format that a major browser already does implement: the one from the Spidermonkey Javascript engine.

0 comments

4 comments · 1 top-level

masklinn13y ago· 3 in thread

So alternative VMs and VMs progress can go die in a fire, one runtime to rule them all and in the darkness bind them? No Carakan, no JavaScriptCore/Squirrelfish, no Chakram, no V8?

Here's an idea: javascript is your bytecode, and you have every single javascript VM as your runtime.

bunderbunderOP13y ago

Perhaps not all of those specific ones, at least not without modification. But you're being hyperbolic; there's absolutely no reason you couldn't have multiple implementations of the VM standard. In fact, there should be - in the grandparent I pointed out that single-owner standards like Java are a no-go in my opinion.

My only thought here is that having a bytecode standard to work from might give a little more flexibility and power to folks who want to experiment with alternative client-side languages.

CJefferson13y ago

A byte-code based on Javascript VMs would be less useful than you might think.

For many years people who have tried to build dynamic languages on Java have had to go through horrible pain to build their languages, and not gained the performance they would want -- only the recent addition of invokeDynamic have finally allowed fast implementations.

Personally, I would hope any browser bytecode would have big integers as a primitive, as implementing them in dynamic language is very slow. However, no Javascript byte code would have big integers, as they aren't in Javascript!

1 more reply

masklinn13y ago

> But you're being hyperbolic

Not really.

> there's absolutely no reason you couldn't have multiple implementations of the VM standard.

If you define a bytecode standard, you greatly restrict the flexibility of VM implementors and the possible outputs. A stack-based bytecode will preclude register-based VMs, V8 doesn't even use bytecodes, it does all translations straight from source via two different JITs.

> My only thought here is that having a bytecode standard to work from might give a little more flexibility and power to folks who want to experiment with alternative client-side languages.

It doesn't. It might provide them more a little more simplicity because they merely need to generate binary bytecode streams rather than text, but it adds no expressive power, and as I noted it severely limits the flexibility of the runtime implementors.

j / k navigate · click thread line to collapse