3 ms·

Even if this is old, I don't understand why they don't push an open Browser VM spec. This would be much more open and fruitful.

TillE 13y ago
Yeah, a flexible bytecode VM seems like the ideal solution for browser scripting, rather than the awful kludge of "compiling" things to Javascript. I'm not quite sure why there hasn't been more effort towards that.
- modarts 13y ago
  https://www.dartlang.org/articles/why-not-bytecode/ https://www.dartlang.org/articles/why-not-bytecode/
  - pera 13y ago
    > The key argument in favor of a language VM is the development process. > If you’re writing JavaScript, your “compile step” is just refreshing the browser. This is not a really strong argument: the development process could be exactly the same if your development environment automate certain task, as syntax checking (like with jslint), recompile when the sources have changed (ie file watch functionality), reload when save (like with tincr)...
  - chromanoid 13y ago
    people will want to choose their own language forever. not building some low level spec like asm.js or a similar bytecode like language is just a marketing strategy.
duaneb 13y ago
Ok, what would you consider for a universal vm? It seems to me that it's much easier to put one in later than the fundamental problems with JS that need addressing now.
- chromanoid 13y ago
  It should be a Spec that supports some generic operations and a spec for a standard library (interaction with dom etc.). Maybe bytecode is too low level, how about some kind of stackless 3-address intermediate representation like Soot uses for JVM bytecode (jimple has afair ~15 operations, see http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.58.7708&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.58....). This would lead to a language one can wonderfully compile to. asm.js is probably already this idea in practice.

TillE 13y ago

Yeah, a flexible bytecode VM seems like the ideal solution for browser scripting, rather than the awful kludge of "compiling" things to Javascript. I'm not quite sure why there hasn't been more effort towards that.

modarts 13y ago
https://www.dartlang.org/articles/why-not-bytecode/ https://www.dartlang.org/articles/why-not-bytecode/
- pera 13y ago
  > The key argument in favor of a language VM is the development process. > If you’re writing JavaScript, your “compile step” is just refreshing the browser. This is not a really strong argument: the development process could be exactly the same if your development environment automate certain task, as syntax checking (like with jslint), recompile when the sources have changed (ie file watch functionality), reload when save (like with tincr)...
- chromanoid 13y ago
  people will want to choose their own language forever. not building some low level spec like asm.js or a similar bytecode like language is just a marketing strategy.

duaneb 13y ago

Ok, what would you consider for a universal vm? It seems to me that it's much easier to put one in later than the fundamental problems with JS that need addressing now.

chromanoid 13y ago
It should be a Spec that supports some generic operations and a spec for a standard library (interaction with dom etc.). Maybe bytecode is too low level, how about some kind of stackless 3-address intermediate representation like Soot uses for JVM bytecode (jimple has afair ~15 operations, see http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.58.7708&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.58....). This would lead to a language one can wonderfully compile to. asm.js is probably already this idea in practice.