I struggled between Flutter and Electronjs, checked at Tauri too.
Electronjs does the 3 Desktops (linux,windows,macos).
Tuari is new, serves the same user base, smaller, but you need learn Rust.
Flutter does 3 Desktops and 2 Mobile platforms(android,ios), but you need learn Dart.
While doing my own research, I eventually chose Flutter, reasons are:
* it does 5 platforms fairly well
* its user base keeps rising rapidly over recent years
* dart is very much java|c++|javascript syntax alike, just simpler, picking up dart at least is much easier for me comparing to Rust.
There is also a brand new one called Socket which is similar to Tauri but doesn’t require knowing any Rust. It does all 5 platforms and it’s just pure HTML, CSS, and JS. It’s announcing a stable release on the 15th.
You should probably disclose that you're the primary developer.
The name seems like a terrible idea, as it's so generic and unsearchable. It will be hard to find help with things, even if it becomes more widely used. The peer-to-peer stuff seems interesting, but the documentation is incomplete. Elsewhere the documentation says "It’s built from scratch, 1000 lines of code", but it's way more than 1000 lines (and it would have to be).
Electron, Node, and Bun are also pretty generic and unsearchable. As to the rest of your comment, the p2p component is less than 1000 lines of code. And, as I said it hasn't had an official release yet (due on the 15th).
But socket already has a well-established meaning in software. I think even if you succeed with that name, it will be at the unnecessary cost of making network programming more difficult for everyone. It's easy to choose a unique name (even "SocketEngine" might do), and now is the time to do it.
Oh, that component is <1000 lines, got it.
Whether or not it's officially released, you are already promoting it as an alternative to much more established options, so you should expect people to compare on the same terms.
We've set expectations very clearly in that it's pre-release status with the intent to compete with Electron and similar projects. Node is an extremely common word in software for example, but it's not a problem because people generally apply context to their searches.
I don't see the problem with using Flutter. It has proper support from Google for all the major OSes for both Desktop and Mobile. A worthy and serious alternative to both Electron and React Native. It sits in the middle of being faster and smaller than Electron, and being more easier to pick up than Rust with Tauri.
I would rather build a desktop and mobile app using Dart with Flutter than with Rust using Tauri, especially with in a defined deadline or a rewrite.
The most popular one I have seen is Indian Google Pay (which is different from global Google pay afaik) and that app has terrible performance even on a high end device like Pixel.
Coin by Zerodha (India's biggest stock broker) is also on Flutter but again, has sluggish scrolling.
Curious if this is true for other Flutter apps in the wild or just my experience.
https://flutter.dev/ does have an impressive list of apps, though I'm unaware any existing long-standing popular apps are rewritten in Flutter, it's more about 'if you want to write a cross platform apps today, which framework you will pick'
I had the same thought until one day I tried to use it to do some quick Dart coding, turns out it is very easy comparing to other languages, and it has sound null safety too, all syntax are pretty much the same as C, I like it and I hope its popularity will increase.
wails2 has room to improve and I think it will be done in wails3, also it does not have mobile support yet, both Tauri and Wails might add mobile support in the future, using webview underneath.
The UI is built with Flutter but you don't write any Dart. They ship flutter wheel in python and they plan to support other languages like "Go, C# and others are coming next"[0]
I'm not aware of any browser engine restrictions on Android / Google Play. If Electron isn't running on Android, it's probably because the Electron project has chosen not to do it.
But since there are restrictions on iOS, maybe it's less appealing to bother with Android? (You'd want to be able to say you support both mobile platforms, but you wouldn't be able to. And there wouldn't be a path toward doing that that's within your control.)
Honest question, when solutions like https://github.com/tauri-apps/tauri exist out there that promise smaller build sizes and similar developer experiences, are folks still using Electron to build new apps?
I’ll reply to your question with a question: once VSCode has proved one could build hyperscale complex apps that perform well, would you be fast to bet for less proven tech?
I’ve had a great experience using VSCode on occasion (I’m a JetBrains guy), and loads of other people, including some great programmers, rave about it. I’ve similarly had a fairly solid experience with Spotify desktop across different platforms.
I’m asking genuinely, is it such a subpar choice when there’s such proven success cases?
I don't think you realize how slow those are, how slow they make your entire machine (eating the RAM for no good reason) and how insanely fast similar apps could be if written in something that doesn't involve massive bloat.
Electron is also how Microsoft essentially broke Skype (on purpose?) IMO.
For me Electron just stands for lazy companies/devs who are not interested in producing something elegant that runs as fast as possible.
> I don't think you realize how slow those are, how slow they make your entire machine (eating the RAM for no good reason)
You're on a forum full of software developers, I think you can give us credit for knowing exactly how much resources the apps we use take up.
Personally, I frequently run VSCode, Slack, Zoom, Chrome, and occasionally Loom at the same time on a machine with 8gb ram and it's fine. Until one of these new platforms like Tauri or Socket.sh catches up, the trade off for developers being able to develop once and run on multiple platforms is entirely understandable and clearly acceptable to most people.
Cool. I'm a single developer releasing software for free which is only made possible by Electron and wouldn't exist without it but I guess I'm just lazy.
Honest question: where does all the RAM go? If a chrome tab eats about 200 MB ram, shouldn’t an electron app consume about the same? After all Electron is just an SPA with all the assets packaged with the browser engine. Like the zip’d web archives of yore
Chrome engine is build for browsing the web multiple windows multiple tabs etc.
If you drive with a empty truck with trailer it uses more oil than a car.
Chrome is not designed for this. There are other engines like https://sciter.com that are work for single apps, but probably scale bad if they are misused as a browser.
I just opened Chrome to a news website and got 400MB of usage on the "GPU Process", 150MB on the "tab" process, and 100MB on the "browser" process. In Electron the webpage doesn't have access to native APIs like the system tray, so that's done by exchanging messages with an extra process.
The ones of these I've actually used like Slack are doggie doo. Aside from using way more resources than a chat app should, last I checked basic UX was not close to on par with native, like right mouse clicks didn't do anything but bring up the built in browser menus.
I don't mind using an Electron app. The problem is, they are multiplying too fast. I currently use: 1Password, VS Code, Discord and / or Element, Obsidian, and Postman. They use most of the machine's resources doing nothing at all.
You can also see the pains the Evernote team took from the initial Electron-based 10 release until it became usable again. But you could also feel the product moving again after stagnation on a gazillion native clients. It was the right albeit mostly final engineering decision they took.
"Powers" being a relevant word here. People love to call out various tech/choices for needlessly sending our energy into a black hole, has anyone run the numbers for Electron's negative impact versus a non-wasteful solution?
> VSCode has proved one could build hyperscale complex apps that perform well
did it though? It might perform "good enough", but its still an order of magnitude worse than native solutions. the only reason to ever use Electron or similar is for rapid prototyping. once you have an MVP, you should immediately work towards a native solution. people seem to forget that part, out of laziness or ignorance.
I use VS Code daily and I have never had performance issues. That obviously doesn’t apply to all folks.
Also, it seems presumptuous to prescribe what appropriate solutions are for all people of all time. There are many, many places where an electronjs would be just fine.
> Also, it seems presumptuous to prescribe what appropriate solutions are for all people of all time. There are many, many places where an electronjs would be just fine.
And many where it wouldn't. It seems more presumptuous to me to demand that users have machines with that much memory and CPU to spare.
You have to define ‘worse’ because raw performance isn’t really everything and vscode’s popularity proves it.
Feature set and extensibility have clearly won here. At a certain performance point, it’s good enough and what you can do with it matters more.
I’m not sure you could achieve the sane flexibility in a more native, “bare-metal”, development environment. Possible, yes, but it would probably not be as successful as developing for it would be somewhat harder.
Vscode is “fast” enough. Its extensibility and its ecosystem are what makes it so popular and successful.
I’m not sure you can build the same without trade offs.
> once you have an MVP, you should immediately work towards a native solution.
All of the chat apps that worked towards a native solution have died. Most of the other apps too, but all of the chat apps. Going native, despite being satisfying for the user, carries a maximum cost in terms of internal organization (several departments in the company for each target OS), HR (developers that can’t be recycled in other departments), marketing: “Wait, does HipChat MacOS has the same features as HipChat-on-the-mac-but-in-browser? Wait it doesn’t matter, HipChat is dead.”
Telegram, which is easily the best chat app by software quality, has native apps on all platforms (well, QT on desktop, but that’s close enough). iMessage is native as well, and widely used, though it has admittedly fewer target devices. Those are the two I use daily, so I definitely don’t live in your Electron world, and I’m happy for it.
They do have a native solution you might be familiar with, "Visual Studio". It took them a solid decade to port it even from 32->64 bit (finally released last year). Hard to blame them for some institutional PTSD around the whole idea of native apps.
- Not everyone wants to learn Rust but want to use the same language throughout their stack
- Tauri is still new which means it is not considered "tried and true"
- More developers know how to use Electron or at least know enough Javascript to learn which means larger talent pool = cheaper and easier to replace developers if need be
- Last I checked (was not recently I admit), the build time for Tauri was abysmal
- I would argue very few gives a damn about smaller build sizes unless the problem space actually requires size to matter
In short, Electron is established tech and "good enough" while Tauri is the new kid in the block. It takes time for it to carve a space for itself. With all the Rust hype going on, I don't doubt it will happen.
Fun fact: I actually embarked on a project recently where my plan is to build the app in Electron first and once I had a change to learn Rust, I'll probably try to migrate the Electron app to something like Tauri.
A reason to keep using Electron rather than Tauri is when you need to make sure the UI is going to be displayed the same way on each platform.
Tauri uses the OS's native webview which means that there can be differences in how the DOM is displayed. It's not the same browser engine being used for each platform.
One problem with Tauri is that it doesn't bundle Node runtime, meaning that you can't take advantage of the npm packages that works outside of a browser environment. It does allow you to use Rust packages, but that's another story than Javascript.
Yes. As a user, I’m rooting for Tauri, but as a developer, I could probably build my app faster using Electron. Unfortunately, past experience tells me that companies usually optimize for ease of development instead of performance, most of the time :(
It was just open sourced, if your pointing out how few stars it has. It also hasn't been officially announced. But HTML, CSS, and JS are far less niche than Rust.
Electron is very well known & has a large footprint - lots of existing tutorials, extensions/plugins/libraries, regular bug fixes. There are also lots of existing large Apps that can serve as reference. If you Google - building cross-platform desktop Apps, most of the results will point to electron.
If you already know JavaScript (lots of people do) & are trying to quickly get your App up & running, then it can make sense to just go with Electron rather than trying to learn a new language like Rust.
Yes, Electron Apps are big but in the grand scheme of things, they might not matter so much for now (laptops are being built with bigger memories, Apps are being improved to manage memory).
It's not really the same developer experience. Because it's a browser JS engine it's much less powerful than electron, and you need to write more rust as a result. For many people that's probably not a demerit but for others it will be.
There is something to be said for a unified frontend and backend that closely mirror the existing browser API just extended. It comes with it's downsides too, where Tauri obviously shines, but really I see Tauri and Electron as two different approaches not direct competition. Last I checked Rust was still the only native backend too, that changing may help its story. Of course there is always the ecosystem size difference too but that normally sorts itself out with time.
I tried using Tauri (about 6 months ago, so things maybe have improved), and found lots of inconsistencies and issues between platforms. It did work well on my "dev platform", but then things often misbehaved on other platforms.
I'm not sure many people are refusing electron apps due to the size, but they would definitely reject a buggy app that didn't work on their platform.
Unfortunately despite Tauri being very performant, small, and having good UX it looks like most projects are still using Electron. I've built a prime number calculator which draws a graph in the webview using Tauri [0], this has was part of a series of projects of mine that calculated prime numbers and displayed them to compare performance of browsers and backend languages. The application does all the calculation in Rust and I got to say I will never ever go back to even considering Electron again.
I believe the reason why people look to still be using Electron is simillar to why people use React. Sure it's a bit bloated, a bit hard to master, it has some design flaws, but it's well adopted, and hundreds of successful companies use it in production. Meanwhile Tauri is rust the new kid in the block.
Tauri and similar are only as good as the webviews on the system. My trials with webview based alternatives showed they use slightly less ram as electron at startup, but later use more memory and perform worse in FPS. (Linux)
Not really seeing an advantage other than a smaller binary.
I don't underestimate the sheer amount of cognitive effort, money and time needed to maintain native versions of software. Or to build a desktop application at all!
From my perspective Thunderbird, IntelliJ, Firefox, Chrome are extremely complicated pieces of software. My initial exposure to Qt is that it is a very difficult framework to use properly to build nontrivial applications. Not only do you have the barebones complexity of C (build everything yourself) or the overwhelming complexity of C++ (there's many ways of doing the same thing) you also have a graphical GUI framework AND a platform API to work with. It's simply a lot of moving parts.
I've written a few Java SWING GUIs and an electron app but I wouldn't want to use a low level programming language to build a GUI.
I love HN because it opens up a dichotomy of views.
Optimistic: It is cheaper, as in time and cost, way to build products that users can enjoy and newer developers that only know web technologies can tip toe into platform apps.
Pessimistic: It’s not optimal and eats resources.
Me: I use it to build internal tools and don’t work on a potato so it can have all the resources it wants with my overkill machine.
What really gets me is using web technologies in operating systems. Press the Windows key in Windows 11, and watch the start menu crawl & flicker up the screen. It should be rendered natively & buttery smooth. But no.
I'm not sure if the use of web technologies in the start menu is the cause of this. I thought it had to do with their search indexing or the lack of it so it winds up crawling a bunch of unindexed folders every time you open the menu.
Electron Fiddle is cool and the sort of thing that helps Electron maintain its lead over other frameworks, but it doesn't take you all the way through a project to the point of distributing your app. It helps you figure out how to make an app that starts up and does stuff, but, then you're on your own again. That's often where the pain really starts, as the most common tools are mostly thin wrappers that just map JSON to command line flags for the native toolchains on each platform. Or for Electron you end up being pointed at a lot of not fully maintained tools, custom update servers etc. Abstraction and convenience are minimal, cross-packaging painful or outright impossible. This is a problem not only for Electron; Flutter, Tauri, Jetpack Compose for Desktop, JavaFX/Swing etc all suffer the same issues.
There's another way to get started: grab Conveyor [1] (disclosure: my company makes it) and run
conveyor generate electron com.example.my-project
Then run "npm install" inside the generated directory. You can now hack on your app, add modules and so on, make a few edits to the conveyor.conf file and then run one command to create and upload packages for each OS. Signing and notarization are also handled even if you're on Windows or Linux.
It works for real production-grade apps; there's an example of packaging GitHub Desktop [2] which covers more advanced stuff like registering URL handlers (deep linking), Windows notification callbacks and so on. Also works for Flutter [3] and native apps.
Finally, for people asking "Why Electron", the answers are pretty simple: Google invests a ton of money in Chrome, and the multi-vendor nature of HTML makes it largely immune to rewrites and platform churn of the sort that affects Windows, Linux, macOS, iOS and Android. It's got its problems but stability+investment isn't one of them, which is why there are so many developers who know it.
What exactly makes the average Electron program so goddamn awful? Does the Javascript language inherently result in a bloat runtime? Are the runtimes accidentally bloat? Is it all the browser stuff and not the JS runtime per se? Or maybe just bad programming on the dev side?
its a massive embedded browser. imagine if every app you opened on your computer was a separate process running chrome? thats more or less literally what electron is.
“Does the Javascript language inherently result in a bloat runtime?“
No
“Are the runtimes accidentally bloat?”
Not accidentally
“Is it all the browser stuff and not the JS runtime per se?”
Basically, yes
“Or maybe just bad programming on the dev side?”
No
Essentially the reason Electron apps are so heavy is they run on a browser, not on an operating system.
In the beginning, programs ran directly on hardware, and things were good. (e.g. Pretty much every game would ship with a custom bootloader that knew how to address the hardware and exposed this to the program, you didn’t - couldn’t - have anything else running at the same time.)
Later on, programs ran on the operating system, and things were okay. Operating systems abstracted over all the possible hardware configurations in an acceptable way and users got the benefit of running multiple programs simultaneously without too much of a performance cost.
Now, programs run on the browser, itself a program running on the operating system. Because the browser wants to be a platform for any other program, it has to hook into almost every part of the operating system, so that it can support almost any program. This necessarily brings with it enormous bloat - in effect you’re running one general-purpose pseudo-OS framework per program.
At places I’ve worked there have been discussions about whether to use Electron. Something one dissenter said has stuck with me. “Imagine every Python module you imported ran in its own Docker container. You would quit, but that’s what we’re asking of users.”
Browser performance is actually very good. Its runtime js engine is heavily optimized. Same for the render. Wether its the dom node render or canvas one. They can be very fast. Certainly possible to write native like apps.
The problem are those libs . In this case electron. There are a zillion parsers and inefficient steps in every app code execution path i see.
Mainly the fact you have to run an entire browser (= more memory usage, slower startup time) and that it runs on HTML + JS, which is very slow compared to fully-compiled languages like C, C++ or Rust.
Please can Electron die already? Almost every Electron program I use could be a PWA. Slack has no reason to need another browser engine running. You could make a point for native integration, but there is none. And all it does is display text (and images). What a world we live in. Worse is better, amirite?
It might if Apple or Microsoft provided good frameworks for building native apps.
I read a comment[0] by a developer who used SwiftUI for his app
> What took me 15 minutes on the web, it could take a day on SwiftUI.
It's just not possible for indie devs (or startups) to put that sort of time into native apps. Not to mention SwiftUI is still extremely broken despite being available for 3 years. Quoting from that article
> Every major iOS / macOS upgrade, I have to refactor my code because something crashes the new version. Imagine this happened on the browser.
At this point, unless Apple and MS provide a good component based abstraction for building native UIs (SwiftUI is a step in that direction) developers will keep going to Electron and other alternatives which let them write React (or svelte or even Flutter in the non-web land -- anything that lets them get actual work done)
I find all this hate rather bizarre. Why do you even use the electron versions instead of opening things in browser tabs? I find all this hate rather bizarre.
Err, tray icons? Filesystem access/watches? Registry? Process API? Native plugins? If _every_ Electron program you use could strictly be a PWA, that says more about your usage than Electron itself.
Electronjs does the 3 Desktops (linux,windows,macos).
Tuari is new, serves the same user base, smaller, but you need learn Rust.
Flutter does 3 Desktops and 2 Mobile platforms(android,ios), but you need learn Dart.
While doing my own research, I eventually chose Flutter, reasons are: