11 ms·

If nothing else, it results in a smaller download than minified js. (I believe that's true even today.) And, in theory, it should be able to run a bit faster al

If nothing else, it results in a smaller download than minified js. (I believe that's true even today.) And, in theory, it should be able to run a bit faster also. Not sure if that one's true yet. Update: Here's a quote from the Microsoft announcement: "Despite being an early implementation, the demo starts-up significantly faster than just using asm.js as the WebAssembly binaries have a smaller file size and parse more quickly than plain JavaScript that needs to be parsed in the asm.js case." https://blogs.windows.com/msedgedev/2016/03/15/previewing-webassembly-experiments/ https://blogs.windows.com/msedgedev/2016/03/15/previewing-we...

xigency 11y ago
Yes, it would be faster.
- AgentME 11y ago
  Why would bundling a Javascript engine in a webpage be faster? I guess it's likely if someone were to make an improved Javascript engine, but their effort would be better spent improving the Javascript engines in browsers (affecting all webpages) rather than bundling it as a many-megabyte download into their own webpages.
  - xigency 11y ago
    It really depends on the code. This whole topic is for webpages with scripting that have reached performance bottlenecks, not just an obscure exercise in torture.
  - geon 11y ago
    DonHopkins pointed out that wasm will eventually support serialization of arbitrary js. So you wouldn't need to include the js runtime at all, but still get a much quicker download and parsing. https://news.ycombinator.com/item?id=11291997 https://news.ycombinator.com/item?id=11291997
jhpriestley 11y ago
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.
      - 11y ago

xigency 11y ago

Yes, it would be faster.

AgentME 11y ago
Why would bundling a Javascript engine in a webpage be faster? I guess it's likely if someone were to make an improved Javascript engine, but their effort would be better spent improving the Javascript engines in browsers (affecting all webpages) rather than bundling it as a many-megabyte download into their own webpages.
- xigency 11y ago
  It really depends on the code. This whole topic is for webpages with scripting that have reached performance bottlenecks, not just an obscure exercise in torture.
- geon 11y ago
  DonHopkins pointed out that wasm will eventually support serialization of arbitrary js. So you wouldn't need to include the js runtime at all, but still get a much quicker download and parsing. https://news.ycombinator.com/item?id=11291997 https://news.ycombinator.com/item?id=11291997

jhpriestley 11y ago

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.
    - 11y ago