
So, if not Electron apps, then what? - vijaybritto
I&#x27;m trying to get some data on building a cross platform desktop app. It&#x27;s to help devs in my company by giving a GUI for few tasks. But I don&#x27;t want to suck up their RAM. What are the other alternatives that come close to electron in terms of productivity while consuming low memory?
======
monetus
Tk is pretty fast. It has bindings in multiple languages, though I'd suggest
TCL. There is a starkit idea floating around, where people package a binary
for each platform along with any other dependencies. It is much lighter than
electron.

edit: to be clear, one clickable thing that works on mac, windows, linux,
and... maybe arm? there is an androwish, but I haven't tried it.

------
notheguyouthink
Tbh I'm surprised React Native hasn't been brought to Desktop yet. It solves
the problem with nice compromises imo, and gives a great native experience in
the ui layer.

~~~
Chyzwar
People are trying

    
    
      https://github.com/Microsoft/react-native-windows
      https://github.com/ptmt/react-native-macos
      https://github.com/status-im/react-native-desktop
    

But without top-level standardisation effort it will not work.

------
flukus
Qt, Gtk, Tk, wxWidgets, Delphi (whatever the open source one is). All have
pros and cons depending on your needs but you should be able to throw
something pretty serviceable together pretty quickly. The biggest catch for
most is the reliance on c/c++, but if you want to be lean on memory then you
probably want this anyway.

Some of these are heavyweight, others are just wrappers for the native
libraries.

If this is a dev tool I wouldn't rule out a curses based TUI app either.

~~~
O_H_E
> curses based TUI app I really love these

------
jetti
FreePascal with Lazarus. You can create native apps (including mobile apps)
all with one Object Pascal code base. If you want a commercial product and are
on Windows you could always use Delphi as well.

------
kevinherron
JavaFX, especially when used with Kotlin and TornadoFX, is really nice.

We're now at the point where you can bundle your app, JVM pieces needed, into
a single distributable for each platform. With Graal and whatever else on the
horizon there might even be just plain compiled-to-native options coming too.

If you don't like the JVM ecosystem I think QT also has potential but it seems
much more difficult and labor intensive to create a decent application.

------
quantummkv
Nothing really. If you don't want to sacrifice productivity then you go the
electron way. Java/Swing has horrible UI/UX and doosen't offer any real
benefits on RAM. QT is good if you are willing to pay for the licensing costs
for commercial use or you open source your app. Everything else that is cross
platform works, until it dosen't. Good luck debugging gtk on windows.

If you can spare the resources, create per platform apps. If not, then
electron is your only headache less option.

~~~
flukus
> QT is good if you are willing to pay for the licensing costs for commercial
> use or you open source your app.

Qt is LGPL, you can use it commercially for free.

It sounds like this is for an internal app they don't plan to distribute, so
even the GPL would be fine and not require them to open source it.

------
pier25
The idea of using web views for the UI is valid IMO. The problem is that
Electron brings a ton of metal with it (Chrome + Node).

A solution is to create your own Electron by creating the UI with HTML/CSS/JS
and using the OS native APIs for the window and "back end" code.

Depending on your use case it might be feasible to do that yourself, or use a
project like NodeKit.

[https://nodekit.io/](https://nodekit.io/)

------
seanwilson
What does the app do? How much RAM do the company machines have?

Personally, I'd take the hate about Electron here with a huge pinch of salt.
RAM isn't expensive, developer machines tend to have a lot of RAM and you're
only wanting to launch a single app. A minimal Electron app takes about 100MB
of memory which isn't much if you've got e.g. 8GB of RAM.

------
roryisok
How about this?

[https://github.com/zserge/webview](https://github.com/zserge/webview)

C/C++/Golang webview. Build your UI in html/js and offload any heavy tasks to
compiled languages. There's also a rust binding on github.

The sample app shows what you can do

------
lignux
I use TornadoFX daily and its a joy to use.

~~~
mrks_
This looks great, thanks for bringing it to my attention!

------
WaltPurvis
Depending on what you're trying to do, Xojo might be a good choice:
[https://www.xojo.com/products/desktop.php](https://www.xojo.com/products/desktop.php)

Others have mentioned Qt/QML, another solid choice.

------
mabynogy
Love2D with a GUI (lua): [https://love2d.org/](https://love2d.org/)

miniSpere (js): [http://www.spheredev.org/](http://www.spheredev.org/)

------
TekMol
Why not a web app?

------
brudgers
What's the financial ROI effort spent to "save Ram" on developer's computers
versus just adding hardware capacity to those same computers? The ROI should
include productivity gained lost based on delivery schedule, the costs of
ongoing app maintenance, the cost of finding developers in whatever
alternative to electron is chosen, the value in terms of security and bug
fixes that a mainstream project like Electron provides, and the economic value
of having RAM on developer computers available for other business productive
purposes. My gut assumption is that $200 of RAM upgrades across 50 developers
is probably cheaper, but I could be mistaken. Good luck.

~~~
cimmanom
Not everyone can upgrade their RAM without switching to new hardware, and the
company's probably not going to invest in that across their entire dev team
just to accommodate one new internal app unless it's truly mission-critical.
And heck, Mac laptops _still_ max out at 16GB.

And it's not just RAM. Electron rendering is slowwwww.

~~~
brudgers
I don't disagree that there may be a hardware upgrade. My point is that
without running numbers increasing development, maintenance, and risk in order
to "save RAM" is dogma not engineering. Rendering speed is just one
consideration. That's why Slack.

~~~
cimmanom
That may be. But there's also no point in building something at all if your
target audience's hardware won't run it or if it'll slow those machines to a
crawl. There's a decent chance that the OP has no power over the pursestrings
that would need to be opened for a hardware upgrade.

------
imauld
If it's for devs just stick a small server and thin HTML front end in a Docker
container. Or just give them a CLI, I prefer CLI's over a GUI most times
anyway.

------
wishinghand
If one is down with React, this project has promise:

[https://proton-native.js.org](https://proton-native.js.org)

~~~
pcmaffey
Looks interesting. Anyone tried this?

------
mbrodersen
Seriously? Are your devs running MS-DOC with 640k of RAM? If not then don't
worry about it.

------
farseer
A Java/Swing application would be easy to maintain long term, even decades
from now.

------
matlk
Spending on the requirements, possibly Python and TKinter?

------
aaronbrethorst
native apps.

~~~
vijaybritto
I'm asking for productivity. I want to develop for 3 platforms and I don't
have a lot of time!

~~~
Artemix
I think that .NET Core have a stable UI kit.

Else, my favourite solutions are Kotlin/TornadoFX/Java/JavaFX.

~~~
neilsimp1
> I think that .NET Core have a stable UI kit.

It does, Avalonia:
[https://github.com/AvaloniaUI/Avalonia](https://github.com/AvaloniaUI/Avalonia)
It looks like a pretty promising project.

There was another one I believe I saw on HN a while ago but I can't seem to
find it.

~~~
jetti
Avalonia is not stable and is in beta. I would not use it for production.

