Because it's cheaper, quicker and the vast majority of users are fine with it.
I'm not excusing it, I curse Slack every day I have to use their Electron app (though mostly just use it in a browser tab now) but we have this exact same conversation every time anything about Electron is posted on HN. None of the parameters for making the choice have changed since the last time we did.
> I curse Slack every day I have to use their Electron app
I did that too for the last couple of years, but recently switched to this client: https://cancel.fm/ripcord/ Found the link in comments here on HN.
Works well so far. There’re couple minor UX issues, e.g. hard to react to messages with these modern hieroglyphs, also images are loaded in web browser, but I can live with them. The upsides (ability to setup font faces and sizes, resource usage, GUI latency) are far more important for me.
The real reason is that the people making electron apps don't know how to make stuff in C++ and don't want to try. This might be a little more excusable before C++11 or if trying to avoid MFC and/or doing everything with win32, but modern C++ and GUI libraries like FLTK, Juce, Qt, etc. are a pretty great way to make something. A FLTK program can start at 100KB without dependencies.
These aren’t developer choices being made. They’re product choices by product managers. I bet there are plenty of JS developers that would be interested in picking up C++ or something like Rust but don’t have the option.
In what world is building an application in a language like C++ when the rest of your tech is built on javascript/java/go ever economical or excusable for a business?
And don't tell me development time will be remotely similar either.
> when the rest of your tech is built on javascript/java/go
Where does this come from? This is a program being distributed to other people.
> And don't tell me development time will be remotely similar either.
It will be in my experience. I haven't felt like C++ slows me down in a long time. Modern C++ and STL vectors + hash maps is the vast majority of what you need. There is no memory management to be found, just moving variables when returning them from an inner scope.
Then you have a single binary that is incredibly fast on any modern computer and even many that aren't so modern any more.
> This is a program being distributed to other people
What does this have to do with anything? Everyone in the company works on 3 languages. Introducing a new language, with new runtimes and build tools and domain expertise introduces a ton of overhead.
> It will be in my experience. I haven't felt like C++ slows me down in a long time. Modern C++ and STL vectors + hash maps is the vast majority of what you need.
Every tool set has its own set of idiosyncrasies and bugs and general bs that has to be learned. Saying that introducing a new set of tools is cost free is a stupid lie.
The nice thing about this question for old-timers is that we can recycle the answers we already heard about using Java for cross-platform desktop development from 20+ years ago. Or the rationale for using a cross-platform toolkit with C++ from 30+ years ago.
You get substandard desktop applications that tend to frustrate people who are deeply immersed in any one ecosystem and expect native applications to have deep integration with each platform and comply with each platform’s design sensibilities.
But history shows that applications written against cross-platform toolkits have done just fine, as have applications that completely embraced “going native” on particular platforms.
I’m left with the thought that either strategy works if you go “all in,” the mistakes come from:
1. Going cross-platform but then doing ridiculous back-flips to try to make the app feel really, really native. Just take what the platform gives you, and accept that you’re giving people a web-like experience that happens to have some native affordances. Learn to live with the few complaints from retro-grouches.
Or, 2. Going native, but skimping on deep integration and fully embracing the look and feel of each platform. This is one of those “penny-wise, pound-foolish’ strategies: You ship faster, but you lose the big benefits of a cross-platform tool, and you don’t satisfy the users that appreciate what a native app offers in look, feel, and integration.
Ha, I meant it in the opposite way, that it avoids making either mistake. Yes, it consumes a lot of resources, but it's success has proven that users don't mind this as much as commenters on hacker news seem to.
And it's a program that is slick, intuitive, and supports so, so many use cases without ever feeling overloading.
- you want to make sure that people respect the importance of your app by not running it along with everything else because it needs 10x the amount of resources a native app would
Users don't care anymore. Phones have 12GB of RAM. A $500 laptop will have plenty of RAM, CPU power, and storage for the average user to not even notice anything. HN and reddit are the only ones who can't seem to grasp the idea that it's not 1995 anymore, and apps taking even 1-2 GB of RAM isn't that big of a deal for the average user.
Do I want my CAD software as an electron app. Obviously not, but for most applications electron is just as good an option as anything else.
Sure, if you constrain “average user” to America. If you go to other places like India, where people don’t have $500 lying around to drop on the latest notebook, you’ll find a lot of repurposed laptops that have several-year-old specs still finding active use. Machines with 2 GB RAM and 250 GB spinning rust are not as uncommon as you might think.
And sure, if you just run one app and that’s it, you might get away with acceptable performance. But now try to install it over slow or metered Internet. Try to run it alongside Chrome/Discord/Eclipse/Spotify/Android Studio. Try to install all those apps without chewing up your disk space. These aren’t hypothetical scenarios, these are very real usability concerns.
> and apps taking even 1-2 GB of RAM isn't that big of a deal for the average user.
I live in France, a first world country, just checked Amazon, the N°1 best seller laptop currently has 4GB of RAM, a 64GB SSD, and a 1366x768 screen and a dual-core Intel Celeron CPU which does not even reach 3Ghz: https://www.amazon.fr/HP-14s-dq0000sf-Ultraportable-Microsof...
this is what the average user looks like (and will still look like in a few years, if people buy a laptop today it's generally to keep it 5 years). I have never ever ever seen anyone say "hey, my computer is fast" it's always "do you think you could look at it, it's super slow / it has viruses / ..."
Yea, these are poor reasons imho. Relying on mommy Chrome and the hellscape of ECMA transpilers seems like the opposite of "cross platform" since you rely on a much more unstable foundation...
No, really why not write a native application? If I'm understanding it correctly, Electron is depending on third-party libraries like Portal Windows to get functionality like "create new windows, treat them as objects, and poke around in them" which comes for free in single-process GUI libraries like Qt.
The go-to excuses for this are "easier," "cheaper," and "good enough for the users."
Also known as "laziness," "greed," and "lack of pride in one's work."
I'm OK with some rando startup using something like Electron in their formative years. But companies like Microsoft have no excuse other than some middle manager's desire to buy a new boat.
Microsoft understands the value of being able to develop once and run everywhere. That's why both Java and the web almost upended their business.
It's not just a monetary/time/effort value to Microsoft or other developers either. It has value to me a user. I prefer applications that I can take with me anywhere I go and they'll be exactly the same on every type of desktop that I use them on.
The list of native desktop applications which can actually do this well for me is pretty short.
Hey! Author here: this demo is just the most extreme example I could quickly write to show the power of this library.
Realistically, you won’t need to chain window movement like this in most cases (other than our chatbox, I think none of our windows stay open when their parent window is moved). Fast auto-resizing, on the other hand, is more common, and works great.
I'm not the OP but even the demos with the actual software are kinda stuttery. Like the one where you move the outlined spotify window, it's just not great. It's cool that you were able to make it simple to do, and not worry about it, and it's really impressive work, but I guess still feels off a little.
Ah, I know the one you’re referring to—-that purple window actually isn’t using this library.
We can get the position of our _own_ windows easily, but when it comes to getting Spotify’s position, we need to do some more complex polling, which is slower (and only works when the 3rd-party window is in focus).
This is a constraint of the APIs provided by MacOS, they allow you to position by (x,y) coordinate and resize by width/height, but there's no way to tween these values...and nor should there be.
What's Tandem are doing here is (interesting, but) atypical behaviour.
I don’t think that's entirely correct. While you can't ask the OS to tween the values, nothing prevents you from doing that, other than likely a reduced frame rate.
It's still not 100% smooth, but it seems slightly better and demonstrates the ability to manually tween values. Similar performance in both Chrome and Safari.
It's curious to me, because I've seen compositors in both Linux and Windows handle it perfectly, but I admittedly haven't played with MacOS more than I'm forced to. I'm not very familiar with Quartz, I sorta assumed it would cover x11 functionality by default.