Why aren't there any real alternatives to Electron?

Electron is absolutely unbeatable when it comes to being cross-platform. Because its core is the same as Chromium, every time Chromium, the biggest browser engine without question, is updated to run better, more stable on every platform, and big companies pump millions of dollars into it, Electron gets it "for free". Very hard to compete with that. Additionally, writing Electron applications has a relatively low entry point because it resembles writing web pages to some extent.

There are great alternatives. I used Python and Qt to create my file manager fman [1]. It's a tool that needs to start quickly so Electron was not an option [2]. I open sourced my build system for creating cross-platform desktop apps with this stack in minutes [3]. For a quick tutorial, see [4].

1: https://fman.io

2: https://fman.io/blog/picking-technologies-for-a-desktop-app-...

3: https://build-system.fman.io/

4: https://github.com/mherrmann/fbs-tutorial

Tauri is certainly not dead, and with a security audit in progress and a stable release in its fourth RC, it's surely very close to 'production ready'.

https://github.com/tauri-apps/tauri/releases/tag/tauri-v1.0....

I’m not a JS developer, so take this with much salt, but one that caught my eye was SciterJS [1]. It is built using Fabrice Bellard’s QuickJS engine [2], and appears to be very efficient. Definitely has great potential I think. See previous discussion here: [3]

[1] https://github.com/c-smile/sciter-js-sdk

[2] https://bellard.org/quickjs/

[3] https://news.ycombinator.com/item?id=24797423

At this point its hard to come up with interesting arguments. I don't like electron as much as the next guy, but if you ever tried to develop a desktop app you can easily appreciate Electron for what it is.

Anyway heres some other choices might be viable these days: - Flutter desktop https://flutter.dev/multi-platform/desktop - Jetbrains Compose https://www.jetbrains.com/lp/compose-mpp/

IMO immediate mode guis should be option as well, like imgui, egui. (But afaik you basically throw accessibility out of the window)

You can use JavaFX or QT (with c++ or python) but they are no match for the eye candy that is to be had with html5 and css3. It's your job to integrate with the platform style, you have the flexibility to do so.

Resource usage is a problem but has become manageable over the years. See how pretty and efficient VSCode is. And honestly thank God we have electron, before that a truly cross platform ecosystem was limited to Java and that abomination Adobe AIR.

Qt's QML is both declarative and reactive, and even lets you program in JavaScript or TypeScript. It also uses a tiny amount of memory and it's really fast. It's the closest thing to the React and Electron model while still being fast and efficient.

There are some suggestions, on Mozilla's suggestion platform Mozilla Connect, for turning Gecko into something like Electron[1][2].

In the past, Mozilla ran the Positron project, which was an Electron-like library on Gecko[3].

[1] https://connect.mozilla.org/t5/ideas/create-an-alternative-t...

[2] https://connect.mozilla.org/t5/ideas/ability-to-embed-gecko-...

[3] https://github.com/mozilla/positron

> Is "just stick Chromium into all your apps" seriously the best we can do as an industry?

Yes. What other rendering engine are you going to use? If your answer is anything but a web browser rendering engine, then consider that any serious UI toolkit in 2022 is certainly going to need a WebView UI component: so if you want the WebView UI component to be consistent across platforms (you want this), then you will have to bundle a web rendering engine anyway. In that case, why not just use the web rendering engine as your main rendering engine?

There’s nothing wrong with Electron as a concept. The issue is with either: blink being under optimized for this use case, or bad Electron apps.

> Why aren't there any real alternatives to Electron?

Because it's not as easy as it seems to create a proper cross-platform framework. And even if there was an alternative, these days you often need rich text, images, videos, etc. all of which are essentially HTML pages. So you'd end up adding a webview anyway, which is getting quite close to being Electron.

And I think that's the key - why create an "alternative" to Electron if you end up bundling webviews, ffmpeg, libpng and so on. It might be a bit smaller in size than Electron but not enough that it matters.

Tangehtial comment: I do not use the Discord Electon app, but use it as a pinned tab on Firefox.

I would not trust a full browser running on my machine on which I have no control and they can mine whatever telemetry data they want.

>There are a number of solutions that are either dead or are not ready for production yet, such as React NodeGUI[0], Proton Native[1] or react-native-desktop-qt[2].

Just looking at your 3 examples, I notice they all depend on Qt ... and hence the Qt UI components instead of the more familiar HTML/CSS of Electron.

So the code ends up looking like:

  const { QLabel, QMainWindow } = require("@nodegui/nodegui");
  const win = new QMainWindow();
  const label = new QLabel(win);
  label.setText("Hello world");
  label.setInlineStyle("color: green; background-color: white;");
  win.show();
  global.win = win;

So the idea of programmers having to learn a bunch of unfamiliar QXxx() like QLabel() etc -- will be a tough sell to gain mindshare. Yes, it's Javascript instead of C++ but the QXxx() will still create a lot of friction for adoption. Also, a dependency on the Qt framework may be worse than Chromium for various strategy/technical/license reasons.

