Electron: The Bad Parts | Hacker News Reader

Electron: The Bad Parts

hackernoon.com

68 pointsmpweiher51 comments

> While many people would expect Chromium to drastically slow down the performance or “consume precious RAM” I haven’t experienced any of this in practice and haven’t heard bad feedback from thousands of test users.

Well you seem to be looking only at process attached to a window, look a bit down in background tasks: see those chrome and other electron-based apps eating your RAM?

Electron has always kind of felt like a prototyping tool to me. It's great for rapidly developing desktop apps, but it feels like once you get a product you want to distribute, you should use a more performant GUI library like Qt.

Unfortunately, it almost never works that way, because Electron is what allows people knowing only (and willing to only ever know) JavaScript to make "desktop" apps. At the point you should switch to something native, the prototype has so much JS code you'd have to por that it's not worth it anymore.

Oh, I figured that that was the case; it's easier to make desktop apps with Electron, so it's attractive to companies because they can hire JS developers, which are almost certainly cheaper than Cocoa/Qt/GTK+/Whatever-Windows-Uses-Now developers. They're able to deliver a good-enough product with Electron, and don't really see it as a prototyping tool.

React Native says otherwise: javascript talking to native components.

React native targeting QT or a similar desktop widget toolkit ... is that a thing? It seems like it should be a thing at least at the highly starred but otherwise vaporware github repo level?

Microsoft maintains react-native-windows that targets the UWP/XAML components

