7 ms·

You are misunderstanding. A C++ application compiled to wasm is smaller than a C++ application compiled to a subset of javascript. A javascript application com

You are misunderstanding. A C++ application compiled to wasm is smaller than a C++ application compiled to a subset of javascript. A javascript application compiled to wasm doesn't really make sense. Javascript isn't a compiled language. The best you could do would be to store some kind of compressed representation of the source code, along with a JIT compiler to run that source code. It isn't a sensible thing to do.

xigency 11y ago
Sure it does. Do you know that Lisp and Scheme have compilers? They target assembly even as dynamic languages, like JavaScript. These are totally sensible. Look at: http://www.call-cc.org/ http://www.call-cc.org/
- RussianCow 11y ago
  But the point is, if you want to compile your JavaScript code ahead of time, you have to ship your own GC and JIT compiler, because you no longer get it "for free" from the browser's JS implementation. There's absolutely no benefit from doing this.
  - geon 11y ago
    That will soon not be true. Exposing the js gc is on the roadmap. ...which will also make it feasible to use other gc:ed languages without shipping an enormous runtime.
    - tanlermin 11y ago
      But they will still need to be interpreted ie cpython. I'm not sure how much space just cutting out the GC will save?
    - esailija 11y ago
      GC is only a small part of a high level language runtime.
    - RussianCow 11y ago
      Okay, but why would you compile JS down to wasm, only to have it then use the browser's built-in JS runtime? I see the use for compiling other dynamic languages, but compiling JS via wasm shouldn't be any different than running it via the normal JS engine, aside from potentially having a slightly smaller executable.
bpicolo 11y ago
> Javascript isn't a compiled language I mean, it is if you compile it to wasm. It is definitely JIT compiled.
- Touche 11y ago
  Then you have to ship your own GC with it.
  - xigency 11y ago
    My initial reaction was for software with a flat memory footprint, so it really doesn't require garbage collection. Our application could be written in C, if we weren't web developers who are working in JavaScript. No one wants to do web development in C++ honestly, but they would like the performance.
    - tracker1 11y ago
      I could see this functioning really well with webworker once some sort of thread-safe representation is in place for quickly moving objects in/out of said worker... Would be a pretty clean separation of WebAssembly code, and the DOM accessible code by convention... even if sticking to object serialization (JSON), it would be pretty clean... With IE9 support slipping, it seems to be a no-brainer in terms of support at this point too [1]. I'm also thinking this could be a huge win once it hits node.js (v6?), as this could be a great answer to better binary module support. As binary modules are a bit of a pain to support, and prebuilt binary modules are in a hodge-podge state. [1] http://caniuse.com/#feat=webworkers http://caniuse.com/#feat=webworkers
  - cstrahan 11y ago
    I think you misunderstand what WebAssembly is about. As I understand it, it's little more than a binary serialization of JavaScript ASTs. In which case, no, you don't need to ship your own GC with it. I mean, you could always write a JavaScript interpreter in JavaScript, and then compile that into WASM, in which case, yes, you'd ship your own GC. I don't see why you would feel the need to do that for real world applications, though.
stcredzero 11y ago
A javascript application compiled to wasm doesn't really make sense. Javascript isn't a compiled language. This compiled/interpreted distinction has gotten quite fuzzy, and it has been for decades now. Smalltalk was always a compiled language with really late binding. It did compile to a bytecode which was interpreted at first, but that became JIT compiled in all but one commercial VM. This all happened over a decade ago. Also, there is clearly a subset of Javascript programs that could be usefully compiled down to a small, fast, compact machine language program.
- deleted 11y ago
  [deleted]
- geon 11y ago
  > there is clearly a subset of Javascript I suppose the extra restrictions of Typescript would help. At least if you add extra restrictions to make it easier to compile.
DonHopkins 11y ago
Once WebAssembly supports all the features of JavaScript, which is on the roadmap (step 3, "everything else" [1]), it'll be a very sensible thing to do, especially for mobile. Compiling JavaScript text source code into a binary representation of its AST will save time and space downloading, and time starting up. You won't need another JIT compiler, the web browser usually already has one. WebAssembly is bytecode and JIT agnostic. Compiling text JavaScript into a binary WebAssembly representation of the parse tree is different than compiling the parse tree to bytecode, or JITting the parse tree or bytecode to machine code. They are complementary layers, and both synergistically useful together. [1] http://bytecrafter.blogspot.nl/2015/06/a-quick-overview-of-what-webassembly-is.html http://bytecrafter.blogspot.nl/2015/06/a-quick-overview-of-w...
- twistedpair 11y ago
  I can only imagine the possible security exploits available by passing AST binaries directly to the browser, rather than letting the JS lexer/tokenizer and compiler enforce language rules from the source.
  - jfbastien 11y ago
    The wasm AST is also a language, and a very simple one at that. Much easier to test and fuzz than all-out JS.
  - robbrown451 11y ago
    Luckily, the designers of WebAssembly imagined those things before you.
    - lisivka 11y ago
      That's true of version 1, but supporting arbitrary JavaScript is on the roadmap.
