Learning takes time and effort, and the more general the tool I use the better.
If I had to implement a desktop app tomorrow, I would default Electron, no contest.
A bit of an aside, but I was thinking lately, it would be great for linux to have an SSD benchmarking app, just like CrystalDiskMark, I would never attempt to implement something like this in Qt or GTK, there's just too much to learn beforehand compared to simply going with CSS, wrapping the fio command in a JavaScript shell call then publishing everything as an appimage. This way I know it will work everywhere and it will have a consistent look and feel everywhere. I might actually set this up as a weekend project sometime next month. Without Electron it would take me months of intense dedicated time, which I would rather spend on something else.
Electron app memory usage: 150MB
Native app memory usage: 0 MB (because you never ship it)
really hit home for me.
Of course it does not apply to everything, some apps do need every last clock cycle of speed, but so far none of mine had.
I cloned a 165mb Electron app in Sciter, and it was only 6mb:
In fact, you can write GTK apps in JS. A year or two before Electron came along, the Gnome folks had the foresight to declare that JS would be the language of choice for promoting GTK and Gnome app development, with the option to drop back to C otherwise. This caused a minor controversy, where the community decided to rage against this effort and essentially rejected it. Here we are then, instead.
Rather than the "default" toolkit of choice in 2020 being GTK, which is cross-platform, provides an opportunity to get closer to "native", and has the roots and traditions of pre-GitHub FOSS, an vacuum was left wide open—unfilled due to the internal revolt/denial of the Linux desktop crowd. So the NodeJS and web developer community swooped in and filled it, with their dubious sui generis practices pushed to the forefront instead, and the world is shipping apps in browser runtime containers.
I'll eat my hat if it's as easy to write a hello world in GTK as it is in Electron/nw.js.
Keep in mind that with Electron/nw.js I download the toolkit binary and then simply declare an arbitrary webpage or js file filled with arbitrary modern HTML5 to be my "main" page/script. That means any frontend dev can immediately get a "hello world" running with no extra tooling and immediately access the full dev environment they are used to. Aside from the json file they don't even have to learn any of the non-HTML5 APIs (which, btw, are typically where the most nefarious bugs live in these toolkits).
What is more, the dev can immediately bring in any of the zillion frameworks they depend on to pad strings or whatever.
I'm guessing GTK has a way to hook into its own API through javascript. But if it's anything more than a single call to create a window and fill its webview with a page (or execute a js in its context), it's already more complicated and electron/nw.js wins.
Edit: typo
The fact of the matter is, ecosystem trumps everything else. For UX development, nothing comes close to javascript. The language may suck, npm is somewhat of a trainwreck, and yet, if you want any sort of esoteric component, you'll find it in JS.
It's got so many tools that it simply isn't uncommon for newer desktop apps to have embedded browser in them as an option.
Want proof?
- Show me a Lazarus native flamegraph.
- Show me a Lazarus graph library that comes close to D3
- Show me a Lazarus date picker :D
Yeah, I hate the language. I even hate parts of the ecosystem (is-even... WTF?!?!?!). However, you just have to admit that nothing comes close to the tools and widgets you get for free by adopting js. It was built for UX.
Yes I hate bloat but I'm starting to hate it less and less each day due to understanding more and more the effort required to build things (in general, not just desktop apps).
I think, unless you have the resources to dedicate yourself to just one OS/toolkit, for which your app performance is an absolute must, it's better to prioritize delivery speed and adoption, using generic tools, with plenty of resources and skills that can be transfered from other areas, like web frontend is in this case. One thing is for sure, I don't have time and resources but I have a pretty fast laptop, so the choice is easy in my case.
Not weird at all.
c'mon, getting the very basics of it in Qt took the better part of 15 minutes and less than 100loc - then it's mostly a menial "where to show which data"
I used to think this same way about things because I had so much time in the tools that I never looked at stuff from a perspective of people who have no clue.
Now that I have a friend going through coding schools and everything with zero understanding, everything I think is "just a 15 minutes of tinkering and you'll know all the bits you need" is actually 3 months of banging your head against the fucking wall.
Don't let your existing experience cloud your judgement.
I can almost guarantee you that an average frontend developer (web) would not be able to do that.
Learning takes time and effort, and the more general the tool I use the better.
1. Learn Electron and implement an app, publish to all platforms.
2. Choose your target OS, learn the native toolkit, implement the app, switch to other OS, implement again, rinse and repeat for all, and in the case of linux you have to deal with multiple toolkits and you have to know the quirks around Wayland support (with electron you don't necessarily as chromium handles most of that).
One of them simply takes way more time and effort than the other.
Users are acutely sensitive to apps that feel right. It's something Java learned the hard way, or not at all: there's an uncanny valley if you get it wrong, and users hate that. Native apps will always be better than a web app, but a web app will be better than an app that doesn't really have a home on any platform.
It would have been great if users were willing to say, "Oh, I know this, it's a Swing app, just like the one I used on my Mac/PC/Linux/etc." But Swing never really succeeded, and web browsers did.
Congrats on the app, it looks great :)
People love Discord. On a desktop they have no choice but to use its Electron client. Some people love Skype, but I guess not one of them wanted for native Skype to migrate to Electron. The list goes on.
Electron app developers are dime a dozen, comparing to native app developers. That's the biggest driver behind Electron popularity: business decision.
These are just the last few results for `yay -Ss discord`:
aur/purple-discord-git v0.0.r637.d47f0bc-1 (+13 0.24)
A libpurple/Pidgin plugin for Discord.
aur/ripcord 0.4.27-1 (+20 0.66)
Qt-based Discord and Slack client
aur/discord-canary 0.0.115-1 (+29 2.70)
All-in-one voice and text chat for gamers that's free and secure.
aur/discord_arch_electron 0.0.12-4 (+46 17.96)
Discord (popular voice + video app) using the system provided electron for increased security and performance
community/discord 0.0.12-2 (50.8 MiB 173.6 MiB) (Installed)
All-in-one voice and text chat for gamers that's free and secure.I have never seen people avoiding them, because they don't have a native interface. As long as interface is intutive, people are happy to use them.
* button/link handling: win desktop uses the pointer with hover effects; electron uses a hand cursor with hover effects
* minimize/maximize/close buttons, and title bars in general; electron apps tend to have them being bigger than native. Native tends to vary by framework, with UWP explicitly not allowing some of the desired customization.
* Electron and web apps in general tend to allow more text selection than native does, and with different patterns; there are pros and cons to this.
* Electron apps tend to handle high and mixed DPI better than the native frameworks (I can’t believe I’m typing this). UWP dialogs are super buggy on high and mixed DPI. WPF needs lots of manual configuration otherwise it will look blurry at least some of the time (the very latest changes _may_ have fixed this)
I tend to support native development in general, but in the case of win desktop, the native frameworks are so bad and inconsistent, I’d rather just follow the web patterns. E.g. I think the hand cursor on buttons and things is actually quite nice and worth emulating, same with non-shit titlebars.
Because so many daily use apps (VS Code, Teams, Slack, all of the web) are electron, electron often feels more native than native, at least on Windows.
Edit, since I was suddenly triggered: SVG support on Windows is shit. WPF can sort of do it if you convert to Path geometries, but that isn’t a perfect match or convenient in any way. UWP does that, but with the added bonus of an extremely buggy rendering engine that falls down on even the simplest icons.
We will of course ship native iOS/Androids apps at some point and then there will come a reckoning. Some sort of a hybrid solution is an option of course (make the bulk of the app native and have a small webview for the editor).
0: https://kitemaker.co, a super fast issue tracker with deep integrations to all of your tools
We do every once in a while end up with really embarrassing bugs though since we rarely touch the mouse ourselves.
I've also heard that PWAs have made significant progress toward being a viable option for building a desktop app. Curious what folks think about this as an Electron / native alternative.
Obviously they do, but it seems like explaining things to developers should be table stakes.
Will Flutter keep improving? Or will Google get bored with it and neglect it, like they have with Angular? I have a guess.
Still in Alpha.
I hope Flutter will solve that
Browser-based apps have no common UI rules at all, which makes them significantly more confusing to use.
For my own desktop apps, I'd choose Qt, since cross platform support is top notch.
With that said, I understand that nowadays, C++ developers are harder to come by, and memory corruption issues are not fun to work with.
Though I haven't done anything that I would consider extremely complex, memory corruption seems easy enough to deal with by planning.
Maybe because it is so ingrained as whenever I heard discussions of C++, memory (de)allocation and memory corruption was always the first thing people talked about. Dealing with de-allocation feels like closing a curly brace, almost automatic.
Currently I sell about 100 copies per month (and donate $350 of it to charity).
Public: https://videohubapp.com/
GitHub: https://github.com/whyboris/Video-Hub-App
ps - and I have a free file renamer made in Electron and Angular: https://yboris.dev/renamer/
There is a measurable cost to me for using these “lazy” apps:
- time and data plan spent downloading and updating these monsters
- my disk space (yes, my previous laptop ran out of space, which is hard to accept when you see “simple” apps using hundreds of megabytes)
- my battery life and utility bill (it is easy to measure the absurd CPU use of some of these things)
I am literally subsidizing your development with my own resources, because you couldn’t be bothered to create something that is at least moderately optimized for users.
In practice you are getting a "discount", because there was a time when most apps were paid for, while all the electron apps I use at least are free -- so there isn't anything to discount.
Due to money (development costs) and ongoing support (being able to improve and maintain the UI with CSS) I had to find a tool that would work for me.
Maybe one day with enough time and money, I'll be able to develop some beautiful native desktop apps for macOS and Windows. That would be nice :)
My understanding is that you could not use these apps. So how could one feel entitled to discounts based on implementation quality?
I bet most people who have a problem with Electron are laptop users. I use a refurbished HP desktop i7 that I bought two years ago for $300 on Amazon and upgraded the SSD and 32gb RAM for another $250 or so. I can run numerous instances of VS Code, Chrome, Slack, Postman, etc all day without even a hint of a slowdown. I also never hear my fans go on, not ever.
I work in a nice quiet room and I don’t have to travel to work. I never understood why people want to optimize for working on trains, planes and in meetings. Even when I was going into the office, I didn’t need to bring my computer home because I had the exact same machine at home since it was so cheap.
Sure one or two apps are ok. But since each app is Electron (not literally but a huge number). Your RAM melts like butter in near Sun's orbit.