And then when you see how easy it is to make a Qt app (eg http://qmlbook.github.io/en/ch04/index.html) you start wondering why you didn't go this route sooner :p

I looked through the docs some and thought it looked quite nice, except that it appears you have to write the app in c++. I see that Qt Quick uses Javascript in some way, but it seems like you'd primarily be writing your application in c++ and then maybe doing some UI scripting with javascript—is that right?

I'm not particularly tied to javascript, but just have no interest in investing the time to learn c++ properly, so that would be a showstopper for me and probably lots of others who are considering going down the Electron route.

To re-iterate though, QML does look like a very nice system for specifying UIs...

> I looked through the docs some and thought it looked quite nice, except that it appears you have to write the app in c++.

No, you can write full apps in QML/JS (I personnally prefer going the C++ route for the stricter typing and better performance, but to each its own :p).

Most JS libs will work (except those that work on the HTML DOM since ... it's not HTML).

And then when you see how "uncanny valley" Qt apps still look due to its emulated widgets, you'd wonder when are we gonna get a proper cross platform UI solution...

wxWidgets

Unless you need features that aren't staples of the Qt system, like editable diagrams connected by Bezier curves on an arbitrary size canvas.

Okay but you can do stuff like that in qt or qml just as easy as javascript (if you know how to use it of course)

Uh ? there are actually quite a bit of stuff like this, for instance I like this one: https://github.com/paceholder/nodeeditor

From the "roadmap" section for that project

> GUI: fix scrolling for scene view window scrolling

I need the scrolling to work out of the box. Some of the users' diagrams are going to be 10x the size of the examples shown for that framework (if not larger).

Also in the issues section:

* you can't put a custom context menu for the nodes

nw.js (and I assume Electron) provide this by default.

* Crash: Attempting to connect an input node into self output node

Sorry, that's a showstopper. The application I maintain proudly does not crash when the user tries to do this.

And then this one: * Implement QML frontend

So... if I'm not leveraging QML, what's my workflow with this framework? Am I coding it in C++?

If so, then the speed and ease of developing the frontend doesn't compare to HTML5.

Just noticed another showstopper:

* https://github.com/paceholder/nodeeditor/issues/63 (doesn't currently support HiDPI)

I need HiDPI support out of the box.

This may all seem secondary to my original statement, which was that Qt works fine until you want to draw certain types of diagrams. While I'm convinced it's possible (and looks to be getting easier in the future), the example you gave isn't fully baked, doesn't have a QML frontend, and doesn't look to be stable.

I have no doubt people can and will build more frameworks for Qt as it continues to improve. Meanwhile, however, with HTML5 I can use raw Javascript, or d3, or React, etc. all the way up the ladder to frameworks specifically designed for editing diagrams. All of those will result in diagrams of boxes connected by Bezier curves with performance that scales with the number of DOM elements. And every single one of those options have demos that work in the browsers we're staring at that merely require a keyboard shortcut to study and change the code.

Chromium is a ridiculously optimized and extremely flexible runtime. Qt is ok for basic UIs, but once you need to do custom draw, "modern" animations (supported by CSS) - Chromium will be much more approachable and faster.

That's ridiculous. Qt has excellent support for custom UIs and one of the strengths of QML is animation.

The second image on the Electron home page claims that it has "native menus." However, as I noted in 2015 (and haven't seen any evidence of it changing - https://github.com/electron/electron/issues/2504), it absolutely does not have native menus. There's nothing native about Electron at all; if there was, it wouldn't be stylable via CSS, and that would defeat the purpose of the project. But Electron should at least try to emulate the native menu behavior as close as possible. That doesn't seem to be a priority for the project, however.

nw.js has native menus:

https://nwjs.io/

That said, I'd steer away from native menus unless the GUI toolkit specifies their behavior precisely, including how the menu API interacts with HTML5 including DOM bubbling, CSS layout calculations, etc. Otherwise you'll need to research the behavior yourself, for each platform, defeating one of the benefits of using a cross-platform HTML5 toolkit in the first place.

Electron does have native menus on OSX. I always got the impression that OSX is the main OS the team is interested in supporting.

Qt is native and it has styling by CSS. It's not impossible to do.

> The fact that each application comes with its own version of Chromium (the 20 million LOC, ~30MB [packaged] Web runtime) is one of the most criticised aspects.

Can't they make use of shared libraries?

The big advantage of doing it this way is that, for users, it Just Works. They never get incomprehensible error messages telling them that they've got an incompatible version of libwhatever.dll when they try to load your app. I remember well the bad old days of Java desktop apps in the early 2000s, where this problem was omnipresent. Moving away from that was a major boon to users, and I don't ever want to go back.

And now many java apps bundle their own JRE (at least on windows).

Like anything else it's a tradeoff, and for the average user not having to install separate dependencies (at least on windows and mac) is going to be easier, and 50 or 100 mb isn't something anyone is going to really have an issue with in the vast majority of cases.

Slack for example is 192 MB. I guess if everyone had that theory I might have 30 extra copies 6 extra gigabytes. More importantly I would have to ensure I killed apps lest say a calculator app or editor ruin my battery life by itself for the dubious privilege of rendering a blinking cursor.

Like I said it's a tradeoff.

For you, it sounds like it hurts more than it helps, but for others the options may be:

1. Don't use slack at all because they can't figure out how to install the correct version of libthingy.dll. Or they don't get the app at all because it's not for their platform.

2. Use slack

And in that scenario, the option they went with wins hands down.

I'm not saying it's perfect, and I still believe that giving both options would be a benefit for most, but the fact that it is done this way wasn't a "mistake", it was a tradeoff for the targeted audience solving problems that many had.

You're not really being fair here. You could just as well distribute all needed dll's with the app. In fact, that's pretty much what Electron does.

Why not ship an installer that checks for and appropriately installs DLLs?

Doesn't sound that bad on desktop. The binaries for Qt or the java JVM are not small either.

I suppose it's a problem on mobile though.

Hmmm.

Qt programs are pretty small. Java are bigger but still much much smaller than any Electron-based program.

IIRC JRE is about 50 MB. Probably less. So even if you include it with your Java program, it's STILL smaller than Electron programs.

Java was the problem here. DLL hell is a problem if you don't ship with the needed DLLs. Which you shouldn't do in the first place.

I‘ve had a bunch of electron apps show incomprehensible Javascript errors at launch. Technology doesn‘t prevent people from distributing poorly tested code.

It's 2017 and we still can't distribute software or manage libraries. For some reason content addressability based on hashes for libraries has never occurred to anyone.

Windows Side-by-Side assemblies (WinSxS) are similar to this. Each assembly or .dll contains a manifest that list its dependencies by version and token id. The OS dynamically loads the dependencies based on the manifest.

https://en.wikipedia.org/wiki/Side-by-side_assembly

This was introduced in Windows 2000 and used for core OS components starting with Windows Vista.

I think Guix has the potential to do that. At least the hash for the reproducible build is part of the package definition.

So it seems like one should be able to just have that hash, and then rely on the backend to just go fetch a blob that has that hash from a list of possible sources (centralized repo, bittorrent tracker, IPFS, etc.)

Why use hashes instead of, e.g., semver, or hash + patch version, so that you could patch Heartbleed easily?

What do you mean should be hashed? Each library?

Yes. Then add a service on the OS that fetches the libraries for any binary. It's not a complicated thing. It's been obvious to me for years that this is how exact version linking should work.

Linux at least has library versioning so this is less of a problem. Windows has foo.dll and foo.dll and foo.dll, so pretty much the only way is to ship your own foo.dll.

There are schemes like this, e.g. Nix.

I like it though it not without any disadvantage.

It will be challenging to upgrade OpenSSL after a discovered vulnerability.

Not that I disagree, but the downside is that you would have the browser fragmentation that alot of people use electron to avoid.

There is a project that actually does something in those lines.

https://github.com/nodekit-io/nodekit

Instead of embedding a browser engine and Node in each application, it uses the available ones in the platform it's running.

Another similar project to use the available browser on the user's current platform:

https://github.com/pojala/electrino

Then you'll get weird errors. Everyone distributes the whole universe because it just works. Docker is the same idea for services.

And you fix these errors as they arise, adding platform-specific hacks to the library as necessary. Your product still ends up much smaller and better-performing than the others.

Updating just the app is a nice trick. However, if you only update your app and not your dependencies, that means you don't get security fixes to your dependencies. It seems important to solve security updates for dependencies too?

I really like the idea of using HTML/CSS/JS for the GUI and UI logic of an app, but shoving in a whole web-server just seems nutty to me...

That is essentially what qml does

Depends on your definition of "essential". The biggest similarities of QML to an HTML engine are that it contains a JS engine, and that it has item and layout trees. It is worth noting that the core content description language of both has nothing to do with JS.

I would have liked to see a call out for crash reporting. I still haven't found a good self hosted Breakpad server.

Mozilla has Socorro, which is great, but way too heavy for a small application.

Yes, Electron updates and installs are a pita. Specially in Windows.

Reply on news.ycombinator.com