PuercoPop 11y ago
Nitpick: What doesn't make sense is 'compiled language'. The term is non-sensical. Languages are not interpreted or compiled, implementations are (sometimes both like cpython). As a counter example, cl-javascript[0] compiles javascript to common Lisp [0]: http://marijnhaverbeke.nl/cl-javascript/ http://marijnhaverbeke.nl/cl-javascript/

xigency 11y ago

Sure it does. Do you know that Lisp and Scheme have compilers? They target assembly even as dynamic languages, like JavaScript. These are totally sensible. Look at: http://www.call-cc.org/ http://www.call-cc.org/

RussianCow 11y ago
But the point is, if you want to compile your JavaScript code ahead of time, you have to ship your own GC and JIT compiler, because you no longer get it "for free" from the browser's JS implementation. There's absolutely no benefit from doing this.
- geon 11y ago
  That will soon not be true. Exposing the js gc is on the roadmap. ...which will also make it feasible to use other gc:ed languages without shipping an enormous runtime.
  - tanlermin 11y ago
    But they will still need to be interpreted ie cpython. I'm not sure how much space just cutting out the GC will save?
  - esailija 11y ago
    GC is only a small part of a high level language runtime.
  - RussianCow 11y ago
    Okay, but why would you compile JS down to wasm, only to have it then use the browser's built-in JS runtime? I see the use for compiling other dynamic languages, but compiling JS via wasm shouldn't be any different than running it via the normal JS engine, aside from potentially having a slightly smaller executable.

bpicolo 11y ago

> Javascript isn't a compiled language I mean, it is if you compile it to wasm. It is definitely JIT compiled.

Touche 11y ago
Then you have to ship your own GC with it.
- xigency 11y ago
  My initial reaction was for software with a flat memory footprint, so it really doesn't require garbage collection. Our application could be written in C, if we weren't web developers who are working in JavaScript. No one wants to do web development in C++ honestly, but they would like the performance.
  - tracker1 11y ago
    I could see this functioning really well with webworker once some sort of thread-safe representation is in place for quickly moving objects in/out of said worker... Would be a pretty clean separation of WebAssembly code, and the DOM accessible code by convention... even if sticking to object serialization (JSON), it would be pretty clean... With IE9 support slipping, it seems to be a no-brainer in terms of support at this point too [1]. I'm also thinking this could be a huge win once it hits node.js (v6?), as this could be a great answer to better binary module support. As binary modules are a bit of a pain to support, and prebuilt binary modules are in a hodge-podge state. [1] http://caniuse.com/#feat=webworkers http://caniuse.com/#feat=webworkers
- cstrahan 11y ago
  I think you misunderstand what WebAssembly is about. As I understand it, it's little more than a binary serialization of JavaScript ASTs. In which case, no, you don't need to ship your own GC with it. I mean, you could always write a JavaScript interpreter in JavaScript, and then compile that into WASM, in which case, yes, you'd ship your own GC. I don't see why you would feel the need to do that for real world applications, though.

stcredzero 11y ago

A javascript application compiled to wasm doesn't really make sense. Javascript isn't a compiled language. This compiled/interpreted distinction has gotten quite fuzzy, and it has been for decades now. Smalltalk was always a compiled language with really late binding. It did compile to a bytecode which was interpreted at first, but that became JIT compiled in all but one commercial VM. This all happened over a decade ago. Also, there is clearly a subset of Javascript programs that could be usefully compiled down to a small, fast, compact machine language program.

deleted 11y ago
[deleted]
geon 11y ago
> there is clearly a subset of Javascript I suppose the extra restrictions of Typescript would help. At least if you add extra restrictions to make it easier to compile.

DonHopkins 11y ago

Once WebAssembly supports all the features of JavaScript, which is on the roadmap (step 3, "everything else" [1]), it'll be a very sensible thing to do, especially for mobile. Compiling JavaScript text source code into a binary representation of its AST will save time and space downloading, and time starting up. You won't need another JIT compiler, the web browser usually already has one. WebAssembly is bytecode and JIT agnostic. Compiling text JavaScript into a binary WebAssembly representation of the parse tree is different than compiling the parse tree to bytecode, or JITting the parse tree or bytecode to machine code. They are complementary layers, and both synergistically useful together. [1] http://bytecrafter.blogspot.nl/2015/06/a-quick-overview-of-what-webassembly-is.html http://bytecrafter.blogspot.nl/2015/06/a-quick-overview-of-w...

twistedpair 11y ago
I can only imagine the possible security exploits available by passing AST binaries directly to the browser, rather than letting the JS lexer/tokenizer and compiler enforce language rules from the source.
- jfbastien 11y ago
  The wasm AST is also a language, and a very simple one at that. Much easier to test and fuzz than all-out JS.
- robbrown451 11y ago
  Luckily, the designers of WebAssembly imagined those things before you.
  - lisivka 11y ago
    That's true of version 1, but supporting arbitrary JavaScript is on the roadmap.

PuercoPop 11y ago

Nitpick: What doesn't make sense is 'compiled language'. The term is non-sensical. Languages are not interpreted or compiled, implementations are (sometimes both like cpython). As a counter example, cl-javascript[0] compiles javascript to common Lisp [0]: http://marijnhaverbeke.nl/cl-javascript/ http://marijnhaverbeke.nl/cl-javascript/