There are several interesting electron-js alternatives here. For example,
In summary, we have the following options:
1. flutter for web/mobile/desktop or
the advantage of flutter is that flutter is used to build cross-platform applications. Because it operates on a single codebase and renders native code on each platform, Flutter engineers can build native-like apps faster and with lower development costs. Flutter apps are compatible with iOS, Android, Windows, macOS and other platforms.
the downsides of Flutter is that it is a relatively new framework and may not have the same level of community support as React Native. This can make it harder for startups to find resources and support for their development projects.
another disadvantage is that you would have to change the frontend or backend or full-stack source code to flutter, which can be bad, because while a newer version is not made, certain features are left out.
ps: Of course users can choose to have an older version with less features compared to the development version.
2. tauri-js or nwjs for desktop or
the advantage of tauri-js and nw-js is that they are alternatives that consume less ram than electron-js.
tauri-js works with webview whereas nw-js will open the given entry point in a browser window. In Electron, the entry point is always a JavaScript script. Instead of providing a URL directly, you manually create a browser window and load an HTML file using the API.
the downside of nw-js, tauri-js is that they take browser resources to work. Despite being alternatives to the electron, they work in a similar way with technically very small differences.
3. self-hosted or
the only advantage of this type of architecture is if you have a personal homeserver or have money to keep the infrastructure of a local server running.
The downside of self-hosted architecture is that a server is required to run 24 hours a day, 7 days a week, 365 days a year. For most users this option is bad, because you have to have a certain level of computer knowledge to set up or manage self-hosted.
4. delta-chat as a browser add-on or
the disadvantage of this idea is that webassembly does not have the necessary resources to make this option interesting
5. only serverless/unhosted for desktop: ipfs(frontend), backend(mobile) for desktop - the proposal you suggest. and api/restful/ajax written in rust(in mobile).
As I understand it there would just be a mobile compiled UI and the web interface would be rendered by the browser into an ipfs address. The user would only have to have a dns address pointed to ipfs or even the ipfs address to access directly in the browser.
The advantage of this software architecture is that you don’t need to install anything on your computer. You would have to install only the mobile version to send or receive locally and offline synced email messages with web or desktop.
Another advantage of this idea is that you could have just one compiled version and another version just rendered, rendered by the browser from an ipfs address or custom dns address to ipfs.
In theory this architecture would be faster, because the entire frontend part runs separately from the backend part. The backend part, in turn, depends exclusively on the user’s cell phone hardware to function. Another advantage is that even if the user’s hardware is old, this will still work with certain performance and speed.
A final advantage is that each user can create custom instances of the delta-chat frontend on different types of networks, such as: i2p, tor(onion), hypercore, dat, ips, freenet, etc., to guarantee certain anonymity, security, control or privacy.
The downside is that whenever the graphical interface changes, a new ipfs address must be generated and must be associated or not with the custom dns, if that option is interesting and preferable. But this would happen only through the web version and not through the mobile version. Because the web version is different from the mobile version.
The final downside is that the web and mobile versions are different. As they are different versions, the code of the versions is also different.
Another disadvantage is that someone would have to be responsible for hosting the web version on some network protocol, server.
Notes
- As we can see there are 5 solutions for delta-chat to be faster or more performant, or even general solutions for the desktop, mobile or web version.
- In my humble opinion, the web option with serverless/unhosted would be better. Because the user accesses the site and uses delta-chat. It would be an experience equal to solutions like Spike, Gmail, Telegram-web, Whatsapp, Spark-mail etc.
,