I mean, this isn't the first time in history that quality and performance got thrown under the bus for the sake of cost. When developer salaries are your highest cost, and you have to make more and more money, eventually everything will get (and has gotten) sacrificed at the altar of "developer cost".
Historically, commercial software development has never been the place for perfectionist "software craftsmanship". If you want to make the world's fastest performing, native, bug-free, warning-and-lint-free, most beautiful and elegant software project, you're going to have your lunch eaten by the competitor who throws together a barely-working, bloated JavaScript mess in 1/10 the time. The people who take pride and "sand the back of the cabinet" go out of business. At the end of the day, customers (broad generalization) don't seem to care about performance or quality. So, purely by survival of the fittest, these frameworks are going to take over every software project they possibly can. Sad if you care about native/performance, but inevitable as the tide.
It's not (just) about money or profits. As a solo web dev, building for desktop with electron is faster. It saves me time, the most valuable resource. How I choose to spend that extra time - on more features or on vacation - is up to me. I don't want to spend it on learning yet another way (or several) to build UIs and apps, when I already know enough to make a good enough product for my goals. It would be great if Electron was less resource intensive, yes. There's Tauri and other alternatives that will eventually replace it and solve the performance problem.
You can blame OS vendors for trying to build a moat with OS-specific, not web-compatible UI toolkits. Don't want to touch that, don't have to, thankfully.
You are saving your own time and resources, in exchange for those of every one of your users. That insanely selfish attitude is why we are so incensed by this crap --- especially when it's developers making the lives of other developers worse.
Have some respect for your users; they might be developers too.
You're presuming that these users would have a product, even if it took several times longer for the developers to build. That isn't always (or maybe even often) true.
There are tradeoffs to be made; being absolutist about it isn't helpful.
> I think there's already more than enough quantity
That's just not true though. People need so much software, I've written more than one mediocre electron app for niche use cases that saved users multiple hours a week of mind-numbing work. That software that they're so happy to have in their lives would still not exist if it weren't for electron.
Almost none of those users are willing to pay 4x the price for native iOS, Android, Windows, Macos, and Linux apps (on top of the web version).
Also, I do not, in fact, have 4x the time to implement all that, vacation or not, nor do I have enough revenue to justify hiring a team of specialized developers.
It's about as selfish of me to be building on Electron as it is of you to not be working full time on Tauri or some other secure and high performance solution to this problem. Which is - not at all. Nobody is entitled to our dev time for free or against our will.
Realistically, the alternative to an Electron app is not native apps for multiple platforms. It is either a web app or a native app for a single platform.
Fully agree. I have a background in C/C++ and a bunch of other languages, I'm probably in a better position to write native apps, and am no Electron fan, but I never got into native GUI's for a reason. Certainly if they have to be portable, it's an absolute mess. I already did throw together basic VueJS web apps for management interfaces for another projects, and now I need a similar interface, but with some OS-level access. My choice right now is not between a native app or an electron (or something similar) app, it's between having an actual viable project/product or having nothing at all.
I can't afford to waste time and money on native apps for multiple platforms. And I know that once my thing would bring in money, I could easily find someone not too expensive to take over the work on that UI.
Native apps cost a LOT more money, not to mention organisational overhead to bring feature parity to all. Bringing something native to 4 platforms is nowhere near an x4 cost, optimistically it would be more like x8.
I thought it was that it was the browser as part of the OS which was the issue from being priveledged in performance (regardless of security concerns).
I conjecture that if the alt-universe Microsoft could have dodged that bullet via different code structuring. If there was a "HTMLReader.dll" available which handled the HTML page display rendering If Internet Explorer, its help file reader, and any other implementer of the API could use it there would be no antitrust issue because it doesn't technically priveledge their own applications. Not a lawyer but it would be interesting to know if I am right or where I went wrong.
If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.
I learn plenty of technologies - those that I want or need. I neither want nor need to learn any desktop GUI frameworks for my purposes, so I don't. Certainly not going to do anything just because some troll told me to.
If you want to make the world's fastest performing, native, bug-free, warning-and-lint-free, most beautiful and elegant software project, you're going to have your lunch eaten by the competitor who throws together a barely-working, bloated JavaScript mess in 1/10 the time.
On the other hand, things like kdb+ and the like show that there is a market for excellence. It's unfortunately rare, but it's there.
Historically, commercial software development has never been the place for perfectionist "software craftsmanship". If you want to make the world's fastest performing, native, bug-free, warning-and-lint-free, most beautiful and elegant software project, you're going to have your lunch eaten by the competitor who throws together a barely-working, bloated JavaScript mess in 1/10 the time. The people who take pride and "sand the back of the cabinet" go out of business. At the end of the day, customers (broad generalization) don't seem to care about performance or quality. So, purely by survival of the fittest, these frameworks are going to take over every software project they possibly can. Sad if you care about native/performance, but inevitable as the tide.