4 ms·

All of those things you mentioned are currently being worked on and will be added to JavaScript directly.

by Touche 13y ago

modeless 13y ago
What's the solution being worked on for code size?
- azakai 13y ago
  Code size currently is avoid equivalent to native builds, if you gzip both of them. The emitted code is basically similar to a native build except it's in text format (so the difference mostly vanishes after gzip). You mentioned things like templates in C++ - those will be an issue in asm.js just as they are in a native build, no more and no less.
  - modeless 13y ago
    My experience has been that emscripten builds are significantly larger than native even after gzip. Templates are of course an issue in native builds too, but native builds are usually less size-constrained than web apps. Sending (minimized) Rust source code, as we do with JavaScript, would result in significantly smaller downloads (and less code to compile) vs. asm.js. Also shipping a standard library with the browser (as JS does) would be another significant reduction.
    - azakai 13y ago
      I would be curious to see your code, if that's possible - perhaps we can optimize things better or you are hitting a bug. How much larger was it, after gzip? I'm not sure you'd want to send Rust source code - you'd need to wait for it to compile on the other side. (Rust is designed for many things, but fast compilation is not a primary goal.) Most likely you'd want to build it ahead of time on the server, just like C++, but then I'm not sure there would be a size advantage to Rust.
      - modeless 13y ago
        It seems to me like making a fast Rust compiler would be an easier problem than making JavaScript run native code fast :) Thanks for the offer of help. Unfortunately I can't send our code, but I just talked to our guy working on emscripten and he said he's already been in touch (though not about code size yet). https://groups.google.com/d/msg/emscripten-discuss/n1qfKPPAy08/a5LJliGPDPQJ https://groups.google.com/d/msg/emscripten-discuss/n1qfKPPAy... My impression of emscripten code size might be out of date, I know that development on asm.js has been pretty rapid.
        emn13 13y ago
        It's not just a question of engineering resources; some problems are intrinsically hard. There may well be things (like floats in css) in rust that make fast compilation hard if not impossible - depending on what exactly you want to achieve. After all, the point is to generate efficient code, so a solution that simply disregards most optimizations isn't an option; and most of the type system is likely unavoidable and/or critical to the optimizer. By contrast, asm.js is fairly simple: All the heavy lifting of compiling has mostly been done - the remaining JS was chosen so that it fairly straightforwardly represents assembler instructions. Decisions about types and what that means for semantics (and safety) have been done, inlining, code rearranging etc. - that's all largely done. In a way, asm.js is assembler with a weird syntax and environment. I really doubt you'd ever get something like Rust (or really most any other statically compiled language) to ever compile as fast, given comparable resources.