>Is "just stick Chromium into all your apps" seriously the best we can do as an industry? It's resource-inefficient to high heaven,

The complaints about "resource-inefficient" attract a lot of agreement but also ignore the productivity of the developers that get to leverage their existing knowledge of Chromium-based components.

If whatever alternative to Electron has SuperiorResourceEfficientTechnology also comes with unacceptable extra friction (aka learning curve) for adoption, it will then also lose to Electron.

Unpopular but a valid alternative is a wxWidgets application using the wxWebView component - very similar to Electron, in that it IS Chromium at the core, but it is in it's component pieces. One gets to pick and choose at a lower level what portions or the entire thing ya want. And being wxWidgets, it runs fine on the desktop OSes. But wxWidgets is unpopular, so be ready for assholes to tell you what you're doing is wrong.

This would have been one of the things Mozilla should have been involved, have their Rust/Servo team focus on node/electron alternatives too, this way they could have gain the minds of developers but they would need to somehow be able to accept donations for this projects and not for their weird activities not related to dev.

My question is why Electron isn't a shared OS level thing.

It seems like Chrome OS really had the right idea. Can't we have some cross platform app format that's just a ZIP file full of HTML, with some APIs that go beyond normal web features?

I saw a project on here a while ago that used Godot to make a desktop app. Godot is a “game” engine, but the app posted to HN was a business application. I thought it was interesting to use a game engine to make a business app, it actually looked quite good. I wish I still had the link.

On Windows and Mac I make application shortcuts directly in Chrome. These use the same amount of resources as an ordinary tab, but appear just like a desktop application. I have dock/taskbar icons for Gmail, calendar, YouTube music, ect.

I don't use Linux, but given that Edge also supports this, I suspect that you can do this with Chromium.

I'm not on my computer, but the steps are to hit the hamburger menu, select create shortcut, and then select the checkbox. The words vary, but it's usually something like "run in separate window" or "run as application."

As a compromise are there any major downsides to instead deploying your app that hosts its own lite http server using a multi-platform library in Go or Python, which then uses the pre-existing web browser to render the UI?

Developers often work on high-specced laptops and it's hard for us to even remember how using 4GB of RAM feels like. My first laptop I used for professional work had 16GB of RAM and that was a 1000€ laptop 9 years ago. That laptop still works and Discord is usable on it.

On the other hand I did see a computer with 512MB of RAM in use at a high school in my country in 2018, so I understand that in some places people can't afford to upgrade their hardware.

But if RAM is the only issue and most 15 years old hardware can be upgraded to 8GB or 16GB of RAM for 80€, I believe that most developers simply see problems on 4GB RAM systems as a non-issue.

You can use Lazarus IDE/Free Pascal to build small efficient executables on most platforms. A small GUI built without debug information clocks in at less than 3 megabytes on Windows.

To get to the non Mac/Linux/Windows end users, Free Pascal is working on a WebAssembly back end, which should allow you to run in a browser. Here's their RoadMap/Status page - https://wiki.freepascal.org/WebAssembly/Roadmap

I wonder if there would be some way of having a system wide electrond that hosts the rendering engine, that electron apps could check for the existence of and use, instead of having an instance for every app. Like a multi tenant electron. I’m aware that this is basically a browser, but it would be specialised and offer the same level of integration as normal electron unlike the tab-in-a-window that Chrome apps were.

If you want to write Linux apps, Flutter is a compelling alternative - it's not JavaScript but apps start fast and don't use much memory, but you'll still have a fast, React-like dev experience. Writing Flutter apps on 4GB of RAM isn't gonna work though, as the IDE / Dart analyzer uses a *ton* of memory. Would recommend using CodeSpaces or something similar if you go that route.

honestly you can use Java or Kotlin. Java/Kotlin targets macOS, Windows, and Linux just like Electron. Even though you’re substituting V8 for the JRE, JRE is much faster and smaller and should not eat up your RAM.

The main downside is that you don’t get to write your UI in HTML. IME, most Java applications look really ugly, but they run very fast and work well.

I'm working on an alternative. It's a slightly different take, but provides similar functionality of Node.js plus front end code in a packaged binary. Instead of using a weird custom fork of chrome and downloading that for every different binary we just use the system Chrome browser (or install it once for all apps). Eventually we can probably expand to use other Chrome browsers or even other web driver supported browsers which Firefox seems to be building that support out. I just like the idea of using something that's already on the system.

Take a look at the wonderful GraderJS, heh :)

https://github.com/crisdosyago/graderjs

A true Electron-killer will be one that allows migrating from an Electron codebase with 0 code changes, and offer low usage of resources by e.g. using WebKit on Mac.

In the meantime, no one will bother explore other options, because it just works, even if it's a resource hog.

