Electron is essentially an operating system that runs on every operating system, so you can target just a single OS and your application works everywhere.
In the Electron case, it’s wasteful to some degree. Especially if the app is not doing much with files/storage etc. For VSCode it makes sense to not run in the browser but for Slack, not so much.
But generally I feel like there’s too much overlap between OS, browsers, IDEs and language runtimes (JVM, V8/Node etc.). It gets worse if you add containers and VMs.
I wonder how many garbage collectors, file abstractions, JITs, databases, schedulers, GUI engines, indexers and so on are running on my machine. How many flavors and versions of essentially the same libraries are used.
There is no unified vision, of what an OS/runtime/IDE/browser should be. There’s not even a common understanding!
I tried to picture clusters of information as they moved through the computer. What did they look like? Ships? Motorcycles? Were the circuits like freeways? I kept dreaming of a world I thought I'd never see. And then one day …
I actually can't run it locally (absurd tech policies), and I am so glad to never run it at all ever. Just easier to load it into an isolated browser tab when I need it, Zoom is so superior it's not even funny...
* Looking at an arbitrary article, "Why does Slack desktop app use Electron?" [1], the answer seems mostly aesthetics, "faster performance [citation needed] and the frameless look".
[1] https://brainhub.eu/library/electron-app-examples#:~:text=Wh...
It’s a shame, because cross platform app building, distribution and updates is a shitshow, even with electron, putting extra labor on the developers, so neither party is happy.
That said, some apps should really be web apps, but are still bundled as desktop apps purely for the frameless “premium” experience, and I assume to not be lost among 100s of tabs. It would be great if there was better browser support for allowing users to “install” web apps, but right now the support for that is pretty poor in terms of UX.
In other words, it's a typical case of costs being externalized, making the supposed trade-off be a "free win" instead. Since software resists commoditization, consumers don't even have a way to pass those costs back onto the vendor (by e.g. leaving for a competitor).
I am not particularly fond of Java (I know I am not alone :-D).
Javascript actually can perform well, not nearly as well as java can, but it doesn't have to be as bad as what you see on most electron applications. But it's not trivial to make it so.
But I'd put javascript and java on the same cohort when talk about usability (programability?, what name do I use here?). They are not as bad to be dangerous, but neither is any good either. Anyway, the JVM allows some other languages that don't solve all the problems but bring you some expressivity (honestly, I have no idea if this is a positive), while electron can work with typescript (much better than javascript) and can run wasm (what currently implies on rust, what means low expressivity but high confidence on your code).
I'm not ready to declare any winner here.
Well sure, and I would choose to be hanged rather than broken on the wheel, but I’d rather neither.
Fortunately, Armed Bear Common Lisp runs fine on the JVM.
[1]: https://survey.stackoverflow.co/2022/#section-most-loved-dre...
The best use of Java is implementing Clojure. Of that (Clojure) I am a fan.
As countless others have said before me, the parens really do cease to be an issue over time (and not really very long of a time either). The power and flexibility gained by writing code in Lisp/Scheme/Clojure or other Lisp dialects really is worth the effort, in my opinion. I'm not saying there are no bumps in the road - there definitely are. However, I have zero regrets about taking the time to learn those languages. Even if I never write another line of code in any of them again, it will still have been worth the effort.