3 ms·

So, why aren't we talking about browser bytecode you guys? Why is everyone's solution "whelp, you're stuck with js". Is asm.js going to be a useful halfway poi

by phillmv 14y ago

So, why aren't we talking about browser bytecode you guys? Why is everyone's solution "whelp, you're stuck with js". Is asm.js going to be a useful halfway point?

endlessvoid94 14y ago
I largely agree with you. Food for thought -- can you describe to someone why using bytecode would be faster? V8 is pretty damn fast, would it really be made any faster by using a bytecoded VM instead? There are other reasons to use a bytecode VM besides performance, but the one with the code wins, in this case :-)
- mistercow 14y ago
  The problem, as I see it, with a browser bytecode, is that bytecodes are generally tailored to a specific language. A bytecode designed for JS, for example, is not necessarily something you'll be able to implement Python or Ruby in particularly efficiently. With asm.js I'd be willing to bet that a general purpose bytecode would not let you run any of these languages more than, say, twice as fast as simply pushing the interpreter through emscripten.
mistercow 14y ago
Really the only reason I see that asm.js should be a halfway point rather than an endpoint is that it's kind of verbose. Even so, gzip makes a lot of that point moot, and it might be possible to make a bytecode with a 1:1 correspondence with asm.js (which could then be parsed using JS in legacy browsers), to make something even more concise. But including an entire emscripten'd ruby environment on your website just because you don't want to use JS seems insanely inefficient, and no bytecode is going to fix that.
- anonymous 14y ago
  If we could just have shared libraries in the browser, it would solve the problem of having to serve the entire ruby runtime with each webpage. You'd just put a tag in the header indicating you're using ruby runtime version X and the browser would download it and put it in some permanent cache for javascript code. Really, it's high time we got some sort of package management for browsers. P.S. I mean shared libraries in the abstract sense, not .so or .dll files specifically.
  - mistercow 14y ago
    Well, we sort of have that in the from of CDNs, but taking it any further than that sounds like a very sticky security situation.
stormbrew 14y ago
This keeps coming up lately and it really needs to be clarified. Asm.js is not a useful tool for running dynamic languages as a browser-replacement for js. It carves out its own heap and has extremely limited interaction with the DOM. You probably could establish a bytecode for that purpose, but the problem is that putting it at a higher level (where real interaction with the DOM is possible) gives you an impedance mismatch between object (how messages are dispatched) and execution models (how things like exceptions propagate) that can only be overcome at some degree of a performance loss. I'm not saying that can't be solved, but I don't think anyone's put any serious effort into doing so in a generalizable way.

by phillmv 14y ago

So, why aren't we talking about browser bytecode you guys? Why is everyone's solution "whelp, you're stuck with js". Is asm.js going to be a useful halfway point?

endlessvoid94 14y ago

I largely agree with you. Food for thought -- can you describe to someone why using bytecode would be faster? V8 is pretty damn fast, would it really be made any faster by using a bytecoded VM instead? There are other reasons to use a bytecode VM besides performance, but the one with the code wins, in this case :-)

mistercow 14y ago
The problem, as I see it, with a browser bytecode, is that bytecodes are generally tailored to a specific language. A bytecode designed for JS, for example, is not necessarily something you'll be able to implement Python or Ruby in particularly efficiently. With asm.js I'd be willing to bet that a general purpose bytecode would not let you run any of these languages more than, say, twice as fast as simply pushing the interpreter through emscripten.

mistercow 14y ago

Really the only reason I see that asm.js should be a halfway point rather than an endpoint is that it's kind of verbose. Even so, gzip makes a lot of that point moot, and it might be possible to make a bytecode with a 1:1 correspondence with asm.js (which could then be parsed using JS in legacy browsers), to make something even more concise. But including an entire emscripten'd ruby environment on your website just because you don't want to use JS seems insanely inefficient, and no bytecode is going to fix that.

anonymous 14y ago
If we could just have shared libraries in the browser, it would solve the problem of having to serve the entire ruby runtime with each webpage. You'd just put a tag in the header indicating you're using ruby runtime version X and the browser would download it and put it in some permanent cache for javascript code. Really, it's high time we got some sort of package management for browsers. P.S. I mean shared libraries in the abstract sense, not .so or .dll files specifically.
- mistercow 14y ago
  Well, we sort of have that in the from of CDNs, but taking it any further than that sounds like a very sticky security situation.

stormbrew 14y ago

This keeps coming up lately and it really needs to be clarified. Asm.js is not a useful tool for running dynamic languages as a browser-replacement for js. It carves out its own heap and has extremely limited interaction with the DOM. You probably could establish a bytecode for that purpose, but the problem is that putting it at a higher level (where real interaction with the DOM is possible) gives you an impedance mismatch between object (how messages are dispatched) and execution models (how things like exceptions propagate) that can only be overcome at some degree of a performance loss. I'm not saying that can't be solved, but I don't think anyone's put any serious effort into doing so in a generalizable way.