I am working on app that I wrote initialy in electron, but now have moved away from it.I have perspectives on both good and bad sides of electron

The good parts

Low barrier to entry - if you know javascript you are good to good. No need to learn C++ or Java for building a desktop app.

Truly cross platform - any platforms that chromium supports, electron supports

A very active ecosystem - The community around electron is amazing. I am a big fan of electron.build, things like code signing / auto updates etc are provided out of the box

The not so good parts

IPC hell

Electron has a main process and renderer process and they communicate via events. I found myself swimming in the event soup very often.

Easy to make mistakes

This is more for a note for me or any beginner, but it is easy to write compute heavy code in the renderer and make the ui unresponsive or sluggish. There are many other things like this where it is easy to do things the wrong way.

Security

Electron still has a capable browser which can open any webpage. Mix that with native access and you have a remote code execution vulnerability on your hands.

Bloated binaries

Even the simplest of the electron binaries are large, thats just the nature of electron.

Shameless plug

The app that I am working on is https://loadjitsu.com, I rewrote it using golang, couldnt be happier.

I wish any Electron app would also be available as browser/web app, so I could just run it in a browser tab (and save some resources/memory?). This is possible for Spotify and Slack but not for Signal.

We use Object Pascal (via Lazarus) and compile the code for each target platform. The apps concerned are (only?) dev utilities, but they're fast and have a small footprint.

how much is discord using? on windows it seems to use very little (27MB of RAM).

I just started building with NeutralinoJS, and have previously built with NW.js.

Both don’t really solve the browser engine thing, but at least Neutralino is much smaller in terms of executable size.

I like the idea you can use any language you want for the backend/system level stuff, though for me that just means more typescript :)

I haven't gotten around to trying Tauri, but I've meant to. Perhaps you'll find it interesting?

https://tauri.studio/

If memory serves, it reuses the OS default web view and any "backend" or system things are done in Rust.

Wikipedia says the first web browser was created in 1990. And it says electron is 8 years old.

So it took 24 years to get a cross platform rendering engine that was feature rich enough for great desktop apps. Even if we take these learnings, how long till we get a new framework good enough?

Electron is the lazy way as there is no barrier to entry. But if I wanted to run a web app then I’ll use a browser. I avoid all electron apps except Teams and Edge. When we have a text editor requiring electron then we’ve truly lost our way.

Why isn’t discord.com a PWA already? What are they waiting for?

> Is "just stick Chromium into all your apps" seriously the best we can do as an industry?

Is there a layout engine that performs faster and more flexible?

You may be interested in Tauri: https://tauri.studio/

Why don't you open them in browser tabs, let notifications come through your phone when they're closed?

As native tools get easier to use I believe they are the way to go

the funny thing is that all of the apps that run in Electron use much fewer resources when run in the browser itself. so thats what I do.

i don't think many people outside of us technical folk care about electron apps using tons of resources to do what they need to do. (many folks run chrome, for example).

Electron exist because multi-millon dollar companies and the BEST paying people on earth not care about users, at all.

Only what is convenient and fast to do.

---

Alternatives exist, since long time ago. But developers are LAZY. A LOT.

That is why the worst tech that exploit laziness and reward instant gratification (php, js, node, mongo, electron...) survive and get poured millions on effort fighting them, instead of invest is what is better.

Ironically, this kind of tech WASTE money and time like is not tomorrow, but that is for later, and the major effects are not on the laptops of the developers that made it...

Because of sheep effects and state of things: Big&Powerful want all to be web, to be hosted on their datacenters, with the maximum lock-in possible, so they push desktops toward classic mainframe dumb terminals.

The outcome of such push is:

- we do not have anything really cross platform, at least in look&feel terms, there are classic, old, and nearly ignored by most (T)Tk but not much more. Windows have it's own GUI, OSX it's own as well, Qt have derailed long time ago toward a bloated monster with an uncertain future, GTk have derailed since GTk3, and both still do not have a real "native look&feel" on all platforms;

- developers fear having invested a big amount of time and resources on something and then being forced to reinvest time and effort just because at a certain point in time a dependency they used vanish or substantially changing imposing a almost total rewrite of the UI.

WebUI then seems to be the "safest" way to go, at least they can "float" between various platforms as needed and people know them and like their colored style... However chosen a classic local server for a localhost webapp is longer than just grabbing something already made and then...

IMVHO the real alternative is say STOP. Witch means for now ok-ish to develop locally served WebUIs or classic Tk/fltk/OpenGL (depending on the kind of GUI) but certainly not in the Electron/node sauce, only the UI and as much detached as possible from the core logic for the narrow target. For the broad target push back toward a real desktop model. Push networked applications that are not web thing, like pushing again emails with a local MUA, not a webmail, a local maildir not on a remote IMAP, locally indexed to have GMail like search (notmuch/mu for instance), file sharing apps like SyncThing/Retroshare, Jami for audio/video communications etc.