7 ms·

I once led a mid-sized team in building a desktop application with Clojure. It might sound nuts, but we used both the JVM and Electron, using both Clojure and C

I once led a mid-sized team in building a desktop application with Clojure. It might sound nuts, but we used both the JVM and Electron, using both Clojure and ClojureScript. We solved all the performance issues we’d experienced with Electron by restricting it to serve as a desktop GUI API. Literally nothing was in Electron except a small package for handling these API requests: set a menu, open a window, load a page, etc. Even inside an open window, the ClojureScript code was loaded from and communicated with the JVM, rather than being bundled into Electron. You want your desktop app to both look great and perform great. Restricting Electron to its basics while moving everything else into another system is definitely one option to consider.

sdegutis 7y ago
I honestly cannot imagine how that would be more performant than just using Electron by itself the typical way, unless this was a very CPU intensive application like a video editor.
karatestomp 7y ago
Last I checked, due to how Electron’s structured, you basically have to decouple “logic” from the UI anyway, which makes it relatively easy/natural to make the “logic” side just a thin translation layer talking to some other language.
- efficax 7y ago
  not sure what you mean here. You can write a full fledged app in Electron without any 'backend'
  - karatestomp 7y ago
    Last I checked it runs a process (I think a full process, not just a thread?) for the UI and another for the rest of the application, and the two talk via calls to IPC functions.
truth_seeker 7y ago
Why did you guys use JVM at all ? If it's for multi-core computation purpose it can be with Worker Threads in JS or CLJS.
- vijaybritto 7y ago
  Spawning a thread is much cheaper than spawning multiple processes right?
vijaybritto 7y ago
Was webassembly considered before going with this approach? It's completely okay to go in a way the team is most comfortable with. But if it was pure perf reasons then webassembly would solve it right?
kickopotomus 7y ago
I am actually currently working on something similar but instead we opted to use JxBrowser[1]. It's basically what Electron used to be but has Chromium embedded into the JVM instead of Node. [1]: https://www.teamdev.com/jxbrowser https://www.teamdev.com/jxbrowser
- sdegutis 7y ago
  Super cool. If someone wraps this with Clojure for the backend, ClojureScript for the front-end, and hides jpackage and NPM (or whatever ClojureScript uses) details, this would be a great Electron alternative.
bertmuthalaly 7y ago
This reminds me of this writeup on doing something similar, with Rust as the native core for an electron app; the Rust in this case is in-process, written using "neon". This app (Finda) hit a performance target of 16ms rerenders for incremental browser history + desktop file search - computers are fast, even if you use Electron. - https://keminglabs.com/blog/building-a-fast-electron-app-with-rust/ https://keminglabs.com/blog/building-a-fast-electron-app-wit... - https://github.com/neon-bindings/neon https://github.com/neon-bindings/neon (edited for formatting)
BubRoss 7y ago
What did this do and why was using multiple languages, an entire web browser and the jvm a good fit?

sdegutis 7y ago

I honestly cannot imagine how that would be more performant than just using Electron by itself the typical way, unless this was a very CPU intensive application like a video editor.

karatestomp 7y ago

Last I checked, due to how Electron’s structured, you basically have to decouple “logic” from the UI anyway, which makes it relatively easy/natural to make the “logic” side just a thin translation layer talking to some other language.

efficax 7y ago
not sure what you mean here. You can write a full fledged app in Electron without any 'backend'
- karatestomp 7y ago
  Last I checked it runs a process (I think a full process, not just a thread?) for the UI and another for the rest of the application, and the two talk via calls to IPC functions.

truth_seeker 7y ago

Why did you guys use JVM at all ? If it's for multi-core computation purpose it can be with Worker Threads in JS or CLJS.

vijaybritto 7y ago
Spawning a thread is much cheaper than spawning multiple processes right?

vijaybritto 7y ago

Was webassembly considered before going with this approach? It's completely okay to go in a way the team is most comfortable with. But if it was pure perf reasons then webassembly would solve it right?

kickopotomus 7y ago

I am actually currently working on something similar but instead we opted to use JxBrowser[1]. It's basically what Electron used to be but has Chromium embedded into the JVM instead of Node. [1]: https://www.teamdev.com/jxbrowser https://www.teamdev.com/jxbrowser

sdegutis 7y ago
Super cool. If someone wraps this with Clojure for the backend, ClojureScript for the front-end, and hides jpackage and NPM (or whatever ClojureScript uses) details, this would be a great Electron alternative.

bertmuthalaly 7y ago

This reminds me of this writeup on doing something similar, with Rust as the native core for an electron app; the Rust in this case is in-process, written using "neon". This app (Finda) hit a performance target of 16ms rerenders for incremental browser history + desktop file search - computers are fast, even if you use Electron. - https://keminglabs.com/blog/building-a-fast-electron-app-with-rust/ https://keminglabs.com/blog/building-a-fast-electron-app-wit... - https://github.com/neon-bindings/neon https://github.com/neon-bindings/neon (edited for formatting)

BubRoss 7y ago

What did this do and why was using multiple languages, an entire web browser and the jvm a good fit?