Hacker News Reader

Comment by Veratyr | Hacker News Reader

> So you;d rather have fewer useful GUI programs?

Personally, I'd rather have fewer webapps (which is what these really are) bundled into bloated browsers and called "desktop" or "native".

If you're going to put in the effort to write a proper desktop application with native components through Qt, .NET, Java or OpenGL or something, go ahead but please don't bother with webapps with a browser wrapper, just leave them on the web where they belong. If you need a little more integration, do it with a browser extension.

I'm yet to see a single necessary Electron port.

> What incentive does any developer have to do as you say?

The top comment on any news article or discussion forum being something other than "great, another unnecessary Electron app that'll waste my CPU, RAM and battery".

And producing a better performing application.

View on HN

I use Linux as my desktop and the rising popularity of electron means that most "cross platform desktop app" links which used to mean "we do windows AND mac!" are actually cross-platform, are usable on Linux and are feature-complete and behave the same as on other platforms.

Electron has been a godsend to Linux users and it can definitely be highly performant. I've even switched from vim to vscode because the latter is actually the slickest IDE I've ever used.

You're yet to see a single necessary electron port? Well, I use 4 all the time, probably none of which would even be Linux-compatible were it not for electron. YMMV.

> means that most "cross platform desktop app" links which used to mean "we do windows AND mac!" are actually cross-platform

The "cross platform desktop apps" I'm objecting to are really just webapps that could run just as well in a browser without the wrapper. If they weren't released in a wrapper at all, they'd still be cross platform.

> I've even switched from vim to vscode because the latter is actually the slickest IDE I've ever used.

VSCode and Atom make a little more sense in Electron because they actually have requirements that can't be met when run purely in a browser (like running a build system). I still prefer a native IDE like Sublime Text but I can see also see the benefit of using Electron here. The apps I have problems with are the webapp ports like Slack, Discord and Spotify.

> You're yet to see a single necessary electron port? Well, I use 4 all the time

What are they? What makes them necessary (other than VSCode, which I understand as explained above)?

Slack and discord maybe, but Spotify plays your local music library. Can't do that in the browser (well, maybe with java applets)

Ah, didn't know that. It's a shame, there was a spec for that but it got dropped: https://www.html5rocks.com/en/tutorials/file/filesystem/

"I use Linux as my desktop and the rising popularity of electron means that most "cross platform desktop app" links which used to mean "we do windows AND mac!" are actually cross-platform, are usable on Linux and are feature-complete and behave the same as on other platforms."

This. Electron makes it economically and technically feasible for companies to deliver the same features and support to Linux users as their other customers.

The thing is often not explicitly stated is that many companies using Electron are not desktop software vendors, but SaaS providers. They aren't going to do native desktop applications, because they just want to provide nice clients to users for their particular service.

I'm going to bookmark this post and refer all figure electron arguments here. You're right. Nobody would ever bother porting these apps to Linux

> If you're going to put in the effort to write a proper desktop application with native components through Qt, .NET, Java or OpenGL or something, go ahead but please don't bother with webapps with a browser wrapper, just leave them on the web where they belong. If you need a little more integration, do it with a browser extension.

Yeah... no. I'm not that fond of using Electron apps (Atom, Slack...) myself, but I absolutely don't want them in a browser window. Writing a "native" application simply isn't an option in many cases.

> The top comment on any news article or discussion forum being something other than "great, another unnecessary Electron app that'll waste my CPU, RAM and battery".

So what? There's the same handful of curmudgeons posting that comment everywhere. That doesn't mean they're valuable as a demographic. It depends on the market of course, but if your application solves a problem that nothing else solves as well (as it should), then running on Electron is not a dealbreaker. Most ordinary users can't tell and don't know to care.

> but I absolutely don't want them in a browser window.

But that's exactly what you're getting when they're run as Electron apps. The main difference being that they consume more system resources than an actual browser window because they can't share any resources with your actual browser.

> So what?

> Most ordinary users can't tell and don't know to care.

The problem is that the complaints of CPU, RAM and battery degradation are valid complaints. I think you'll find that many users can tell that their machine has become slower or has a faster draining battery but they won't know to blame the browser wrapper for it. Take Spotify (which uses Chromium Embedded Framework) for example:

- https://community.spotify.com/t5/Desktop-Mac/Battery-Drain/t...

- https://community.spotify.com/t5/Desktop-Linux-Windows-Web-P...

- https://community.spotify.com/t5/Desktop-Mac/Again-When-will...

> But that's exactly what you're getting when they're run as Electron apps.

Well, no it isn't. If you can't even make that distinction, then having any further conversation with you is going to be pointless.

I suppose you would welcome the use of progressive web apps, but those haven't yet "arrived". If they did, I might argue for using them over things like Electron.

> The problem is that the complaints of CPU, RAM and battery degradation are valid complaints.

Many complaints about web technology are valid, that doesn't mean they invalidate its use. The reality is that even a company like Spotify would rather drain its users batteries than develop native apps. It's a tradeoff.

If Spotify followed through with your advice, those users should not be offered a desktop app at all, they should be forced to only use the website and have their browser drain the battery instead. You're effectively arguing for less choice when a native app is not an option. That doesn't make sense to me.

