I chose Electron for the app I was building because it would make sure the app I create (1 code base with Angular) would perform exactly the same way on Mac, Windows, and Linux. It required virtually no learning of anything new (just look up some Electron API like "minimize window") and I was done.
As a single developer, I was able to get an app out in a few months and have been improving it for 4 years now. I love it (enough to create a Renamer app too: https://yboris.dev/renamer/ ).
> I have a hard time understanding why platforms like electron are so popular.
For an example. I'm writing a FOSS app mainly for myself, but i am publishing it for everyone of course. I want to support Browsers, but also "Apps" in OSs. I'm on Linux, MacOS, Windows and iOS every day.
I do not, by a large margin, have the time to write my application in 3 or 4 different native UI toolkits. Furthermore, my application has a lot of text editing and rendering functionality, one i'd have to then reinvent in various UI toolkits, unless i used something that crossed all OSs above perfectly. Finally, my app has WASM plugins, similar to Obsidian.md, to allow the user to easily extend the application.
All together i will not, by a large margin, use anything Native. I barely have enough time _(don't, honestly lol)_ to write the app once - let alone supporting all the above platforms.
I'm targeting the web.
As an aside, i'm writing this in 100% Rust lol. No JS, because i prefer Rust.
Aside from the improvements to project timelines, Electron and similar products are popular because they improve the developer experience, and in 2022 the developer experience is what matters the most to many software companies (yes, in many cases ahead of the customer experience).
DX directly drives engagement and retention, and good developers are hard to find (and keep!).
And like it or not, there are more and more developers entering the industry with web-only training, so we have products that reflect the stack and tooling those developers are most proficient with.
It's not just the developer experience, in fact that is probably lower on the priority than you would think. The entire business IME struggles to reason about a product, in the details, that is logically 1 product but physically N products by virtue of all the different target platforms and codebases required.
JS DX always seemed really quite bad whenever I looked. A constantly shifting landscape of frameworks and packages where nothing will stand for long before being eroded away.
> Let's just imagine for a while what UI would look like if we only had Swing (Java) or QT (C++)
I can easily imagine that, because that's more or less what we had before Electron. And it was much better, because apps (mostly) looked consistent across the OS, rather than each and every one coming up with its own custom UI theme.
At least for Qt, the answer's quite simple: you'd have KDE and the associated apps.
As for the stability of the front-end ecosystem, it doesn't exist. The many articles that were posted on HN over the years complaining about the endless quagmire of front-end frameworks, libraries and technologies explain this better than I could.
if you like the pricing and licensing, functionally QT may be for you. The web frameworks mentioned on the other hand are free to use for everybody and anything.
Qt is LGPL. You know what else requires you to respect the LGPL ? Electron becauses it is built mainly on LGPL components (Blink, FFMPEG to name the biggest ones). If you are ok with the license of Electron you are ok with the license of Qt.
The MIT license only covers what Electron adds to Blink (the rendering engine, which is under LGPL). It does not replace all the licenses of the various components used as part of Electron for which you still have to comply.
That is the exact same license than Qt, you do not need to expose your IP when using it (Tesla used LGPL Qt for their car dashboards and you don't see that IP floating around on the internet)
> Electron and similar products are popular because they improve the developer experience
> more and more developers entering the industry with web-only training
aren't these very different things? Is Electron popular because web-skill are so common, or because the dev experience is better - I sceptical of the latter, as I find JS very dependant on framework/ecosystems for compatibility.
Sorry if I implied those were tightly coupled. I do think they are related but more loosely than perhaps I meant, and not exclusively.
Electron improves DX for all the usually stated reasons (build once for many platforms, etc) but I do think there is a connection to the fact that a lot of developers out there are learning web tooling, and if a company wants to put out a desktop app in 2022, it's an easier (and therefore better for DX) path to use something like Electron or Tauri - where devs can use the skills they already have - than try to either upskill or hire a team that can build native apps on all your desired platforms.
We built our product for the web. People wanted our product as a desktop app. So we wrapped it in Electron and now we have 3 desktop apps. People wanted our product as a mobile app. So we wrapped it in Capacitor and now we have two mobile apps.
> So efficient for you, but 1000x more resources everywhere it runs.
And yet, to the people who do use their app on the desktop, this is obviously a preferable situation to not using the app – which would probably be the case had the developers decided against Electron.
And yet, we have single indie developers writing multiplatform Qt [1] and macOS native [2] Slack apps. Last time I checked, Ripcord used 30-40MiB RAM, a small fraction of the official Slack client.
Writing native apps (or a Qt app) would well be in reach of Slack. In fact, they already have native apps. E.g. Slack for iOS/iPadOS is native [3], just allowing M1 Mac users to use the iPadOS version would most likely be a large net improvement in resource use for those who'd choose to install the iPadOS version. Unfortunately, they disallow iPadOS installs on macOS to force people to use the terrible Electron version.
Exactly this is what I don’t get. Huge corporations are so hard for cross-platform development while Facebook, Google, Microsoft et alia could just spawn as many developer for a new platform as they can. I know that management is trying to cut back on every single penny, but is financing React Native really that much cheaper than just writing that tiny amount of code for each platform that will call into that single native library/web API used everywhere? Especially when you have to have a native dev either way because bugs will happen that will need platform-specific knowledge as well.
Because I can honestly understand going cross-platform by a small startup that can’t finance n*numOfPlatforms devs, but for Slack and the like it makes zero sense to me.
It's amazing how bad the options for native UI frameworks are, even without considering cross-platform, more so once you do. Android is actually decent but with caveat it only works on Android... Windows had a decent WPF but then they came up with 5 other framworks that got rebranded and now nobody knows what to use anymore. Is WinUI the latest and greatest there? Wouldn't be cross platform anyway.
Perhaps Unity? But that's more tailored for 3d scenes, rather than UI widgets.
Genuinely looking for suggestions on what is the best choice to pick there.
Given that there's no other language that works cross-platform with as little jank as JS, I don't think that distaste is adequate reason to avoid using it
While I agree that maintaining one codebase is preferable, the 'teams' part is a bit off.
No-one wants 'three teams building one product' which is why it almost always is far better to have one team with android, iOS, web and desktop mixed. Obviously if their mixed erpertises are around one codebase, that is even better.
> It makes perfect business sense to use electron.
In many cases, it should also make perfect business sense to use PWAs. I've heard Adobe has brought a significant part of the Photoshop and Illustrator functionality into their web apps.
> I've heard Adobe has brought a significant part of the Photoshop and Illustrator functionality into their web apps.
This is true. We managed to wrap a very large portion of the desktop code base into a “portable” library (with some customization at the point the library hits the OS, e.g., file IO.) This library is compiled specifically for the OS it’s going to run on (iOS, Web) to give us the best performance we can muster.
The UI for each implementation is bespoke. This lets us build native interactions on the platforms we ship to, giving the end user the best look-and-feel for the platform they’re on. The flip side to this is development cost and time. In the long run, we believe it is worth it.
Rewriting Photoshop in Electron would have been infeasible and the performance hit a non-starter. The path we’ve taken has some trade offs to it, but is the right one given the legacy tech we have and what we want to do with it.
There's a terrible performance regression in Illustrator 26 when working with files with many objects. Works fine in 25, UI freezes for several seconds in 26.
Windows 10, pulling in part of an engineering drawing from a PDF (so many thousands of objects).
I get that it is basically an impossible problem to triage incoming issues on such large and widely used software, but my impression of the popular "community" approach is that it is useless and designed to provide an outlet for complaints rather than to identify issues.
On the Photoshop team we have dedicated staff to monitor, triage, and respond to these issues. You’re right in that we cannot address _everything_ that comes in from these boards- the sheer volume is too much. Nevertheless we do use it to identify top customer issues and our dev schedule prioritizations are influenced by them.
To wit: I’m known on the team for sussing out information from corrupted PSDs, and get called on about once a quarter to look into a bad file that’s come in. That wouldn’t happen as frequently without the community site.
(1) Branding. Businesses want their app to be thoroughly branded, so they'd rather have a canvas where they can invent their own buttons than use something cross-platform native like Qt.
(2) Hiring. Existing developer base trained on webtech. Qt is a C++ thing - there's a far greater hiring pool for webdevs than C++ devs.
(3) Ignorance. Some developers don't really know that Qt exists, or want to go through the trouble of learning it.
None of these reasons benefit the user - but Electron isn't chosen by those who want to benefit the user in the first place.
Web development tools have become fantastic UI debugging tools. You can inspect live running UI and tweak it in real time without a rebuild.
CSS is very powerful, and it's relatively easy to build complex layouts with animations. People joke how it's impossible to center things, but CSS has matured beyond that (IE is dead).
I must admit, I haven't been following Windows toolkits since MFC. I've only heard about WPF in the context of dead Longhorn features. Isn't it deprecated in favor of WinUI or whatever replaced Metro?
Officially, it isn't (e.g. it got ported to .NET Core). De facto, it is, but it still works just fine, as do WinForms, and all the tooling support is still there.
That said, I've mentioned WPF mostly because that's what I'm personally familiar with. The same inspector-type tooling is available for newer XAML-based frameworks, as well:
It is not hard for me to understand that even though I am not a client-side engineer.
Web tech (HTML, JS & CSS) are widely understood with millions of tutorial reference. On top of that, you get a cross OS build that looks the same everywhere.
If all you are paying are just CPU and RAM, then that is a great tradeoff.
"Probably"? On the contrary, the incredible complexity of the JS ecosystem makes it likely easier to write in Qt.
I've had direct experience with this myself - with no prior Qt or webdev experience (although knowledge of how JS the language works), it took me only around an hour to figure out how to write a Qt application - but after 5 hours (and counting) of struggling with Angular, I wasn't able to figure out how to use it.
I wasn't even talking about the penalty of writing a Qt application in C++.
That's a different penalty. Qt doesn't really compare with what can be done with a good UX/UI dev on the team, and in much less time. And there are far more front-end devs than Qt experts.
> Are you telling me that an Electron developer will be able to implement a system significantly faster than an equally-experienced Qt developer?
Yes. Hands down.
I'm actually saying two things: there are far fewer Qt developers, and the learning curve is much steeper. This has huge impact on maintaining and improving the code. We started with Qt and abandoned it because it is way easier to bring someone new in and get them started than having someone climb the curve to learn Qt and C++. Plus spinning up new features in Qt is laughably slow compared to how quickly a frontend dev can do the same in Electron: the former takes days, the latter is practically interactive.
It was such a clear choice to abandon Qt.
I was primarily worried Electron wouldn't last long, but we wrote our first app with it 6 years ago and it has remained completely stable. The biggest dev hits have been in Node peripheral support as they get better, like BLE and serial port interfaces.
> I have a hard time understanding why platforms like electron are so popular.
To what extent is Electron's popularity due to getting cross-platform availability without writing your code 3x?
The advantages of a native app have to be worth the costs... and I'm seeing plenty of Electron apps so there's a lot of people making that cost-benefit tradeoff.
I share the dislike for bloated apps... but every time my stuff takes 10 seconds to start up I think more about keeping it running the whole day than submitting a PR to remove cruft.
The predictions from Gary Bernhardt seem to really be true, in the future everything will be javascript.
I wonder if somebody actually tried to make an OS that only has a browser, that's what Chrome OS actually is, after all.