12 ms·

The Elusive Universal Web Bytecode

32 points by joubert 12y ago

falcolas 12y ago
> some people don't like some of those things What does that even mean? So why did the author throw out LLVM byte code again? It's BSD, it has bytecode compilers for most platforms browsers exist on (100% vs. 50% speed), and doesn't rely on a subset of another language. It also doesn't have the requirement to fall back to vanilla Javascript. As an added bonus, Javascript could easily compile down to LLVM bytecode. Seems like the author already preferred their answer and threw out some BS to "justify" their choice. JS probably will remain the "byte code of the web", but this article adds nothing to that trajectory.
- flohofwoe 12y ago
  The author is Alon Zakai, creator of emscripten, and the article is quite old (2013) when there was a somewhat heated debate whether a byte code format would be better for the web instead of Javascript, with the byte code fans having fairly theoretical reasons (basically: 'because it is the right way to do it and Javascript sucks anyway'), instead Alon went ahead and demonstrated that in reality the more pragmatic solution to compile to JS has no disadvantages compared to byte code, and you don't need to add a whole new language engine to browsers (like Google PNaCl does), but (in the case of asm.js) only fairly minor modifications to existing JS engines, and you keep full compatibility (but lower performance) with old JS engines. Interestingly, emscripten now also supports an interpreted byte code mode (called emterpreter), which stores code in a byte code format, and runs this inside an JS interpreter(!). The reason for this was quicker startup time for large scripts, but (my own speculation!) it might also be a path to a future byte code distribution format if there are indeed any other practical advantages. Another interesting point is that Safari actually has now an LLVM based compilation layer in their Javascript engine, so it's coming together from both sides with LLVM being the glue (emscripten's front end is also LLVM).
  - falcolas 12y ago
    > more pragmatic solution to compile to JS has no disadvantages compared to byte code The disadvantage is that compilation takes a not-insignificant amount of time, particularly if you want to go from running AST on a VM to running platform native code. It takes even longer if you're on an underpowered device which could take the most advantage of a simple IR bytecode -> native bytecode compilation. This is evidenced in the 50% numbers from the OP's article.
- mrec 12y ago
  LLVM's IR makes no stability guarantees - it can change from one release to the next, with no backward compatibility. That's not ideal for something you're slinging out to the web. I believe this is the same reason Khronos defined their own IR (SPIR) instead of using LLVM's. Needs to be stable.
  - CyberDildonics 12y ago
    That is one reason, the other is being easy and fast to process with tools.
  - legulere 12y ago
    You mean SPIR-V, SPIR is LLVM based
- sp332 12y ago
  LLVM IR isn't portable, it's platform-specific.
  - Someone 12y ago
    For those who don't know why that is true (or even that that is true): http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437...
  - falcolas 12y ago
    And yet Mozilla can use it to write Rust compilers which target ARM and x86-64 architectures, for Mac, Linux and Windows OSes. It might not compile on an AT-MEGA, but it seems portable enough for the purposes of acting as a browser bytecode representation.
    - sp332 12y ago
      They distribute Rust as Rust code, not as LLVM IR. You use LLVM to compile Rust to a target-specific IR and then to a target-specific binary. Try reading that link your sibling posted.
- have_humility 12y ago
  I don't know if maybe the page relies on JS being enabled to load some content and you have JS disabled or not, but there is significant discussion of LLVM on that page. > So why did the author throw out LLVM byte code again? "Again" is right. I don't particularly seek out discussions on this topic, but I've seen this question asked and answered at least half a dozen times before, which is enough for it to start getting annoying.
- TazeTSchnitzel 12y ago
  > So why did the author throw out LLVM byte code again? It's BSD, it has bytecode compilers for most platforms browsers exist on (100% vs. 50% speed), and doesn't rely on a subset of another language. It also doesn't have the requirement to fall back to vanilla Javascript. As an added bonus, Javascript could easily compile down to LLVM bytecode. LLVM has a single implementation, is very complex, isn't even remotely portable, and is primarily suited to C and C++, or similar languages. We also already have a very performant transformation format for LLVM IR into JS: asm.js. And asm.js fixes most of LLVM IR's problems: * It's very simple * It's portable across architectures * It doesn't have undefined behaviour * It has multiple implementations * It has forwards-compatibility (existing browsers, regardless of explicit support, can run asm.js code) * It is standardised
  - rictic 12y ago
    Well put. One nit: I think you mean backwards compatibility, though asm.js can also be expected to work without modification in future browsers and future versions of javascript.
    - TazeTSchnitzel 12y ago
      Yeah, I originally put backwards-compatibility, but I wasn't sure if forwards-compatibility was the right word for allowing old software to use new code.
CyberDildonics 12y ago
I heard about a project called Oak that was supposed to do this, never heard what happened to it...
- mmastrac 12y ago
  I assume this is a subtle Java joke -- for those who completely missed it: http://en.wikipedia.org/wiki/Oak_%28programming_language%29#Differences_with_Java http://en.wikipedia.org/wiki/Oak_%28programming_language%29#... If we were going with a bytecode, I wouldn't choose LLVM or JVM. Neither is really suited for the task.
- deleted 12y ago
  [deleted]
- DonHopkins 12y ago
  It got renamed, then somebody made a backroom deal to borrow the new name for another totally different language in order to trick people into confusing the two languages, then the other language became much more popular and widespread than the one that used to be called Oak, totally taking over the browser, and making good headway at taking over the server too. Incidentally, Arthur van Hoff just pointed out: >Time flies. This week it is 20 years since we announced Java... "Why Sun Thinks Hot Java Will Give You a Lift" - March 23 1995 http://web.archive.org/web/20060819094743/http://java.sun.com/features/1998/05/images/merc_large.gif http://web.archive.org/web/20060819094743/http://java.sun.co...
  - arethuza 12y ago
    I blagged a copy of Java from Arthur a while before that when I found out he was working at Sun - I'd used HyperNeWS for quite a while and was in awe of his programming skills. Edit: Are you this DonHopkins? http://art.net/~hopkins/Don/hyperlook/index.html http://art.net/~hopkins/Don/hyperlook/index.html
    - DonHopkins 12y ago
      That's me. While I was working at Sun in '90-91 on NeWS, we tried very hard to convince management to hire him to work on HyperNeWS for TNT, but Sun wouldn't give us a requisition (because they intended to kill NeWS, not save it). So I quit Sun and moved out to Glasgow to work with him at the Turing Institute on HyperLook, and ported SimCity to HyperLook. HyperNeWS aka HyperLook was like HyperCard implemented with PostScript programming and graphics, plus networking. In that alternate universe, PostScript would have been the universal bytecode for the web. https://www.scribd.com/doc/77192884/HyperLook-Product-Info https://www.scribd.com/doc/77192884/HyperLook-Product-Info https://www.scribd.com/doc/77164708/HyperLook-SimCity-Manual https://www.scribd.com/doc/77164708/HyperLook-SimCity-Manual Arthur's programming and entrepreneurial skills are indeed awesome, and I'm glad I quit my day job at Sun and left the country for the opportunity to work with him! He's now an advisor to my current company: http://pantomimecorp.com/the-team http://pantomimecorp.com/the-team
marcosdumay 12y ago
I'd settle for a bytecode that supported numbers (instead of only strings), blocking I/O (in addition to non-blocking), and easy integration with system (or, in this case browser) utilities. Javascript happens to have none.
- TazeTSchnitzel 12y ago
  Uh, JS has numbers, blocking IO, and easy integration. What are you on about?
  - marcosdumay 12y ago
    JS implement numbers as strings (has bitten me once). Last time I looked at, there was no blocking IO at all (there is continuation, but it does not solve the problem because there isn't any locking mechanism - yep, I'd like atomic locking at my bytecode too). That's even the main "selling point" Node.js people throw around as if it was a good thing. By easy integration I mean the hability of using capabilities available at the system, but not exported into the language runtime. It can be solved by something that would let me query the sandbox enviroment for the existence of a "library" that exports foreign functions, and use it. Also, something that by the other side lets me write and distribute one such "library" so people can install them on their browsers let JS use its functionality.
    - jdmichal 12y ago
      > JS implement numbers as strings (has bitten me once). What? JS implements all numbers as 64-bit floating point, which happens to be able to perfectly represent the 32-bit integer space. It can actually perfectly represent a 52-bit integer space. See Number.MAX_SAFE_INTEGER [0] for details. Now, JS does allow for type coercion between values when using the `==` operator. Luckily, the `===` operator also exists which eliminates this effect. [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... > Last time I looked at, there was no blocking IO at all. What does blocking even mean in a single-threaded event-pump context? Does it mean other events can be processed while the IO executes? Because that's exactly what an asynchronous AJAX request does. Or does it mean it blocks the only thread available? Because that's what a synchronous AJAX call does. Now, if your argument is that JS doesn't have an async / await construct in order to make asynchronous AJAX look like synchronous AJAX in the code, then that's in ES7.
rikkus 12y ago
I've pondered this a couple of times. One Ask HN I posted: https://news.ycombinator.com/item?id=6773980 https://news.ycombinator.com/item?id=6773980 A reply to a comment I made on another post says that the CLR and JVM suffer from GC pauses, which would not be acceptable for web apps.
- fla 12y ago
  GC pauses already occur in most JS engine. They are especially tolerable in a web app.
Rusky 12y ago
The article makes the argument that existing systems are easier to improve incrementally, while designing new systems is more work and not guaranteed to succeed. The problem is JavaScript-as-bytecode is not especially easy to improve. Anything you want to add/change that would make it a better bytecode has to be balanced with the language's use by humans. The solution to one-VM-to-rule-them-all is not to cram everything into a higher-level system with lots of assumptions (JavaScript) or to ignore portability (NaCl, LLVM), but to use a bytecode that's low-level enough to implement the various assumptions needed by higher layers. That way both C++ and JavaScript can run at full speed as well as have their implementations changed (even across websites!) without pushing every change through the browsers- just like native apps, with the browser providing only cross-platform and security, nothing more.
- TazeTSchnitzel 12y ago
  > The problem is JavaScript-as-bytecode is not especially easy to improve. Anything you want to add/change that would make it a better bytecode has to be balanced with the language's use by humans. There are very few cases where human use causes problems. goto is the only one I can think of. Yet we've gotten loads of great improvements in ES6 to make it a good compiler target, like float32 and better integer multiplication.

32 points by joubert 12y ago

> some people don't like some of those things What does that even mean? So why did the author throw out LLVM byte code again? It's BSD, it has bytecode compilers for most platforms browsers exist on (100% vs. 50% speed), and doesn't rely on a subset of another language. It also doesn't have the requirement to fall back to vanilla Javascript. As an added bonus, Javascript could easily compile down to LLVM bytecode. Seems like the author already preferred their answer and threw out some BS to "justify" their choice. JS probably will remain the "byte code of the web", but this article adds nothing to that trajectory.

flohofwoe 12y ago
The author is Alon Zakai, creator of emscripten, and the article is quite old (2013) when there was a somewhat heated debate whether a byte code format would be better for the web instead of Javascript, with the byte code fans having fairly theoretical reasons (basically: 'because it is the right way to do it and Javascript sucks anyway'), instead Alon went ahead and demonstrated that in reality the more pragmatic solution to compile to JS has no disadvantages compared to byte code, and you don't need to add a whole new language engine to browsers (like Google PNaCl does), but (in the case of asm.js) only fairly minor modifications to existing JS engines, and you keep full compatibility (but lower performance) with old JS engines. Interestingly, emscripten now also supports an interpreted byte code mode (called emterpreter), which stores code in a byte code format, and runs this inside an JS interpreter(!). The reason for this was quicker startup time for large scripts, but (my own speculation!) it might also be a path to a future byte code distribution format if there are indeed any other practical advantages. Another interesting point is that Safari actually has now an LLVM based compilation layer in their Javascript engine, so it's coming together from both sides with LLVM being the glue (emscripten's front end is also LLVM).
- falcolas 12y ago
  > more pragmatic solution to compile to JS has no disadvantages compared to byte code The disadvantage is that compilation takes a not-insignificant amount of time, particularly if you want to go from running AST on a VM to running platform native code. It takes even longer if you're on an underpowered device which could take the most advantage of a simple IR bytecode -> native bytecode compilation. This is evidenced in the 50% numbers from the OP's article.
mrec 12y ago
LLVM's IR makes no stability guarantees - it can change from one release to the next, with no backward compatibility. That's not ideal for something you're slinging out to the web. I believe this is the same reason Khronos defined their own IR (SPIR) instead of using LLVM's. Needs to be stable.
- CyberDildonics 12y ago
  That is one reason, the other is being easy and fast to process with tools.
- legulere 12y ago
  You mean SPIR-V, SPIR is LLVM based
sp332 12y ago
LLVM IR isn't portable, it's platform-specific.
- Someone 12y ago
  For those who don't know why that is true (or even that that is true): http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437...
- falcolas 12y ago
  And yet Mozilla can use it to write Rust compilers which target ARM and x86-64 architectures, for Mac, Linux and Windows OSes. It might not compile on an AT-MEGA, but it seems portable enough for the purposes of acting as a browser bytecode representation.
  - sp332 12y ago
    They distribute Rust as Rust code, not as LLVM IR. You use LLVM to compile Rust to a target-specific IR and then to a target-specific binary. Try reading that link your sibling posted.
have_humility 12y ago
I don't know if maybe the page relies on JS being enabled to load some content and you have JS disabled or not, but there is significant discussion of LLVM on that page. > So why did the author throw out LLVM byte code again? "Again" is right. I don't particularly seek out discussions on this topic, but I've seen this question asked and answered at least half a dozen times before, which is enough for it to start getting annoying.
TazeTSchnitzel 12y ago
> So why did the author throw out LLVM byte code again? It's BSD, it has bytecode compilers for most platforms browsers exist on (100% vs. 50% speed), and doesn't rely on a subset of another language. It also doesn't have the requirement to fall back to vanilla Javascript. As an added bonus, Javascript could easily compile down to LLVM bytecode. LLVM has a single implementation, is very complex, isn't even remotely portable, and is primarily suited to C and C++, or similar languages. We also already have a very performant transformation format for LLVM IR into JS: asm.js. And asm.js fixes most of LLVM IR's problems: * It's very simple * It's portable across architectures * It doesn't have undefined behaviour * It has multiple implementations * It has forwards-compatibility (existing browsers, regardless of explicit support, can run asm.js code) * It is standardised
- rictic 12y ago
  Well put. One nit: I think you mean backwards compatibility, though asm.js can also be expected to work without modification in future browsers and future versions of javascript.
  - TazeTSchnitzel 12y ago
    Yeah, I originally put backwards-compatibility, but I wasn't sure if forwards-compatibility was the right word for allowing old software to use new code.

CyberDildonics 12y ago

I heard about a project called Oak that was supposed to do this, never heard what happened to it...

mmastrac 12y ago
I assume this is a subtle Java joke -- for those who completely missed it: http://en.wikipedia.org/wiki/Oak_%28programming_language%29#Differences_with_Java http://en.wikipedia.org/wiki/Oak_%28programming_language%29#... If we were going with a bytecode, I wouldn't choose LLVM or JVM. Neither is really suited for the task.
deleted 12y ago
[deleted]
DonHopkins 12y ago
It got renamed, then somebody made a backroom deal to borrow the new name for another totally different language in order to trick people into confusing the two languages, then the other language became much more popular and widespread than the one that used to be called Oak, totally taking over the browser, and making good headway at taking over the server too. Incidentally, Arthur van Hoff just pointed out: >Time flies. This week it is 20 years since we announced Java... "Why Sun Thinks Hot Java Will Give You a Lift" - March 23 1995 http://web.archive.org/web/20060819094743/http://java.sun.com/features/1998/05/images/merc_large.gif http://web.archive.org/web/20060819094743/http://java.sun.co...
- arethuza 12y ago
  I blagged a copy of Java from Arthur a while before that when I found out he was working at Sun - I'd used HyperNeWS for quite a while and was in awe of his programming skills. Edit: Are you this DonHopkins? http://art.net/~hopkins/Don/hyperlook/index.html http://art.net/~hopkins/Don/hyperlook/index.html
  - DonHopkins 12y ago
    That's me. While I was working at Sun in '90-91 on NeWS, we tried very hard to convince management to hire him to work on HyperNeWS for TNT, but Sun wouldn't give us a requisition (because they intended to kill NeWS, not save it). So I quit Sun and moved out to Glasgow to work with him at the Turing Institute on HyperLook, and ported SimCity to HyperLook. HyperNeWS aka HyperLook was like HyperCard implemented with PostScript programming and graphics, plus networking. In that alternate universe, PostScript would have been the universal bytecode for the web. https://www.scribd.com/doc/77192884/HyperLook-Product-Info https://www.scribd.com/doc/77192884/HyperLook-Product-Info https://www.scribd.com/doc/77164708/HyperLook-SimCity-Manual https://www.scribd.com/doc/77164708/HyperLook-SimCity-Manual Arthur's programming and entrepreneurial skills are indeed awesome, and I'm glad I quit my day job at Sun and left the country for the opportunity to work with him! He's now an advisor to my current company: http://pantomimecorp.com/the-team http://pantomimecorp.com/the-team

marcosdumay 12y ago

I'd settle for a bytecode that supported numbers (instead of only strings), blocking I/O (in addition to non-blocking), and easy integration with system (or, in this case browser) utilities. Javascript happens to have none.

TazeTSchnitzel 12y ago
Uh, JS has numbers, blocking IO, and easy integration. What are you on about?
- marcosdumay 12y ago
  JS implement numbers as strings (has bitten me once). Last time I looked at, there was no blocking IO at all (there is continuation, but it does not solve the problem because there isn't any locking mechanism - yep, I'd like atomic locking at my bytecode too). That's even the main "selling point" Node.js people throw around as if it was a good thing. By easy integration I mean the hability of using capabilities available at the system, but not exported into the language runtime. It can be solved by something that would let me query the sandbox enviroment for the existence of a "library" that exports foreign functions, and use it. Also, something that by the other side lets me write and distribute one such "library" so people can install them on their browsers let JS use its functionality.
  - jdmichal 12y ago
    > JS implement numbers as strings (has bitten me once). What? JS implements all numbers as 64-bit floating point, which happens to be able to perfectly represent the 32-bit integer space. It can actually perfectly represent a 52-bit integer space. See Number.MAX_SAFE_INTEGER [0] for details. Now, JS does allow for type coercion between values when using the `==` operator. Luckily, the `===` operator also exists which eliminates this effect. [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... > Last time I looked at, there was no blocking IO at all. What does blocking even mean in a single-threaded event-pump context? Does it mean other events can be processed while the IO executes? Because that's exactly what an asynchronous AJAX request does. Or does it mean it blocks the only thread available? Because that's what a synchronous AJAX call does. Now, if your argument is that JS doesn't have an async / await construct in order to make asynchronous AJAX look like synchronous AJAX in the code, then that's in ES7.

rikkus 12y ago

I've pondered this a couple of times. One Ask HN I posted: https://news.ycombinator.com/item?id=6773980 https://news.ycombinator.com/item?id=6773980 A reply to a comment I made on another post says that the CLR and JVM suffer from GC pauses, which would not be acceptable for web apps.

fla 12y ago
GC pauses already occur in most JS engine. They are especially tolerable in a web app.

Rusky 12y ago

The article makes the argument that existing systems are easier to improve incrementally, while designing new systems is more work and not guaranteed to succeed. The problem is JavaScript-as-bytecode is not especially easy to improve. Anything you want to add/change that would make it a better bytecode has to be balanced with the language's use by humans. The solution to one-VM-to-rule-them-all is not to cram everything into a higher-level system with lots of assumptions (JavaScript) or to ignore portability (NaCl, LLVM), but to use a bytecode that's low-level enough to implement the various assumptions needed by higher layers. That way both C++ and JavaScript can run at full speed as well as have their implementations changed (even across websites!) without pushing every change through the browsers- just like native apps, with the browser providing only cross-platform and security, nothing more.

TazeTSchnitzel 12y ago
> The problem is JavaScript-as-bytecode is not especially easy to improve. Anything you want to add/change that would make it a better bytecode has to be balanced with the language's use by humans. There are very few cases where human use causes problems. goto is the only one I can think of. Yet we've gotten loads of great improvements in ES6 to make it a good compiler target, like float32 and better integer multiplication.