YEW - a framework for client-side web-apps

#21

You can already do that with the multitude of template rendering: rustache, tera, handlebars, sptl.

Why would you want to run a server-side wasm/js generated code from rust?

#22

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.

#23

It will be a exciting news for rustaceans.

#24

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 :slight_smile:

I was wondering though: What would you say are pros and cons about YEW over Gotham and Rocket?

#25

Apologies for that, this was corrected by https://github.com/gotham-rs/example-app/pull/9.

#26

No problem at all. Thanks for Gotham! Looking forward to using it!

#27

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, :santa:! I never even optimized the Virtual DOM engine. Maybe my benchmarks are completely wrong?! Source: https://github.com/DenisKolodin/todomvc-perf-comparison

0-benchmark

#28

Looks impressive!

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.

#29

Fantastic! I’m not surprised though, Rust is quite a bit faster than JavaScript.

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:

http://stefankrause.net/js-frameworks-benchmark4/webdriver-ts/table.html

It would be great to see how Yew performs on that benchmark.

#30

Why is it only over one run instead of over 10 like in the parent benchmark? Also, why is Mithril just blank?

#31

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!

#32

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:

  1. traditional server-rendered logic-less (or minimal logic) templating, a la jade, moustache, handlebars, erb…
  2. server language macro “templates” that compile to that same language for “separating” the concerns as you prefer
  3. 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…)
  4. some combination of the above repackaged as SSR + SPA
  5. 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 the stuff that one cannot compel purely from the server side that is the target. Previously one had only Javascript or other (non-Rust) things that compiled to Javascript or webasm to do vdom rendering, xhr requests fetch websockets etc, data and/or state updates, form validation and posting without triggering a page load…

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 :smiley:

#33

Great stuff, @DenisKolodin !
Thank you.

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 ?)

#34

Any real-life projects using it in production?

#35

I feel it is too early for that