Socket vs Alternatives (Electron, Proton Native, NW.JS)

[lacymorrow]

Hi, I'm an Electron dev and I have a few questions about why this might be better. Obviously the size, potentially RAM usage.

My questions:

1. Can I create an "Always on top" window that persists above fullscreen apps, even DirectX, Vulkan, etc
2. What does the native module support look like? Can I get the currently focused application name, even when my socket app is not focused?
3. Can socket apps be packaged and built into native executables, similar to electron-builder/forge? What does this process look like?
4. Can apps be auto-updated?

[jwerle]

Hi, I'm an Electron dev and I have a few questions about why this might be better. Obviously the size, potentially RAM usage.

My questions:

1. Can I create an "Always on top" window that persists above fullscreen apps, even DirectX, Vulkan, etc

Currently we do not support an API for doing this, but we could consider it after some research into what it might take to implement on desktop (linux, macos, windows)

2. What does the native module support look like? Can I get the currently focused application name, even when my socket app is not focused?

You can do anything you'd like on the native side. We have a Native Extension API that should help you with various ways of communicating to the webview. We will have some blog post explainers and examples soon that demonstrate how to use the extension API, but you can take a look at the runtime tests as an example: https://github.com/socketsupply/socket/tree/master/test/src/extensions

3. Can socket apps be packaged and built into native executables, similar to electron-builder/forge? What does this process look like?

Yes that is correct. You can use ssc build to build the application. There are various ways to package and codesign (if needed) an application for distribution. We are actively improving this process to automate much of this workflow

4. Can apps be auto-updated?

Currently, we do not have an auto updating feature that is built-in to the runtime. It is on our internal roadmap for research to understand how to implement this correctly

[thalperi]

Especially in a P2P context, it would be immeasurably valuable to allow peers to offer each other incremental, even module level updates with less updated peers having the option to opt in to a peer pool to which they can subscribe.

[heapwolf]

Auto-update only works on 2 of the 5 major OSes. It doesn't work on iOS or Android which are the majority operating systems. Squirrel for macOS hasn't had a commit for 3 years ago, the latest release was 2017! It's neither maintainable or maintained. It also adds a lot of security considerations, distributing through the native app stores offers a lot of upside. We may add auto-updating in the future, but we strongly suggest using the OS's native software update system.

[lacymorrow]

Thanks for the responses here. I really think you've built something great with socket, I urge you to focus on ease-of-use and platform agnostic-ity.

I have a few apps I have use-cases for:

• a cinematic popcorn time – like app that could potentially embed the system native video players, if possible
• an IOT device running a UNIX system that boots into a static HTML site, but then updates with the latest version once connected to the Internet. Currently I'm using github to update the code on a reboot but an automatic way to update the app would be useful for IoT devices or SPAs.
• an electron app that displays a crosshair on the users screen (for gaming). This would be nice to be able to inject above directx or Vulkan games (not yet possible with electron). I've also had requests to change settings based on the current game, which would require the ability to get the currently focused app, or a list of all running apps.

Obviously all of these things are doable in one way or another but the less native modules/OS calls I use, the less likely I am to have my app banned by games.

I have almost all of the features running for these apps, but you can imagine testing/maintaining/deploying can be quite a task.

Other interesting projects similar

Electron
Proton Native: https://proton-native.js.org/#/
NW.JS: https://github.com/nwjs/nw.js
Tauri: https://tauri.app/

https://conveyor.hydraulic.dev is interesting for packaging and deploying, may be useful for socket

[heapwolf]

• Electron and node-webkit is specifically for desktop
• Proton Native hasn't had a commit in 4-5 years.
• Tauri is a library/framework for using the webview from Rust, it's more for rust programmers than web developers which is a major difference between our goals as projects.
• Hydraulic is a service that provides builds for all of these things, its like "last mile" for app development.