> Well, no it isn't. If you can't even make that distinction, then having any further conversation with you is going to be pointless.

What is the distinction you want me to make? That it has a different icon in your OS task bar?

> If Spotify followed through with your advice, those users should not be offered a desktop app at all, they should be forced to only use the website and have their browser drain the battery instead.

My argument is that by sharing resources with the browser they're running anyway, that the battery/CPU/RAM drain will be reduced. A browser is a lot of overhead and using less browsers at once is always good.

> You're effectively arguing for less choice when a native app is not an option. That doesn't make sense to me.

The reason is that these browser wrappers are marketed deceptively, so users aren't equipped to make an informed decision about whether to use them.

Users generally expect that when they download a desktop application, that it's native, has minimal overhead and performs well. Browser-wrappers don't meet these expectations. Users don't realise they're downloading an extra browser and all the overhead it entails.

If users realised that these were just another browser that can only open one website, I'm sure their feelings would be substantially different.

They think that when they download Spotify, it's going to perform like VLC or Winamp and it absolutely doesn't.

> What is the distinction you want me to make? That it has a different icon in your OS task bar?

That's one! So, it's already not exactly the same. Figuring out the rest shall be left as an exercise to the reader.

> My argument is that by sharing resources with the browser they're running anyway, that the battery/CPU/RAM drain will be reduced. A browser is a lot of overhead and using less browsers at once is always good.

You are describing one trade-off. Your argument is valid, but if you follow the links you yourself posted, it's not actually the browser engine that does all the draining, it's the content it is running (i.e. you can disable some functionality and the problem is mitigated). The base RAM overhead of running Electron compared to something like Qt isn't that big either.

> Users generally expect that when they download a desktop application, that it's native, has minimal overhead and performs well.

I don't think that's true, but even if it was, so what? Users need to lower their expectations.

I've considered using Qt in the past as it seems like a good GUI framework, but there seems to be one technical factor that holds it back from even greater market share, which is language bindings.

If you program in C++ or Python, no problem, both have good support for Qt. However, outside those two languages it seems that the available bindings tend to be small projects rather than something robustly tested. That's appeared to be the case a few years ago at least, would be happy to be proved wrong.

If people refuse learning C++ or Python to deliver a product and rather stay with JavaScript, that is the problem.

Not the lack of alternatives.

I'm not suggesting this is a JavaScript-specific issue, there are plenty of other languages without solid Qt bindings, and the suggestion that someone should learn a whole new language just to use one library is a little absurd.

The Go language would pair up nicely with QT since it produces executables with no external dependencies.

Well, people learn SQL to use databases, Ruby to use Rails, C to do IoT or UNIX kernel development,R and Python for data analysis.....

If they want to ship a product with good UI/UX quality, then they should learn the supported languages.

It is all about placing customers above personal preferences.

I bash C a lot, yet I will use it without thinking twice about it, if is the best solution for solving out our customer's project requirements.

Then again, I never bought into Developer Technology X mentality.

> "If they want to ship a product with good UI/UX quality, then they should learn the supported languages."

The time sunk in learning a new programming language is not inconsequential. You can get to a basic level of proficiency relatively quickly, but being productive in a language takes time and effort.

If I took your approach I'd constantly need to switch languages and rely on glue logic to piece them together. Just because a language is 'the best' at one thing doesn't mean it's always the right choice for a project that has multiple requirements. Should all regular expressions be written in Perl? Should all mathematical operations be written in Fortran? Should all macros be written in Common Lisp? Should all data structures be described in Idris?

Which is what we do in consultancy, and I am talking about personal experience here.

We deliver projects in Java (Swing, JavaFX, Android, JEE, Spring), .NET (Forms, WPF, ASP.NET, UWP), C++ (NDK, .NET, Java native methods), Objective-C/Swift (iOS), PL/SQL(Oracle), Transact-SQL(MS SQL Server), pg/SQL (PostgreSQL), JavaScript(Web).

Every 6 months or so, we tend to switch customer and respective project stack, being able to proficiently jump between technology stacks is expected.

That's not what we're talking about though. What we're talking about is developing outside the bounds of battle-tested stacks.

To use another example, let's say I was writing an app in C#. Should I use a JVM GUI library just because I liked it better than the .NET ones? Even if it's technically possible, it's far from optimal.

We have done it a couple of times via IKVM, to access libraries like Lucene or MarvinView.

We also have projects with application servers written in JEE, using native desktop GUIs in WPF, talking via REST to those servers.

The strategy behind JavaScript is to write your application as close to one time(s) as possible. Adding Python or c++ defeats this goal. For most startups looking to build their MVP, the cost of c++ dev (in addition to writing your codebase a second time) would be dangerously unpredictable in cost and stability if they're not already using c++. Python is missing strong alternatives to both writing UI code in the browser and alternatives to react-native. It's also not reliably faster or better than nodejs in any metric outside of a few unrelated top libraries like numpy and ML. The JavaScript community is also interested in an electron alternative and proper QT bindings to nodejs would be a valuable first step to solving the electron problem, if another solution isn't established via react-native/native-script.

Reply on news.ycombinator.com