> 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.
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.
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.
I‘ve had a bunch of electron apps show incomprehensible Javascript errors at launch. Technology doesn‘t prevent people from distributing poorly tested code.
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.
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.
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.
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.)
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.
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 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?
> 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.
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.
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...
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.
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?
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.
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.
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.
> 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?
51 comments
[ 0.18 ms ] story [ 94.8 ms ] threadCan't they make use of shared libraries?
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.
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.
I suppose it's a problem on mobile though.
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.
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.
https://github.com/pojala/electrino
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.
I like it though it not without any disadvantage.
It will be challenging to upgrade OpenSSL after a discovered vulnerability.
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.)
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.
> 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.
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...
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).
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.
Mozilla has Socorro, which is great, but way too heavy for a small application.
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?