Comment by bengotow | Hacker News Reader

Comment by bengotow | Hacker News Reader

This is a great deep-dive into the GUI approaches taken by some nice cross-platform apps, but the author seems to have decided early on to ignore web technologies. It would have been nice to see an Adobe UI broken down, or Spotify, or Steam. (It's not like their HTML/JS-based UIs look any whackier than some of those audio production apps!)

If you have infinite time and need infinitely great performance, writing your own GUI framework on top of each platform's native libraries is probably the way to go. But a huge team of people already built and bulletproofed one called Chromium. It's icky in some ways and abstracted far from the native layer, and it'll probably eat an extra 50ms when someone clicks a button, but you can build and ship a cross-platform app in less than three years. The docs are written, the bugs are known ones, and it's easy to hire people who can help you. Just saying :-)

(full disclosure: I worked on an Electron-based mail client—definitely biased :-) )

Are we looking at the same article? Chromium and Electron are very much mentioned, and the author clearly states their position on the topic.

I'll rephrase: Chromium is a browser. An extremely full-featured browser, made to support the monstrous complexity and the security minefield of 20+ years of web standards piled on top of each other, and an impressive feat of backwards-compatibility allowing us to view ancient websites as well as modern ones using a vast array of different technologies. Great work.

A lot of current laptops come with limited RAM and disk space.

In light of this, the idea of a Chromium-based tea timer seems a little disconnected with reality. Somehow people still do it.

If your tea-timer only runs on windows 10 with .Net 4.6 installed, that's a bit rubbish isn't it?

Maybe it only took you 2 days to build, but you can't re-use any of that code when you port it to another platforms; ok, so you rewrite it in 2 days for mac. Sure. Maintenance is a bit of a pain but its no big deal.

...but what if it was an app that took 6 months to build, not 2 days?

You're screwed on the delivery and on the maintenance.

I think the point is that there are many examples of electron based applications like slack that have been hugely successful.

Sure, there are other options you could use instead, and it is bloated, and slow, etc. etc.; but there's no denying that its a successful platform, like it or not.

Horses for courses.

If you're writing a tea timer perhaps chromium isn't the right tool for the job. I'd certainly be the first to agree and the author highlights this too. If your tiny application doesn't add much functionality, I'd even suggest that a multi platform solution isn't necessary.

However, if you are writing a full featured desktop application, it starts to become a sensible option.

My daily driver is an i5 Mac Mini, and I find the performance of the Spotify app to be almost unacceptable. Clicking on a playlist is sometimes quick, but sometimes takes 5 seconds or more for it to switch screens. The other day there was the VS Code cursor blinking fiasco[0].

I definitely appreciate the rapid development aspects of Electron. I've used it myself to build a couple of little one-off apps for specific purposes. But, man, I've got my mail client open 24/7, and if it's going to waste my battery life just sitting there, I'm not likely going to be using it for very long. And if it's laggy when I'm trying to quickly rip through my email...

[0] https://github.com/Microsoft/vscode/issues/22900

Is your mail client always in focus? Because unless this is the case analogy with vs code is not correct, when it loses focus it stops rendering the cursor.

These are the kinds of things that I don't want to even have to think about. The cursor is an example, not an analogy.

To indulge this though, I'm just looking at my cumulative CPU time list on this Mac Mini (not a laptop, so I don't care so much about battery draining and I tend to keep things open and forget about them).

TogglDesktop has used 1h27m of CPU time since I launched it. That's, I'm 99% sure, an Electron app. It's a single window that displays a timer and sends the occasional POST request back to the Toggl servers.

Spotify is at 1h23, but at least it's doing a bunch of audio decoding in the background.

Slack has used 56m of CPU time as well.

I'm a little disturbed to see that Excel has used over 22h, and I've barely used it, but forgot that it was open. Closing that now.

As a decent contrast, I used Remote Desktop for approximately 32hr/wk, and it's sitting at 4h51. That is streaming compressed images/video constantly as it runs.

You can make an app that runs like shit with any technology possible, it's not the fault of technology itself. I mean, in the article author was suggesting an option of redrawing the whole window at 60 fps which is also not very efficient and also not electron.

Sure... but when you choose Electron, you're starting off with a 200MB footprint before you've even done anything. And there's so many gotchas, where doing something seemingly innocent causes poor performance (e.g. what the VS Code guys did was totally reasonable, but the underlying Chromium engine did something stupid)

I get that there's a lot of things that Electron makes really nice for doing app development, but there's a tradeoff there: how good is it going to be for development vs. how well is it going to perform? And in a lot of cases, it'll perform just fine. Not nearly as good as the same approach would in an actual native framework, but good enough and with a lot less work.

Re: the 60fps thing, that's exactly what happened in the VS Code example, except it was triggered by CSS. They weren't trying to redraw the window at 60fps, but they were because of a simple chunk of CSS that should have only caused the cursor to change every second.

Anyway, I'm totally speaking from my own experience here, and I agree that it's possible to make software that runs like shit in any language, but every Electron app that I use does run like shit. And these aren't little one-off things, these are apps built by established companies. Toggl is a frickin' timer. How is it possible to make a timer app that is slow to show a pop-up?!

The other question is: if they all have shitty performance, why do I use them? And the answer is: because they're useful. I tolerate them because despite the frustration every day, I still find utility there (and I'm working on a desktop where battery life isn't a concern).

If you've got a good example of an Electron app that doesn't perform poorly compared to an equivalently-designed native app, I'd love to see it! And it'd be awesome if the author of that app could start sharing their techniques, so that all of these well-established companies using Electron could stop making their apps suck at being responsive.

Web technologies only works when the interface is the primary feature. Spotify is a music player, Steam is a game launcher. There isn't that much functionality under the hood. On the other hand if you only need performance, or functionality, something like Qt works. What's hard with "applications for professionals" is that you need both. I doubt Adobe mainly uses web technologies in their creative suite.

What I find a better alternative to Electron is to use the browser control of JavaFX (WebKit). You can program your UI in HTML/CSS/JS, and interact very easily with business logic written in Java, Scala, Clojure, Kotlin, Groovy, Ceylon, etc. (also JS, if you want). JavaFX comes included with the standard JVM. I imagine this approach will get even better with Java 9, especially the size of distributables.

In a world where all the apps are Electron based computers have no memory left and everything is subtly or outright sluggish.

Reply on news.ycombinator.com