9 ms·

Electron Fiddle: Get started with Electron

136 points by legrande 4y ago

zhs 4y ago
Honest question, when solutions like https://github.com/tauri-apps/tauri 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?
- doodlesdev 4y ago
  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 https://github.com/DoodlesEpic/GraphPrime
- zamadatix 4y ago
  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.
- aliencat 4y ago
  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.
  - schemescape 4y ago
    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 :(
- stu2b50 4y ago
  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.
- timcobb 4y ago
  Yeah Tauri is in Rust, whereas I want to write the backend and frontend in the same language (TS) and share code
  - heapwolf 4y ago
    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 https://github.com/socketsupply/socket
    - Ygg2 4y ago
      > That’s why Tauri had remained niche. > try https://github.com/socketsupply/socket https://github.com/socketsupply/socket Points to an even less popular niche.
      - deleted 4y ago
        [deleted]
      - heapwolf 4y ago
        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.
        bitfracas 4y ago
        Correct. This is objective.
        Ygg2 4y ago
        I'm pointing the inconsistency of the argument. If you want popularity, there is already Electron.
- mysterydip 4y ago
  I've heard of electron, but not tauri. Maybe it's just not known enough to be included in the decision?
  - david422 4y ago
    Same. I figured I could be out of the loop but ... so are other people.
- rizky05 4y ago
  [dead]
- nassimsoftware 4y ago
  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.
- aerhardt 4y ago
  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?
  - 2h 4y ago
    > 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.
    - simonw 4y ago
      What's your theory on why the VS Code team haven't migrated to native solutions for their app?
      - AlotOfReading 4y ago
        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.
    - Renaud 4y ago
      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.
- nocommandline 4y ago
  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 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).
- tomkarho 4y ago
  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.
- croes 4y ago
  If the OS webview gets breaking changes your tauri app breaks too. Electron bundles the browser therefore the size.
- CJefferson 4y ago
  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.
- mmgutz 4y ago
  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.
yazzku 4y ago
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?
- cultofmetatron 4y ago
  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.
  - Hackbraten 4y ago
    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.
- fwlr 4y ago
  “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.”
avx56 4y ago
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?
- deleted 4y ago
  [deleted]
- oblak 4y ago
  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.
  - speps 4y ago
    Some apps only come as Electron apps with no web version.
- Kiro 4y ago
  Good luck releasing a PWA on Steam. Do you think Vampire Survivors would be so popular if it only existed as a web page?
- ninepoints 4y ago
  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.
- jatins 4y ago
  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-productivity-timer-that-makes-5k-month-in-net-profit-ama-25b59d75f5 https://www.indiehackers.com/post/i-made-session-a-productiv...
synergy20 4y ago
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.
- garyclarke27 4y ago
  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.
  - adrianmonk 4y ago
    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.)
- gl-prod 4y ago
  May I add https://flet.dev https://flet.dev Uses python & flutter. And https://wails.io https://wails.io Uses Go.
  - stoicjumbotron 4y ago
    Is there any good comparison wrt to Wails and Tauri? Or is the only difference between the two is that the backend is different?
samsquire 4y ago
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.
- jiggunjer 4y ago
  Spoken like a dev, not a user. Try using older hardware if you really want to understand the other side.
  - gbear605 4y ago
    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.
PriceDev 4y ago
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.
- trollied 4y ago
  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.
  - throwaway4aday 4y ago
    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.
pipeline_peak 4y ago
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.
mike_hearn 4y ago
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/ https://hydraulic.software/ [2] https://hydraulic.software/blog/8-packaging-electron-apps.html https://hydraulic.software/blog/8-packaging-electron-apps.ht... [3] https://hydraulic.software/blog/10-flutter.html https://hydraulic.software/blog/10-flutter.html

136 points by legrande 4y ago

zhs 4y ago

Honest question, when solutions like https://github.com/tauri-apps/tauri 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?

doodlesdev 4y ago
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 https://github.com/DoodlesEpic/GraphPrime
zamadatix 4y ago
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.
aliencat 4y ago
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.
- schemescape 4y ago
  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 :(
stu2b50 4y ago
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.
timcobb 4y ago
Yeah Tauri is in Rust, whereas I want to write the backend and frontend in the same language (TS) and share code
- heapwolf 4y ago
  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 https://github.com/socketsupply/socket
  - Ygg2 4y ago
    > That’s why Tauri had remained niche. > try https://github.com/socketsupply/socket https://github.com/socketsupply/socket Points to an even less popular niche.
    - deleted 4y ago
      [deleted]
    - heapwolf 4y ago
      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.
      - bitfracas 4y ago
        Correct. This is objective.
      - Ygg2 4y ago
        I'm pointing the inconsistency of the argument. If you want popularity, there is already Electron.
mysterydip 4y ago
I've heard of electron, but not tauri. Maybe it's just not known enough to be included in the decision?
- david422 4y ago
  Same. I figured I could be out of the loop but ... so are other people.
rizky05 4y ago
[dead]
nassimsoftware 4y ago
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.
aerhardt 4y ago
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?
- 2h 4y ago
  > 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.
  - simonw 4y ago
    What's your theory on why the VS Code team haven't migrated to native solutions for their app?
    - AlotOfReading 4y ago
      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.
  - Renaud 4y ago
    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.
nocommandline 4y ago
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 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).
tomkarho 4y ago
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.
croes 4y ago
If the OS webview gets breaking changes your tauri app breaks too. Electron bundles the browser therefore the size.
CJefferson 4y ago
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.
mmgutz 4y ago
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.

yazzku 4y ago

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?

cultofmetatron 4y ago
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.
- Hackbraten 4y ago
  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.
fwlr 4y ago
“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.”

avx56 4y ago

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?

deleted 4y ago
[deleted]
oblak 4y ago
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.
- speps 4y ago
  Some apps only come as Electron apps with no web version.
Kiro 4y ago
Good luck releasing a PWA on Steam. Do you think Vampire Survivors would be so popular if it only existed as a web page?
ninepoints 4y ago
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.
jatins 4y ago
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-productivity-timer-that-makes-5k-month-in-net-profit-ama-25b59d75f5 https://www.indiehackers.com/post/i-made-session-a-productiv...

synergy20 4y ago

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.

garyclarke27 4y ago
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.
- adrianmonk 4y ago
  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.)
gl-prod 4y ago
May I add https://flet.dev https://flet.dev Uses python & flutter. And https://wails.io https://wails.io Uses Go.
- stoicjumbotron 4y ago
  Is there any good comparison wrt to Wails and Tauri? Or is the only difference between the two is that the backend is different?

samsquire 4y ago

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.

jiggunjer 4y ago
Spoken like a dev, not a user. Try using older hardware if you really want to understand the other side.
- gbear605 4y ago
  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.

PriceDev 4y ago

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.

trollied 4y ago
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.
- throwaway4aday 4y ago
  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.

pipeline_peak 4y ago

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.

mike_hearn 4y ago

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/ https://hydraulic.software/ [2] https://hydraulic.software/blog/8-packaging-electron-apps.html https://hydraulic.software/blog/8-packaging-electron-apps.ht... [3] https://hydraulic.software/blog/10-flutter.html https://hydraulic.software/blog/10-flutter.html