Issue by brson
_Wednesday Apr 18, 2012 at 20:44 GMT_
_For earlier discussion, see https://github.com/rust-lang/rust/issues/2235_
_This issue was labelled with: A-an-interesting-project, A-build, A-runtime, E-hard, I-wishlist in the Rust repository_
I've spent some time poking at this problem and rustc now generates code that emscripten can translate, but the compiled javascript fails when it hits a runtime function. The next step is to start building the runtime using emcc as the compiler. Stub out all the things that don't build behind EMSCRIPTEN ifdefs.
Emscripten is adding a way to treat inline assembly as javascript, so all the parts of the runtime that don't build with emscripten can be implemented inline with javascript.
Alternately, we could reimplement the runtime piecemeal in javascript and not bother compiling it from C++ at all. This approach isn't recommended.
Looks kinda-working with a bit of hackery - http://www.reddit.com/r/rust/comments/2ylzkx/a_game_written_with_piston_running_on_the_web_via/
This feature looks very promising. I wonder, is the expecting performance going to be better than with native (handwritten) Javascript?
@antonkulaga it should perform much better in a browser that supports asm.js - tests show asm.js is within about a factor of 2 of native performance.
it's not working any more: https://github.com/AerialX/cargo-build/issues/2
@t128 The next step is basically https://github.com/rust-lang/rust/pull/26505
@tomaka rust-lang/rust#26505 is closed. So how good are chances to see a working Rust -> JavaScript transpiler? Has anyone made progress?
This is not exactly a Rust -> JavaScript transpiler, but there is bilalhusain/dust, which is a language which is very similar to Rust (but as it's JS, it doesn't have all the fancy memory mangement of rust, it uses a gc). I'm not sure if that's relevant.
Also why make a transpiler, instead of getting it to work with emscripten?
@bennyn The previous PR has been closed in favor of https://github.com/rust-lang/rust/pull/28355
To give a summary (hopefully I don't say anything wrong):
After these two PRs we probably need to tweak the lists of build targets, then compiling a program with #![no_std] should probably work.
Then the stdlib probably needs some tweaks, although in don't know at which degree.
Just wanted to give a notice here: with WebAssembly being implemented as a pure LLVM backend in the future, compiling from Rust to WebAssembly should prove ridiculously easy, and as WebAssembly has JS polyfills, running it in browsers will be easy too.
@tomaka I have other inbound PRs that address all of those issues. Plus this PR: https://github.com/rust-lang/rust/pull/27937 . Also don't forget about the work I still have to do in pnacl-llvm.
This branch by @brson is a work in progress that adds support for emscripten to rustc.
I tried it and it works great for the moment (I managed to run glium's teapot example with WebGL with some changes in the stdlib and in glutin and glium), although @brson said that things weren't getting compiled properly in release mode (I didn't try release mode).
Hope I'm not adding too much noise; could anyone tell me the current status of this issue?
I don't know enough to implement it myself, but have been eagerly following all PRs hoping I might one day find a set of commands that lets me compile a Rust program, with or without stdlib, to JS :)
What's currently still needed to bring emscripten support into the nightly builds? I'm having a hard time getting an overview of what the current blocking issues are for this.
@LaylConway
Other than that, most of the critical bugs have been fixed already and the rest of the fixes are in https://github.com/rust-lang/rust/pull/31623.
This is done.
Most helpful comment
@LaylConway
Other than that, most of the critical bugs have been fixed already and the rest of the fixes are in https://github.com/rust-lang/rust/pull/31623.