Bind components to the DOM. Quasar keeps your views up-to-date when you mutate component (or application) state.
Your component types are propogated into events. Never null. Never undefined. Never TypeError. No need to check to see if it quacks like a duck.
Bring your own templating engine. Quasar has an out-of-the-box default, but it is trivial to swap for your own templating engine.
This page is powered by Quasar (see how) and compiled to ASM.js. See also the WASM variant (coming soon).
The examples on this site were built for each of these engines. Toggle between engines to see how they differ.
...and supporting your preferred templating engine is probably trivial.
Accessing data makes your component an observer of that data. Modifying data causes its observers to be rerendered. This is all enforced by Rust's type system.
(And yes, you can undermine these behaviors by using interior mutability)
The same rendering can be used both server and client side.
That said, the patterns and details for doing so are not established yet.
By exposing the node and app in the Renderable
trait, it should be possible to explore ideas for more complex templating engines that enable features like 2-way binding or custom attributes with associated behavior.
No demo yet.
The story around integrating quasar with a backend is still just conceptual.
Probably Not. Nothing about Quasar is stable. Performance is probably attrocious. Rendering has plenty of quirks. The API is still plenty awkward. And major refactors are still anticipated.
There are tons of ways to contribute to Quasar, directly or indirectly, depending on your interests. The possibilities include contributing to the design the architecture and API to building demos to a variety of other ideas that more generally benefit Rust's emscripten ecosystem. There are issues tracking these and several other areas that could benefit from contributors, and feel free to file any new issues.
And of course, a star on GitHub encourages further development: Star on Github