An experimental rust-to-{wasm,asmjs} frontend framework.
An experimental rust-to-{wasm,asmjs} frontend framework.
Supermassive black holes exist at the center of most observed galaxies, but there is much about them that remains a mystery. It is believed that rapidly adding sufficient matter to a supermassive black hole's accretion disk results in becoming a quasar that emits enormous amounts of electromagnetic energy as matter via astrophysical jets perpendicular to the black hole's spin. These jets can emit matter at nearly lightspeed and stretch hundreds of thousands of light years across a galaxy.
WASM is at the center of an upcoming shift in web development, but there is still much about that shift that remains a mystery. Some believe Rust, as an early mover, and with zero-cost abstractions is well-positioned to invest in bytecode that spins up on the event loop. It may be possible for Rust to power the fastest applications on the web, becoming highly visible across the frontend ecosystem for years to come.
Oh, and black hole's form from the collapse of a core of iron.. you know, the only element that rusts.
Everything is experimental, half-baked, full of caveats, regularly broken, and subject to change. But some basic principles are beginning to emerge. With Quasar...
Currently, Quasar combines some basic JQuery-like semantics with state and component management while ensuring that state modifications trigger rerendering of components that depend on that data.
Renderable
trait.Renderable
. Quasar takes ownership of your components when binding them to the DOM and makes the data available to your event handlers via data()
and data_mut()
methods. In general, methods that mutate the component will result in re-rendering it at the end of the event handler. Note, component data is local to the component and not shareable outside your component.innerHtml = ...
approach, which kills DOM state like input focus, so eventually some sort of DOM diffing/patching or virtual DOM solution will become pretty important.TypeId
), and any attempt to read a shared data partition (calling data(key)
) automatically registers your view as an observer of that data partion. Any attempt to write to an app data partition (calling data_mut(key)
) will automatically add all observer views for that data partition to the re-render queue process at the end of the event handler.A basic example might include an HTML file like this:
<html>
<body>
<div id="counter"></div>
</body>
</html>
You can bind and update data with a snippet like this:
#[derive(Default, BartDisplay)]
#[template_string = "<p>Count: {{count}}</p><button>+1</button>"]
struct CounterData { count: u32 }
impl Component for CounterData {
fn onload(view: &View<Self>) {
view.on_each(EventType::Click, "button", |mut evt| {
evt.binding.data_mut().count += 1;
});
}
}
fn main() {
let mut app = quasar::init();
app.bind("#counter", CounterData::default());
app.spin();
}
And every such framework needs a To Do app; Quasar has two: Mustache To Do, and Maud To Do.
Quasar is still exploring some ideas and working to better understand what works and what's missing in webplatform. Here are some overarching questions that are guiding this experimentation right now:
Admittedly Quasar is absent any perf goals at this time.
You'll need emscripten setup and activated (see brson's post), and then to add a couple compilation targets:
rustup target add asmjs-unknown-emscripten
rustup target add wasm32-unknown-emscripten
Now you can build quasar with:
cargo build --target=asmjs-unknown-emscripten
# or using cargo-web
cargo install cargo-web
cargo-web build
And you can run the various examples by running cargo-web start
from their directory:
cd www
cargo-web start