Web developers may be also interested in <a href="https://gotham.rs/" rel="nofollow">https://gotham.rs/</a>, which was released very recently and looks to be a promising competitor to Rocket.
Man Rust is super hard already! I mean people told me it would be harder to think functionally but after clojure, i think lisps are super easy. But i feel Rust is way harder than anything. Infact i feel Haskell is comparatively easier than Rust. So i am not sure why one wants to use it for web. I think Rust has a place and that is to replace C++ for system software, possibly even C for writing Kernels because why not? But definitely not for web. Go is probably the right choice for that sort of performance scenario in the backend. But for frontend neither Go or Rust are good simply because of the huge size of the runtimes. Clojure-script comparatively has a smaller runtime than either Go or Rust runtimes compiled to JS.
I built <a href="https://dtmf.io/" rel="nofollow">https://dtmf.io/</a> using Rust. The first prototype was using the Iron framework but then after fighting some parts of Iron, I pared it back to just using async hyper & handlebars-rs directly for the HTTP and templating. The glue to put them together is really minimal. Overall, I've been really impressed with Rust.
Nice overview, it might be worth mentioning that Emscripten isn't a tier 1 platform[1]. We've seen some asserts thrown in LLVM when building debug but go away when build release.<p>I've been trying to isolate it down to a reproducible sample but haven't nailed down exactly what's causing it yet.<p>Even with that issue it's been great to work with. I find myself so much more productive with Rust compared to C/C++.<p>[1] <a href="https://forge.rust-lang.org/platform-support.html" rel="nofollow">https://forge.rust-lang.org/platform-support.html</a>
> NamedFile::open(Path::new("www/").join(file)).ok()<p>Is this vulnerable to the classic "../../../../../../../etc/passwd"?
Just a small nitpick, but #3 is not actually an isomorphic app, it's just a regular server-rendered one. Isomorphic typically means that the app is rendered in the same way (e.g. via React) on both the frontend and backend, and the frontend degrades gracefully when JS isn't enabled.<p>More on-topic: I just recently started a new web app using Rust on the backend. Though there is definitely a lot still missing, it's amazing how far the language and its ecosystem have come in the past year or so. I expect that within a couple years, Rust will be a viable alternative to Python and Ruby for backend web development.
It's cool that you can do this, but it's probably not something you want to do unless you have an unusual application. A reasonable application might be a heavily used API at the HTTP level, where the web-facing part is really a subroutine call interface, performance may be a big issue, and safety against bad parameters is a big issue.
You are cool, and it's all is amazing work. I bet it was very interesting to implement. But reading comments I think people don't understand that it's just demonstration of how much Rust evolved, not a tutorial of what they should do to use Rust for the Web. Kind of overkill :)
The 'Client-sode JS in Rust' part is a promising showcase for WebAssembly and I hope to see more languages compiling to WebAssembly soon. But looking closer at the code which does not a lot compared to its size I rather prefer the JS version.
This makes no mention of the size of these applications. Given the recent focus on shipping less JavaScript to the browser to better support mobile and slow networks, I wonder how feasible this project even is?
This is all good and dandy but I don't like the webpage font-color! Can we have more of black on black so that it's even more modern and minimal? Or white-on-white which is more of a trend these days?