Why would you want to run a server-side wasm/js generated code from rust?
I don’t know if you’re aware of Askama, my templating crate, but I would be very interested in collaborating to make Yew work well with Askama. I’ve been thinking about doing something with isometric-Rust-functional-reactive web programming through WASM for a while now, so it looks like Yew could be one of the building blocks for that.
It will be a exciting news for rustaceans.
Thanks for this @DenisKolodin! I am only a few weeks into Rust, but have made my way through the book and made a couple of small CLIs. Having a more web dev background I am interested in potential Rust web frameworks.
I cloned Gotham’s example app yesterday over Rocket, purely because it was async and built on stable rust. Unfortunately, it couldn’t compile due to an existing issue on the repo. I installed emscripten and followed your instructions and had a look through the examples which were great
I was wondering though: What would you say are pros and cons about YEW over Gotham and Rocket?
Apologies for that, this was corrected by https://github.com/gotham-rs/example-app/pull/9.
No problem at all. Thanks for Gotham! Looking forward to using it!
Hi, Rustaceans! Thank you everyone for the friendly reviews! Some holiday benchmarks I promised to do. Firefox 57.0.1 (64-bit) + target
wasm32-unknown-unknown. I can’t believe the results, ! I never even optimized the Virtual DOM engine. Maybe my benchmarks are completely wrong?! Source: https://github.com/DenisKolodin/todomvc-perf-comparison
The benchmarks are relatively old (3 years). For example, ember 1.x is used in the benchmarks. Current stable release is Ember 2.18. An update would be useful.
Like mschorsch said, those benchmarks are super super out of date: they don’t even include Inferno: https://github.com/infernojs/inferno
Here is a more up-to-date benchmark:
It would be great to see how Yew performs on that benchmark.
Why is it only over one run instead of over 10 like in the parent benchmark? Also, why is Mithril just blank?
This is awesome! @DenisKolodin I’d love to hear a little more about where you see this going and what the roadmap looks like. Very excited to see the potential of Web Assembly for enabling rust-based web applications coming to actual fruition!
Markup + helper = component = idiomatic for the “react” style client-side SPA.
It’s currently the rage for SSR due to node.js “there’s nothing about window, let’s try running it in node. oh hey, it compiled!”
Otherwise, you have:
- traditional server-rendered logic-less (or minimal logic) templating, a la jade, moustache, handlebars, erb…
- server language macro “templates” that compile to that same language for “separating” the concerns as you prefer
- a client-side SPA that loads at “/” url and xhr or websockets other paths or query-string-paths or whatever flavor of the day is fun/trendy/useful to post data and get data (and delete update patch rest whatever…)
- some combination of the above repackaged as SSR + SPA
- some combination of the above with server-side routing and a client-side vdom that updates data and re-renders as appropriate.
6)? whatever I forgot or am ignorant of due to being old/young/human.
This crate/framework (YEW) is filling in a missing link (previously stdweb and it’s predecessor i forgot the name of) in terms of Rust that compiles to a client-side target (previously asm.js now webasm!)
This will enable numbers 3,4,5 and 6 above.
It’s pretty useful and significant, because it allows a singular application to control behavior from the database to inside the clients browser, via a 2-compilation-target approach and the deployment mechanism know as a webserver
Great stuff, @DenisKolodin !
I’d be interested in examples of how to integrate this with any of the popular server frameworks (or did I miss that and it was already posted?) like iron, nickle, rocket, gotham…
(or do you strictly imagine using server frameworks to deploy YEW clients and afterwards used as a JSON API as @dylan.dpc mentioned ?)