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.
What I really mean is a virtual dom implementation that
- On the frontend can diff/patch a real DOM node - On the backend can render into an HTML string that you can serve
So my intended takeaway with that title was:
-> A virtual dom implementation that allows you to write frontend web applications that support server side rendering.
Apologies for the buzz-wordification I didn't even realize ha!
You did not miss the mark, you did a good job in the limited space you had.
I don't think many would understand what an inverted-index homomorphic shadow DOM is, though I think I can cobble together a very very vague understanding.
Not sure if this is ironic, but a 5 year old definitely wouldn't understand this!
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)!
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.
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 porting some code from NodeJS to a wasm module. I got it sort of working on Node, but haven't tried it on the browser yet (ran out of weekend).
I'm quite optimistic about wasm [and Rust with wasm_bindgen]. I'd been thinking of writing a native add-on for Node, but the idea that I can use wasm instead is exciting.
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 the JS that initializes the WASM
So that's your server crate. Then your client crate also pulls in your same application crate and you compile it to WebAssembly and that's what runs browser side.
Feel free to let me know if any of that was poorly explained!
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!
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.
> 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.
