Electron is a widely hated framework on Linux, but what about the alternatives like Neutralinojs?
In their own words: In Electron and NWjs, you have to install Node.js and hundreds of dependency libraries. Embedded Chromium and Node.js make simple apps bloaty — in most scenarios, framework weights more than your app source. Neutralinojs offers a lightweight and portable SDK which is an alternative for Electron and NW.js. Neutralinojs doesn’t bundle Chromium and uses the existing web browser library in the operating system (Eg: gtk-webkit2 on Linux). Neutralinojs implements a secure WebSocket connection for native operations and embeds a static web server to serve the web content. Also, it offers a built-in JavaScript client library for developers.
Do you experience alternatives like Njs to blend more in the desktop layout, install less junk, use less memory, are more compatible with Wayland,…?
https://tauri.app/ is very popular and does not need electron. It uses the OS native we view.
Tau’ri, you say?
And 2.0 will support Android and iOS
I wanna use Rust to build mobile apps so bad. I don’t really know what I want to build, but I want to use Rust to do it
Reinvent Winamp for Android and iPhones.
It will?? When??
I don’t know, but probably soon. They release beta versions already.
what apps use Tauri? I only know about Dorion which doesn’t really work well from my experience
edit: ok so Dorion works well in an Ubuntu VM but it doesn’t have a build for any other distro :/ also i found this https://github.com/tauri-apps/awesome-tauri
I have been using Tauri for a personal project of mine and I absolutely love it
Came here to say Tauri.
I haven’t use any alternatives, and haven’t developed with electron, but I know that there are another alternative – Tauri. It also uses web-view. It’s built in Rust and allows apps to be developed in JS (providing JS api) and in Rust.
What I can say – JS support won’t be cross-platform, like we have with NodeJS in electron. Special debug per platform might be required.
If you need multi platform support in one codebase, Flutter is a good choice. Ubuntu uses it for their new OS installer and GUI package manager.
Quite easy to get set up on Linux (though the recommended route is using Snaps).
No waiting ages for a massive node_modules folder to fill up, nor the general pain of using javascript; dart is a really nice language to write in.
You wont get the smallest binaries with it, but it’s powerful, reliable, and pretty damn performant for a “non native” framework.
Second this. Been working with flutter and dart professionally for awhile now and it’s great
Alternative for what? I never used electron apps and I don’t see any reason for that. If you are a developer, try Qt.
Qt and Electron are different technologies that achieve somewhat different goals
Yet the telegram client is written in Qt and has great cross-platform support.
They have like 3 different, official codebases and clients (and so many 3rd party ones) for so many platforms. No other app I know of is like that, not really a great example imo
Qt and Electron are different technologies
Yes.
that achieve somewhat different goals
No.
You can’t get a website working as a “native” application with Qt, which is exactly what is Electron’s goal.
There is a browser working natively in any system. I don’t see any point in bundling a web app together with a browser and calling it a “native” app. The only difference is that you have no address bar in that case.
Which is why Electron reminds me of a little kid who’s just done some extremely difficult but utterlly pointless thing.
Websites belong in a browser. If it doesn’t work in any random standards-compliant browser, then you should be delivering it as a true native application, not some horrific fiji-mermaid-esque hybrid.
You are talking as if all people can make a native app with the same knowledge and amount of effort as it would take to develop a website.
Sometimes, web developers would want to go further with their app and deliever “native” functionality. Sometimes, a person wants to build an app but only happens to know how to build a website.
It’s a much more complicated matter than just some idiots deciding “let’s build an utterly pointless thing and then let other idiots build horrific fiji-mermaid-esque hybrids!!”.
https://asylum.madhouse-project.org/blog/2018/10/26/Walking-in-my-shoes/
Sometimes raising the barrier to entry is a good thing.
Many Electron applications I’ve run across don’t make even a try at loading system settings. For me, that causes accessibility issues related to photosensitivity. For some reason, feeling like I’ve been stabbed in the eyeball when I try to open a program does not endear me to it or its framework.
No application at all is actually better than something built on Electron, as far as I’m concerned, because then there’s a chance that someone, somewhere, might fill in the gap with software I can actually use.
Electron needs to either actually provide the basics of native functionality, or go away.
Then they shouldn’t! Just give users website and be done with it.
Now you can even allow websites work offline and install them “like” an app with proper manifest.
I’ve just tried Qt based matrix client. Compared to Electron based Element.
It’s nice, snappy, beautiful, and eats WAY less RAM. But it lacks lot of feature. That’s sad.
I’m using pywebview, a cross-platform python web view GUI framework. I like it so far, it’s fairly straightforward. I just wanted a python API around my database, and I’m building most of the app in the front-end with vanilla JS and html.
I didn’t want the (alleged) bloat of electron, and I didn’t want to jam async/await onto everything in the backend, so I found this alternative.
The 3rd contender was Tauri, but I didn’t want to bother learning Rust for a simple API. But it was very tempting, and Tauri is an option you should consider.
I haven’t finished my current project so I can’t completely vouch for pywebview yet. But so far it’s great and I recommend it if you don’t mind using python (I do long for a statically typed backend TBH).
