Reconsider where the words "Rust" and "Javascript" are used within examples and documentation.

[seanybaggins]

Is your feature request related to a problem? Please describe. I have found throughout the documentation, that the front end is assumed to be written in javascript and the back end Rust.

This assumption makes reading documentation and examples very confusing if you are writing the front end in Rust/wasm

Specific example. Send event to Rust Someone using Rust/wasm is going to think they are sending a message to their front end application when in reality they are sending a message to the back end of the application.

Describe the solution you'd like Perhaps making the distinction between front end and back end rather than javascript and Rust.

[nothingismagick]

That's a really good point, however I would like to remind you that WASM is always run in a javascript context and without that JS wrapper, there is no WASM. In fact, you actually lose a number of memory protection mechanisms by using WASM in the front end. If you haven't watched this presentation, then I highly recommend you do so at your earliest convenience:

https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann

In many cases I have seen WASM actually run slower than other bindings (obviously depends on the use case). Now while you might be operating on the notion that you are running 'backend' rust inside of WASM, I am very suspicious of the security model of this type of system. Nevertheless, we can't change history now and the paradigm is quite powerful. But I would like to remind you, just because you are binding your rust and delivering it to the JS engine as WASM, you are not operating on the 'secure' side of the equation. You are executing single-threaded code in the webview and do not have the memory isolation or multithreading etc. etc. etc. that you have on the 'real-backend'. So your 'pseudo-backend' is really in my opinion a wolf in sheep's clothing. </rant>

That said, we are moving toward a future where the backend could be written in any number of languages and sidecar integration is even available today. Therefore I would recommend we start being more general like you recommended:

1. Launcher
2. Backend
3. API
4. Sidecar
5. Webview

[nklayman]

Would it be better to copy electron and use main/renderer process for simplicity? Backend/api could easily be confused with a cloud server in some cases (ie "send message to backend" or "request with the api").

[simonhyll]

So for this we have pretty much settled on the concept of calling it "front-end" vs "back-end", where WASM would fall under the category of the front-end and the back-end is the native Rust side of the app.

I'll close this issue as being taken care of in fairly recent discussions on Discord.