coldtea 13y ago
"Coming in a browser near you in another 5-6 years"... I've followed Harmony / ES6 for like 7 years now. Don't hold your breath. (And I know that you can get lots of these features with special switches in Chrome, FF etc. Also know about Traceur. I mean don't hold your breath about having it released and available all-around for real web work, frameworks updated for it, etc).
- lomnakkus 13y ago
  On Traceur: We're currently using a subset[1] of Traceur for out frontend coding and I can't say I've noticed any particular problems doing so. I also don't see any problem if libraries we were using would change to using Traceur, so long as they were to distribute the compiled output. Yes, we'd have to include the Traceur runtime, but we already do, so... (There could be versioning issues, but I suspect that the Traceur runtime is relatively static and so could remain "compatible enough" across versions. One could also easily imagine JS libraries built on Traceur distributing both the original ES6 source and the transpiled JS.) [1] The caveat here is that we have to support IE8 (for now at least) which the Traceur runtime doesn't support, so there are a few features we cannot use (yet).
  - cpeterso 13y ago
    Does Traceur always polyfill ES6 features, even if the browser supports them natively?
    - lomnakkus 13y ago
      Of course pure source transformations (classes, let, const, splats and such) just yield ES5 source directly, and so you lose native browser support for those. That's no big deal since most browsers really aren't really up to scratch yet in ES6 support. I'm not sure about the runtime, but I think I remember it doing some (very basic) feature detection while browsing through the generated code during a debugging session. EDIT: Frankly, I think it would probably be a good idea to polyfill all browsers until they all really implement the ES6 spec.

All of those things you mentioned are currently being worked on and will be added to JavaScript directly.

by Touche 13y ago

All of those things you mentioned are currently being worked on and will be added to JavaScript directly.

modeless 13y ago

What's the solution being worked on for code size?

azakai 13y ago
Code size currently is avoid equivalent to native builds, if you gzip both of them. The emitted code is basically similar to a native build except it's in text format (so the difference mostly vanishes after gzip). You mentioned things like templates in C++ - those will be an issue in asm.js just as they are in a native build, no more and no less.
- modeless 13y ago
  My experience has been that emscripten builds are significantly larger than native even after gzip. Templates are of course an issue in native builds too, but native builds are usually less size-constrained than web apps. Sending (minimized) Rust source code, as we do with JavaScript, would result in significantly smaller downloads (and less code to compile) vs. asm.js. Also shipping a standard library with the browser (as JS does) would be another significant reduction.
  - azakai 13y ago
    I would be curious to see your code, if that's possible - perhaps we can optimize things better or you are hitting a bug. How much larger was it, after gzip? I'm not sure you'd want to send Rust source code - you'd need to wait for it to compile on the other side. (Rust is designed for many things, but fast compilation is not a primary goal.) Most likely you'd want to build it ahead of time on the server, just like C++, but then I'm not sure there would be a size advantage to Rust.
    - modeless 13y ago
      It seems to me like making a fast Rust compiler would be an easier problem than making JavaScript run native code fast :) Thanks for the offer of help. Unfortunately I can't send our code, but I just talked to our guy working on emscripten and he said he's already been in touch (though not about code size yet). https://groups.google.com/d/msg/emscripten-discuss/n1qfKPPAy08/a5LJliGPDPQJ https://groups.google.com/d/msg/emscripten-discuss/n1qfKPPAy... My impression of emscripten code size might be out of date, I know that development on asm.js has been pretty rapid.
      - emn13 13y ago
        It's not just a question of engineering resources; some problems are intrinsically hard. There may well be things (like floats in css) in rust that make fast compilation hard if not impossible - depending on what exactly you want to achieve. After all, the point is to generate efficient code, so a solution that simply disregards most optimizations isn't an option; and most of the type system is likely unavoidable and/or critical to the optimizer. By contrast, asm.js is fairly simple: All the heavy lifting of compiling has mostly been done - the remaining JS was chosen so that it fairly straightforwardly represents assembler instructions. Decisions about types and what that means for semantics (and safety) have been done, inlining, code rearranging etc. - that's all largely done. In a way, asm.js is assembler with a weird syntax and environment. I really doubt you'd ever get something like Rust (or really most any other statically compiled language) to ever compile as fast, given comparable resources.

coldtea 13y ago

"Coming in a browser near you in another 5-6 years"... I've followed Harmony / ES6 for like 7 years now. Don't hold your breath. (And I know that you can get lots of these features with special switches in Chrome, FF etc. Also know about Traceur. I mean don't hold your breath about having it released and available all-around for real web work, frameworks updated for it, etc).

lomnakkus 13y ago
On Traceur: We're currently using a subset[1] of Traceur for out frontend coding and I can't say I've noticed any particular problems doing so. I also don't see any problem if libraries we were using would change to using Traceur, so long as they were to distribute the compiled output. Yes, we'd have to include the Traceur runtime, but we already do, so... (There could be versioning issues, but I suspect that the Traceur runtime is relatively static and so could remain "compatible enough" across versions. One could also easily imagine JS libraries built on Traceur distributing both the original ES6 source and the transpiled JS.) [1] The caveat here is that we have to support IE8 (for now at least) which the Traceur runtime doesn't support, so there are a few features we cannot use (yet).
- cpeterso 13y ago
  Does Traceur always polyfill ES6 features, even if the browser supports them natively?
  - lomnakkus 13y ago
    Of course pure source transformations (classes, let, const, splats and such) just yield ES5 source directly, and so you lose native browser support for those. That's no big deal since most browsers really aren't really up to scratch yet in ES6 support. I'm not sure about the runtime, but I think I remember it doing some (very basic) feature detection while browsing through the generated code during a debugging session. EDIT: Frankly, I think it would probably be a good idea to polyfill all browsers until they all really implement the ES6 spec.