Show HN: Percy – A Rust and WebAssembly isomorphic virtual DOM implementation

As in an example app?

If you don't need server side rendering you can have one Rust file but you also need a JS file to initialize the WebAssembly module. So just one file isn't reasonably possible.

For a server side rendered app you need to have a cargo workspace with 3 crates (they can be in the same repo so not a huge deal).

One crate is a `cdylib` that you compile to WebAssembly to serve your app to the client. This is a light wrapper around your actual application.

One crate is your actual application.

And one crate is your server, which is also a light wrapper around your actual application.

That server side rendering structure can be found here - https://github.com/chinedufn/percy/tree/master/examples/isom...

But in terms of a super minimal example without server side rendering.. I'll be working on adding one (along with updating the current example)!

In a regular DOM there's just a tree of elements, this makes many operations tedious, e.g. finding elements with a given set of classes and so on. So with an inverted-index shadow DOM you get another DOM with element shadows and an index of element properties back to the shadow elements (making it an inverted index). Then simple boolean retrieval can be used instead of DOM traversal. Much more efficient. The actual reason why you want to use shadowing instead of direct-mapped nodes/elements is shadowing enabling E2C (element change coalescing) meaning instead of shadow element changes directly transferring over to a change of the actual DOM element you can batch changes on shadow elements together and change a bunch of DOM elements in one go, which avoids unpartitioned (and therefore wasteful) re-renders by the browser engine.

How does this compare to the Yew framework?

what i want to see is to have all logic to be centered around features, and have a framework compile the server side and client server out of one logical piece of code, if that even makes sense.

a bit like in the old days of php when you'd have the serverside code and html rendered in their, but this time nearly everything is running on the client unless the client can't be trusted.

you could have some kind of ring system, where something can never run on the client right up to always run on client, but all in one file.

but maybe that's nasty.

Yew is awesome and just knowing that something like that was possible inspired Percy. I also looked at Yew's `html!` macro when figuring out how Percy's could / should work.

One difference is that Yew is powered by stdweb and Percy is powered by wasm-bindgen.

I'm personally SUPER bullish on wasm-bindgen because it's been designed from day 1 to be able to take advantage of the host bindings proposal when it materializes.

Host bindings tl;dr is that instead of needing to go through JS to interact with browser APIs you can interact with them directly.

Another difference is that to my knowledge Yew doesn't support server side rendering ( which was why I couldn't use it even though I wanted to :( ).

Without having used Yew I don't want to comment any further than those high level differences.

I can say that a big focus of Percy is to be a grab bag of modules / tooling for frontend Rust web apps with a major focus of you being able to swap out the parts that you think are bad for other peoples' better implementations. That dream isn't realized yet.. but I think that Rust's generics / traits could make this feel very clean!