3 ms·

Nice! I remember hearing about Aether some time ago, and I'm glad to see development is continuing; I think the world needs more decentralized social networks.

by comex 8y ago

Nice! I remember hearing about Aether some time ago, and I'm glad to see development is continuing; I think the world needs more decentralized social networks. I plan to try it out and maybe post more in-depth feedback. For now, though, since nobody else in this thread has mentioned it, I'm going to be that guy – sorry: I wish it weren't Electron. I don't really expect it not to be; I realize your development resources are limited, and that it's the easiest way to make a cross-platform application, which is a must for a social network. Still, having to deal with a non-native UI makes it harder to truly enjoy using the app. Also, if it uses as much memory as Electron apps typically do, I'm going to want to quit it when it's not actively in use – but apparently Aether really wants to stay running in the background so it can continue to synchronize posts. (Is there a way to close the client but keep the backend running?)

devwastaken 8y ago
I think native UI in dedicated applications is massively overrated. It's great if it's apart of the system, if there's a config menu or something you'd expect from the system itself, but I have never had a problem with Spotify or Discord in terms of 'non native'. They can be a lot better absolutely, but native look is far worse.
rolleiflex 8y ago
I know - given enough time and money, I'd make a CLI app using something like ncurses. Unfortunately though, the reality is that I just don't have the resources. The backend is its own process, you could definitely find the binary in the application package and run it on its own — it's not bound to Electron in any other way. Electron is just the client, the frontend graph compiler, and the backend are two separate binaries that communicate with each other over gRPC. That means you could run any of these independently, as well. [0] The client is Electron, but nothing except the UI happens in JS, everything happens in the frontend and the backend, and they're both tiny, fast, native-compiled Go apps. My backend, for example, is 4.8mb, frontend I think is 6mb. The rest of the size of the app (70mb) is just Electron, its dependencies, and the whole enchilada that comes with it. I'm not happy about it either. For better or worse, though, since the JS part of the app is nothing but its 'skin', it's as memory efficient as Electron apps get. No real processing happens in JS, it's all Go. [0] That said, it's not something I support right now, because if you ran the backend separately and then started the app, you'd effectively be running two backends. There is not yet a way to tell the app package that it should connect to an existing backend running locally instead of starting one.
- fbender 8y ago
  How about providing a WebExtension that exposes the bits that require a binary (e.g. P2P and possibly proof-of-work part if WASM does not work for you) or are provided by the platform, then you can waive the Electron requirement for those who do not want it, plus your web interface potentially works the same for read-only visitors and users (who have the web extension installed). You can also include the frontend bits in the WebExtension so no one relies on the website working anymore.
FPGAhacker 8y ago
I haven’t worried about how much memory an app uses in many years. On a MacBook Pro with solid state storage, it’s just not noticeable. I did some testing a long time ago to see how the system behaved when apps used essentially all of the memory and then some. I actually couldn’t tell. I don’t remember anymore if I tried playing a game or not, so that might have been noticeable. But my VMs and browsers and several emacs’ connected to several clojure repls didn’t even hiccup. The fans ran high and the computer was hot, but otherwise it just wasn’t a thing. Is it that different on windows or Linux? At work windows is abysmal, even with an ssd, but I blame all the antivirus and corporate spyware. —- I do marvel at app binary sizes, just because my floppy disks used to hold jus 144k. I did a hello world in Haskell this morning and it was a meg or two. Hello world could fit on a floppy from the //e era. That’s something.

by comex 8y ago

devwastaken 8y ago

I think native UI in dedicated applications is massively overrated. It's great if it's apart of the system, if there's a config menu or something you'd expect from the system itself, but I have never had a problem with Spotify or Discord in terms of 'non native'. They can be a lot better absolutely, but native look is far worse.

rolleiflex 8y ago

I know - given enough time and money, I'd make a CLI app using something like ncurses. Unfortunately though, the reality is that I just don't have the resources. The backend is its own process, you could definitely find the binary in the application package and run it on its own — it's not bound to Electron in any other way. Electron is just the client, the frontend graph compiler, and the backend are two separate binaries that communicate with each other over gRPC. That means you could run any of these independently, as well. [0] The client is Electron, but nothing except the UI happens in JS, everything happens in the frontend and the backend, and they're both tiny, fast, native-compiled Go apps. My backend, for example, is 4.8mb, frontend I think is 6mb. The rest of the size of the app (70mb) is just Electron, its dependencies, and the whole enchilada that comes with it. I'm not happy about it either. For better or worse, though, since the JS part of the app is nothing but its 'skin', it's as memory efficient as Electron apps get. No real processing happens in JS, it's all Go. [0] That said, it's not something I support right now, because if you ran the backend separately and then started the app, you'd effectively be running two backends. There is not yet a way to tell the app package that it should connect to an existing backend running locally instead of starting one.

fbender 8y ago
How about providing a WebExtension that exposes the bits that require a binary (e.g. P2P and possibly proof-of-work part if WASM does not work for you) or are provided by the platform, then you can waive the Electron requirement for those who do not want it, plus your web interface potentially works the same for read-only visitors and users (who have the web extension installed). You can also include the frontend bits in the WebExtension so no one relies on the website working anymore.

FPGAhacker 8y ago

I haven’t worried about how much memory an app uses in many years. On a MacBook Pro with solid state storage, it’s just not noticeable. I did some testing a long time ago to see how the system behaved when apps used essentially all of the memory and then some. I actually couldn’t tell. I don’t remember anymore if I tried playing a game or not, so that might have been noticeable. But my VMs and browsers and several emacs’ connected to several clojure repls didn’t even hiccup. The fans ran high and the computer was hot, but otherwise it just wasn’t a thing. Is it that different on windows or Linux? At work windows is abysmal, even with an ssd, but I blame all the antivirus and corporate spyware. —- I do marvel at app binary sizes, just because my floppy disks used to hold jus 144k. I did a hello world in Haskell this morning and it was a meg or two. Hello world could fit on a floppy from the //e era. That’s something.