TodoMVC in Rust
tcr.github.io
tcr.github.io
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()?
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. .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 */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'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.
$ 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.
It's going to improve rapidly though.
Progress is being made on making this first class though: https://github.com/rust-lang/rfcs/issues/604
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).
The code can be optimized further with Closure Compiler, but I wonder if that decreases startup speed.