Electron Fiddle: Get started with Electron | Hacker News Reader

Electron Fiddle: Get started with Electron

electronjs.org

136 pointslegrande99 comments

Open articleView on HN

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.

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.

I see one huge problem with Flutter. It's supported by Google. And uses Dart, which is also supported by Google. And sees very little use outside it.

Agreed; Dart seems like a dead end, let alone compared to Rust or Go.

golang is also by google the same as dart though

Yes, but unlike Dart, Go has at least modest mainstream adoption.

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.

Being a nice language, is secondary to working.

I thought Dart was close enough to Typescript to be fairly familiar (and thus less risky than a more novel language)?

The lack of native scrolling really kills it for me.

Something just feels "off" when using a flutter app.

Are there any popular Flutter apps in the wild?

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'

May I add https://flet.dev Uses python & flutter. And https://wails.io Uses Go.

Is there any good comparison wrt to Wails and Tauri? Or is the only difference between the two is that the backend is different?

They both use the OS' WebView to render the frontend. I only used Wails (I already knew Go) and used it to build simple desktop apps.

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.

just played with flet, don't know why it mentions flutter in its home page as I saw nowhere flutter|dart is involved.

a helloworld python single binary is 28MB with pyinstaller, c libraries are shared and it is not a static executable.

it uses gstreamer underneath? not sure what that means, do I need gstreamer preinstalled on the platforms?

this seems like yet another Python based GUI framework to me(e.g. a new Tkinter), or I'm missing something fundamental.

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]

[0] https://flet.dev/roadmap

so this is basically a flutter that does not use Dart? this is something major then.

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.

https://github.com/socketsupply/socket

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.

make sense to me, node/bun/electron are common words but not so common in software, socket is a well known software term.

I still have no idea how the "socket" magic works, need to be convinced, till then I will stay with flutter for now.

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.

Let’s hope the regulators recent attention to Browser engine restrictions will allow Node.js and Electron to run on IOS and Android.

Would be fantastic especially for smaller software development companies that cannot afford to fund 3 dev teams.

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.)

Flutter is unsuitable for anything that runs on battery and needs text input.

https://github.com/flutter/flutter/issues/59327

It's insane that this bug is still unfixed.

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?

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.

[0]: https://github.com/DoodlesEpic/GraphPrime

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.

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'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.

Yeah Tauri is in Rust, whereas I want to write the backend and frontend in the same language (TS) and share code

Rust is a non-starter for the majority of web devs. That’s why Tauri had remained niche.

Maybe try https://github.com/socketsupply/socket

> That’s why Tauri had remained niche.

> try https://github.com/socketsupply/socket

Points to an even less popular niche.

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.

Correct. This is objective.

I'm pointing the inconsistency of the argument.

If you want popularity, there is already Electron.

I've heard of electron, but not tauri. Maybe it's just not known enough to be included in the decision?

Same. I figured I could be out of the loop but ... so are other people.

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.

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?

> 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.

What's your theory on why the VS Code team haven't migrated to native solutions for their app?

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.

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.

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.

No one is demanding anything. VS Code exists. Lots of other code editors also exist. Many are native. Choose whichever one you want.

I did use it and find it subpar to JVM based IDE (namely Jetbrains). Yes, both are memory hogs, but Jetbrains feels smoother.

> 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.

What are the 'native solutions'?

Also: Figma, Linear, Notion, Slack, Superhuman, Pitch, Loom. All Electron.

I’ve never understood the hate Electron gets on HN, when it powers so many great products that users love.

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.

>like right mouse clicks didn't do anything but bring up the built in browser menus.

You should try this in slack again...

That UX decision has nothing to do w/ Electron.

If someone brings up a single example they should ensure it aligns to their criticisms, as a rule.

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.

Slack took great pains to make the client not be a memory and CPU hog.

Still better than Teams though. (Which is also in Electron.)

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.

It surely was the right decision, but it came too late.

Also, still the app is almost worthless on my Android phone. Too slow, despite large improvement.

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.

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.

> 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.

Fully agree on all points, I've never had a performance issue with Electron.

I have had Slack fill my home directory with logs once , long time ago. But that wasn't an electron problem.

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.

You're lazy and you should feel bad! /s

"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?

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.

Both reasons were why I picked electron to build https://nocommandline.com

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).

Here's a couple

- 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.

If the OS webview gets breaking changes your tauri app breaks too.

Electron bundles the browser therefore the size.

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.

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.

Spoken like a dev, not a user. Try using older hardware if you really want to understand the other side.

Yep! For another area, it’s very difficult to use any Electron app with OS-built-in voice control, while almost all native apps work fine.

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.

Guess I’m somewhere in the middle lol.

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.

[1] https://hydraulic.software/

[2] https://hydraulic.software/blog/8-packaging-electron-apps.ht...

[3] https://hydraulic.software/blog/10-flutter.html

My biggest turn off with learning to use electron was wiring everything up.

Maybe it’s my fault for thinking things would be as easy as Winform and Xaml, but this sounds promising.

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.

That’s just what opening a new tab in your web browser is.

Dedicated Electron-based apps are even worse than that: a separate set of processes running their own embedded version of Chrome.

“Does the Javascript language inherently result in a bloat runtime?“

“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?”

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?

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.

Some apps only come as Electron apps with no web version.

Good luck releasing a PWA on Steam. Do you think Vampire Survivors would be so popular if it only existed as a web page?

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.

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)

[0] https://www.indiehackers.com/post/i-made-session-a-productiv...

Reply on news.ycombinator.com