Has Facebook picked up on this yet? Good thing the Web is a Web of documents.
Show HN: Percy – A Rust and WebAssembly isomorphic virtual DOM implementation
31–40 of 53 posts
Re: Show HN: Percy – A Rust and WebAssembly isomorphic virtual DOM implementation
#32Has Facebook picked up on this yet? Good thing the Web is a Web of documents.
Facebook is a Rust user, but given that this was just announced, I doubt that they're suddenly using it ;)
> Good thing the Web is a Web of documents.
That was three for three years. It's been 23 years since we've had executable code as well.
Re: Show HN: Percy – A Rust and WebAssembly isomorphic virtual DOM implementation
#33Has Facebook picked up on this yet? Good thing the Web is a Web of documents.
Good thing the Land is a land of dinosaurs.
Re: Show HN: Percy – A Rust and WebAssembly isomorphic virtual DOM implementation
#34Earlier quoted context omitted.
Can someone ELI5 what an inverted-index homomorphic shadow DOM is? TIA
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 r…
This is not ELI5
Re: Show HN: Percy – A Rust and WebAssembly isomorphic virtual DOM implementation
#35Can someone ELI5(+) what an isomorphic virtual dom is?
Isomorphic - runs the same on both web browser and server nodejs.
Virtual dom - not the real dom tree but a representation of the dom using nested objects. You can diff two versions of trees (current and updated) and apply the changes to the real browser dom. This makes building pretty UIs super easy since a view is essentially a function of state. Diffing the virtual dom and patching the real dom is much faster than iterating over the the real dom for every update.
On the server side, you use the virtual dom to render to html string.
So true isomorphism is basically when the same code is used in both browser and server. Server renders the initial page load to html string, once loaded by the browser the browser again uses the same view code to make further UI changes without causing a page reload (single page app). Good for search engines and crawlers, good for blazing fast performance and instaneous interactivity.
Re: Show HN: Percy – A Rust and WebAssembly isomorphic virtual DOM implementation
#36[makes side-eyes at React team to utilize webassembly]
Re: Show HN: Percy – A Rust and WebAssembly isomorphic virtual DOM implementation
#37Earlier quoted context omitted.
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 r…
This is not ELI5
Trolling 5 year olds is a long established tradition.
http://www.s-anand.net/blog/calvin-and-hobbes-dad-explains-s...
Re: Show HN: Percy – A Rust and WebAssembly isomorphic virtual DOM implementation
#38[makes side-eyes at React team to utilize webassembly]
Why? Has anyone shown this would be faster or a smaller download?
Re: Show HN: Percy – A Rust and WebAssembly isomorphic virtual DOM implementation
#39[makes side-eyes at React team to utilize webassembly]
Why? Has anyone shown this would be faster or a smaller download?
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.
Re: Show HN: Percy – A Rust and WebAssembly isomorphic virtual DOM implementation
#40Earlier quoted context omitted.
Why? Has anyone shown this would be faster or a smaller download?
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 you want to end up in the DOM would have to be copied over first, or rather, you want all your VDOM-generating code to be WebAssembly code as well if you want the whole thing to be efficient.