I appreciate it's to demo the capacity to compile Rust to js, but that's some really nasty code.

https://github.com/tcr/rust-todomvc/blob/master/src/main.rs

Why put it all in the main? Why define functions as variables? Why .parent().unwrap().parent().unwrap()?

It is nasty code! I started refactoring before I hit some struct-alignment bugs (fixed on later Rust versions): https://github.com/tcr/rust-todomvc/blob/tcr-wip/src/main.rs

The parent navigation needs to be replaced by a jQuery-like .ancestors() macro.

This was an MVP so I wasn't focused on code quality over features; but I'm also learning Rust for the first time, so it came out less than impressive :)

  > Why define functions as variables?

I'm not sure what you mean here, exactly.

  > Why .parent().unwrap().parent().unwrap()?

I'm not mega familiar with the code, but using a low-level binding to something else that has nulls often means a lot of Option, which means a lot of unwrapping. A nicer library could probably get rid of some of this.

>which means a lot of unwrapping

     .unwrap()

In rust is generally a bad pattern to use. Its basically short hand for

    let o :Option< u64 >;

    let value :u64 = match o {
                        Some( t ) => t,
                        None => panic!()
                     };

So if you don't met the condition, you explode. When ever you see .unwrap() in Rust just mentally switch it for /TODO add error handling */

Yeah, I was just using "unwrapping" as a more general term for "extract the T out."

We almost changed 'unwrap' to 'assert', but people found it a bit too weird.

>We almost changed 'unwrap' to 'assert', but people found it a bit too weird.

That is weird. idk I guess its already sort of being done, you're more or less asserting Option::Some( _ ) is the value.

I wonder if it would looks a bit nicer with .jsx support.

I can't wait for a JSX crate on Cargo.

Would be cool if there was some small web framework you could use so you could avoid having your state in RC(RefCell)'s. Perhaps it's the Haskell guy in me but I always try to make my code have zero RC or even RefCells. I'm also a complete rust noobie, so perhaps that's not good practice at all :)

I'd love to refactor this to not need RC's for DOM nodes. I'm new to Rust, but I expect there's a ton of room for refactoring.

What's the development process like for a Rust-in-the-browser project like this? I mean, is it like; write some Rust - manually start a compile process - wait a while - view result in browser - repeat? Are there nice tools? :)

I'm used to working with raw JavaScript, ClojureScript with Figwheel, and Java/xhtml with JSF. Of the three, ClojureScript/Figwheel has given me the smoothest process so far, though I know there are tools for autoreloading raw js as well, just haven't gotten around to using them.

The general workflow with Rust is

    $ git clone <foo>
    $ cd <foo>
    $ cargo run

With something like this, you might want to also use https://github.com/passcod/cargo-watch , which, after installing it, changes that last line to

    $ cargo watch

and then it will recompile when you change a file, automatically.

I haven't been able to test that this project works exactly this way because it looks like they're on an older nightly than I have on my machine, but it looks like that's all you need.

I will be amazed if true! Last time I looked at the emscripten-Rust stack it was a tower of hacks and required a custom-hacked standard library. If that's all abstracted behind cargo build scripts that's awesome, but we're still a ways from having this be elegantly integrated into the Rust system.

It's going to improve rapidly though.

I think it's gotten better due to recent LLVM changes in emscripten, last I heard, but maybe maybe not. Can't wait until it's just trivial.

This uses a deeply hacked Rust stack. Take a look at this: https://github.com/tcr/rust-webplatform/blob/master/setup.sh It's also using a version of Rust that's pre-1.0.0.

Progress is being made on making this first class though: https://github.com/rust-lang/rfcs/issues/604

For something compiled with Emscripten, this was stupid quick to startup. Wow.

I had to check and the generated .js file is 248kByte compressed, 787kByte uncompressed. That's in the same ballpark as a comparable C++ demo, looking at the code it is even a bit big (e.g. my emscripten demos here are between 100kByte and 500kbyte: http://floooh.github.io/oryol/).

There is some inherent size overhead because the linked parts of the C runtime library and C++ std lib are part of the emscripten-generated JS (std::iostream and printf seem to be the biggest offenders on the C++ and C side) while on some native platforms this code lives in DLLs, but gzipped asm.js code itself isn't bigger than its gzipped 'native equivalent' (usually within +/- 10%).

It is easy to created bloated code with emscripten, especially when using C++ instead of C, but for the same reasons the code would also be bloated as native executable (e.g. massive use of template and inline code).

I was impressed too. I think the key is that it injects all of the HTML at once. Compare that to e.g. the Backbone.js implementation which uses progressive enhancement: http://todomvc.com/examples/backbone/

The code can be optimized further with Closure Compiler, but I wonder if that decreases startup speed.

Nice. Maybe that can be one good use case for the use of rust. Using it in place of C++ for Emscripten. I wonder what are the other languages supported.

Where's the code?

Looks fast.