
TodoMVC in Rust - dumindunuwan
http://tcr.github.io/rust-todomvc/
======
mattmanser
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](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()?

~~~
steveklabnik

      > 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.

~~~
valarauca1
>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_ */

~~~
steveklabnik
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.

~~~
valarauca1
>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.

------
tinco
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 :)

~~~
timcameronryan
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.

------
Reefersleep
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.

~~~
steveklabnik
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](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.

~~~
brson
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.

~~~
steveklabnik
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.

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

~~~
flohofwoe
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/](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).

------
aikah
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.

------
xiaoma
Where's the code?

~~~
the_mitsuhiko
[https://github.com/tcr/rust-todomvc](https://github.com/tcr/rust-todomvc)

------
mtgx
Looks fast.

