Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

41–50 of 53 posts

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

#41

Post by JD557 »

chinedufn wrote: post #19
thinkpad20 wrote: post #15

How does this compare to the Yew framework?

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 materializ…

>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.

I find it funny that you mentioned that. I actually was trying out wasm-bindget/yew recently and ended up using yew because of the wasm-bindgen limitations (mostly related to using anything with generics in the type signature).

The experience will probably improve on the future, but right now yew's actor model seems like a much simpler way to encapsulate rust libraries.

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

#42

Post by _bxg1 »

julian37 wrote: post #40
_bxg1 wrote: post #39

Earlier quoted context omitted.

If they moved their virtual DOM (the meat of the work React does and its primary bottleneck) over to webassembly, it would almost certainly be faster. I can't really speak to the download size, though I wouldn't be surprised if that improved too.

It's worth keeping in mind that WebAssembly can't access the DOM directly; it has to call into JS in order to do that. I haven't investigated it myself but I'd wager that because of this, any performance benefits would be negligible. WebAssembly also can't access JS object structures directly, which means that the virtual DOM would have to live in WebAssembly land in the first place, ie. anything generated by JS that…

The whole point of a virtual DOM is to simulate and reconcile changes before pushing those changes to the real DOM; it would be fairly clean to do all that processing in wasm and then send the result over to JS for reification.

It's true that there would be some challenges when it comes to "sending" data to the virtual DOM; in particular, event objects could get complicated. I assumed this project has solved that problem, but I didn't read very deeply into it.

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

#43

Post by nevi-me »

chinedufn wrote: post #12
nevi-me wrote: post #3

Hi chinedufn, this looks very interesting. I am at the same stage as you re. "I REALLY want to use this for everything ...". I see you're using wasm_bindgen quite a bit, but from a cursory look at the code; I can't figure out something: I can see how you're using wasm in the front-end, but could you please elaborate a bit more about in the backend? I presume that your backend is Rust based? I spent last weekend porti…

Sure! The backend is pretty much this (messy) file - https://github.com/chinedufn/percy/blob/master/examples/isom... . It 1. Pulls in your application crate 2. Initializes your app (more or less sets initial state 3. Renders your app's virtual DOM into an HTML string 4. Serves the HTML to the client, along with the initial state serialized into JSON in a script tag (using serde-json) 5.Also serves the WASM script and…

Thanks, that makes sense. I haven't built web servers with Rust as yet; so it was a bit difficult to follow the code.

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

#44

Post by steveklabnik »

nevi-me wrote: post #43
chinedufn wrote: post #12

Earlier quoted context omitted.

Sure! The backend is pretty much this (messy) file - https://github.com/chinedufn/percy/blob/master/examples/isom... . It 1. Pulls in your application crate 2. Initializes your app (more or less sets initial state 3. Renders your app's virtual DOM into an HTML string 4. Serves the HTML to the client, along with the initial state serialized into JSON in a script tag (using serde-json) 5.Also serves the WASM script and…

Thanks, that makes sense. I haven't built web servers with Rust as yet; so it was a bit difficult to follow the code.

This is good enough for an example, but for a "real" web server, you wouldn't do this; you'd use a framework that handles a lot of this kind of thing for you. I think this code was adapted from the final chapter of the Rust book, which is mostly about learning how to write a simple thing than being production-ready.

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

#45

Post by mekkkkkk »

floatboth wrote: post #27
blattimwind wrote: post #20

Earlier quoted context omitted.

(Ok, before anyone goes running off telling their colleagues about this great new tech: I literally made all of this up on the fly except the batching stuff. That's actually one of two reasons why this whole shadow-DOM-stuff exists. The other is encapsulation. I think this whole thread is a most beautiful demonstration of Poe's law in its original form.)

I thought Shadow DOM only provides encapsulation??

I think "shadow-DOM-stuff" refers to the concept of virtual DOMs. The shadow DOM isn't really a virtual DOM though, sure. It's just encapsulated parts of the regular old DOM.

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

#46

Post by mekkkkkk »

jhabdas wrote: post #30
andrethegiant wrote: post #23

Heads up, there's something already called Percy in the JS space. https://percy.io

Pretty sure there's something called everything in the JS space. Thankfully this is the Rust/WASM space so all good names get to be recycled.

Damn, time to get started on React.rs. Is rQuery taken?

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

#47

Post by skybrian »

_bxg1 wrote: post #42
julian37 wrote: post #40

Earlier quoted context omitted.

It's worth keeping in mind that WebAssembly can't access the DOM directly; it has to call into JS in order to do that. I haven't investigated it myself but I'd wager that because of this, any performance benefits would be negligible. WebAssembly also can't access JS object structures directly, which means that the virtual DOM would have to live in WebAssembly land in the first place, ie. anything generated by JS that…

The whole point of a virtual DOM is to simulate and reconcile changes before pushing those changes to the real DOM; it would be fairly clean to do all that processing in wasm and then send the result over to JS for reification. It's true that there would be some challenges when it comes to "sending" data to the virtual DOM; in particular, event objects could get complicated. I assumed this project has solved that pro…

Keep in mind that WebAssembly strings are not JavaScript strings, so there is additional data conversion overhead that needs to be accounted for, versus a JavaScript implementation. And it's not just events and DOM updates. If you wanted to preserve React's render API, the input data for re-rendered DOM needs to be converted from JS before doing a diff.

With slower data conversion and faster internal calculation, it's plausible that it might overall be either slower or faster. I don't see any way to know without doing some experiments. It would certainly be more complicated.

It seems like the sort of JavaScript library where WebAssembly would be an easy win would have low API bandwidth (not much data crossing the boundary) and do a lot of expensive internal calculations. As a UI framework, React does some internal calculations but has relatively high API bandwidth.

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

#48

Post by steveklabnik »

skybrian wrote: post #47
_bxg1 wrote: post #42

Earlier quoted context omitted.

The whole point of a virtual DOM is to simulate and reconcile changes before pushing those changes to the real DOM; it would be fairly clean to do all that processing in wasm and then send the result over to JS for reification. It's true that there would be some challenges when it comes to "sending" data to the virtual DOM; in particular, event objects could get complicated. I assumed this project has solved that pro…

Keep in mind that WebAssembly strings are not JavaScript strings, so there is additional data conversion overhead that needs to be accounted for, versus a JavaScript implementation. And it's not just events and DOM updates. If you wanted to preserve React's render API, the input data for re-rendered DOM needs to be converted from JS before doing a diff. With slower data conversion and faster internal calculation, it'…

WebAssembly doesn't have strings, so you can model them just like JS strings if you want. It really depends on what you want to do.

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

#49

Post by chris_wot »

navaati wrote: post #21
dtx1 wrote: post #7

Earlier quoted context omitted.

I'm not sure if you are you are fucking with me or if i'm just ery stupid.... :(

AFAIK he's fucking with you ^^

Yup. Otherwise he's basically talking about a structure-preserving index that maps DOM elements - that are rendered outside the main document DOM tree - to a file.

And that's not really what's going on here.

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

#50

Post by somenewacc »

jlebrech wrote: post #17
chinedufn wrote: post #11

Earlier quoted context omitted.

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. T…

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 s…

ASP.NET does this, you use its components and it generates client side javascript. In a more functional way, there's another language that does this caled Opa! http://opalang.org/
Post reply on HN