1. 38
  1.  

  2. 28

    Other facts include:

    I don’t care about how fast your app runs in electron. The Space Shuttle goes fast too, but the amount of energy that goes into launching isn’t trivial.

    1. 3

      IMHO the article is a bit meagre on the facts. Thanks for pointing them out. I also really like the part about the space shuttle, I will use it in future discussion about electron :)

      1. 2

        The native analogy to this isn’t recompiling a program using the native GUI, it’s recompiling the native GUI libraries.

        My understanding is that Qt/Gnome are both pretty tough to get up and running.

        That said, it would be extra awesome to make this stuff easier. Namely not having to have a copy of Electron for every app would be great. Where’s the JVM for Electron?

        1. 8

          My understanding is that Qt/Gnome are both pretty tough to get up and running.

          Nope. Gnome is a mess, but Qt is beautifully organized and very easy to clone and build.

          1. 0

            My limited experience trying to release a new version of a Qt code base says otherwise. Moving an app from one version of Qt to another is non trivial IME.

            1. 2

              I have done it. Coincidentally, it is also a gooey client for postgres (https://github.com/pgXplorer/pgXplorer). Moved it from 4.x to 5.x. It was relatively ‘easy’. From 5.x to 5.y involved little to no change in certain versions.

              My opinion is that the Qt documentation is excellent overall but internals can send you on a wild goose chase. For example textfield or a dropdown in a table header (lel)

              1. 1

                You’re comparing apples to oranges, though.

                Initial setup and day to day use is fundamentally different than upgrading a large code base to an incompatible new major version.

                Electron hasn’t been around long enough to even make that comparison. Even with Qt, there have only been two major non-backwards compatible releases in the past 16 years.

                1. 1

                  I don’t doubt it. I’m hardly an expert, my one set of experiences around this was trying to recompile the Zeal open source doc set viewer (like Dash but for Linux) for a newer Qt version, because if you built it from source on modern Linux versions it wouldn’t display properly.

                  It was un-fun :)

        2. 22

          What a breath of fresh air. Rather than engaging in FUD the author actually comes up with real performance numbers and compares and contrasts against similar software using other methods and toolkits.

          1. 9

            I enjoyed reading about the goals of the Postage project, but I don’t see an actual response to the content of electron/flash, whether acknowledgement or disagreement. The performance numbers listed don’t address that article’s content. Criticism: electron applications are bloated in application size, memory, cpu. Response: install time, startup time, query time compared to another application. They’re related but different subjects.

            1. 2

              While I agree that this article does not counter the specific thrust of the Flash article, I would argue that it makes a valid counterpoint that’s worth noting - for a lot of applications (of which, according to the author, Postage is one) Electron’s size, startup time, memory usage, or whatever else are Good Enough and for the developers at least, such considerations are offset by the ability to deliver a nice cross platform UI at all, which is no small undertaking.

          2. 12

            When it comes to Electron I mostly just wish the Slack team would take some notes from the Visual Studio Code team. As the author here says: “is Electron the problem, or is your code slow?”

            (I still think Electron is an odd choice for an IDE, but somehow MS are making it work)

            1. 9

              Why on earth is it an odd choice for an IDE? The graphics layer is a GPU accelerated cross-platform scene graph, optimized for 2d, using platform native fonts. Then there’s a scripting engine with a finely tuned JIT and a framework for cross-platform native C++ code. Both the scripting engine and graphics have an API that’s common across multiple vendors who compete vigorously on performance.

              I’m not sure why you’d chose any other platform for desktop software.

              1. 3

                When you put it like that… I only mean that it seems an odd choice for things which aren’t “web first” that you want to deploy a local version of (Slack being a classic example here: build a web interface, ship desktop versions for multiple platforms “easily”).

                However you’re quite right — and the folks building VS Code are clearly no fools — so I’m forced to reconsider that although it seemed so to me, Electron is perhaps not that odd a choice after all.

              2. 4

                As far as Slack, there is a chat server called Synapse, the point of the server is you bridge it to other servers like Slack’s API or freenode. I set it up for internal use but I haven’t bridged it anywhere at this time.

                That way you can use a very simple chat client on desktop and mobile to your server and the server handles all the complicated stuff. Plus the servers are federated so if somebody else already uses Synapse then you don’t need to bridge at all.

                For the client: https://matrix.org/docs/projects/try-matrix-now.html

                For the bridging programs: (To set one up you will have to setup your own server, or see if someone else is running a bridge on their server and provides public access to those rooms) https://matrix.org/docs/projects/try-matrix-now.html#application-services

              3. 8

                There are some things that seem a bit off in this assessment of Electron, namely that any electron project can be optimized to something faster than a native GUI with “a fair amount of effort”, or that Native GUI controls are somehow a fixed/limited set of components to be used. That “fair amount of effort” would also need to be applied to the native toolkit app in terms of optimizing, if one is to make a fair comparison. Obviously this breaks down a small bit in that when you’re going cross platform, you have less resources to do optimization with overall, but if we’re talking raw performance, both options in consideration need to be given some love.

                HTML+JS is certainly a very flexible way to do things, but any native toolkit worth it’s salt will give you ways to do arbitrary display work via a graphics context, and should give you a way of composing controls via containers and/or means of doing layout well. Granted, this is a skillset that is hard to take cross-platform, so it only really makes sense when you have a lot to gain by being native, but it bears mentioning.

                The greater point that performance of a given Electron application is largely in control of the developers is appreciated, however. I suspect a great many web pages leak memory quite badly, and that’s usually not given much consideration “because you can just refresh”. And Electron does offer convenience and openness on lot of things that most native frameworks don’t do nearly as well, especially when going cross platform.

                @justintocci You said that you don’t use the node part of Electron? How does that end up working? You just ship the web server binary with the app, and then use Electron to ship a static site that connects to that web server?

                1. 3

                  For the record I feel it’s fair to say I overstepped in my claims but I would say not anywhere near as much as the article I was rebutting.

                  In answer to your question, yes! That is exactly what we do. Postage has an event driven binary that runs something like a web server. The main differences are that it’s a very small API and that API is primarily for passing requests on to a database server. The speed comes from using Web Sockets instead of CGI, the event based architecture and the fact that speed is the primary goal of the project.

                  1. 2

                    That sounds like a very compelling way to use Electron for this Go-head. Part of the reason I’ve not been very keen on using Electron has been the fact that it seems like Node is the Way To Go in terms of the other side, and I’m not currently that keen on doing node.js stuff in my spare time.

                    I don’t mind the mild overstep that much. I was just pointing out that in the larger scheme of things, I suspect that quite a few devs think in more limited ways about native GUI toolkits than those toolkits actually deserve.

                2. 7

                  Recently, we’ve decided we can’t wait for LIBTLS to become usable in a cross-platform

                  Electron does not work on my platform, while LibreSSL does. In fact I use it pretty much exclusively. I also haven’t encountered a system yet where it doesn’t work, so I am curious about where you had troubles.

                  On the note of performance: This article seems to largely focus on startup performance, when it comes to numbers. Sadly not really anything about latency, memory or CPU use. And yes, I agree, that you probably shouldn’t care about every last byte and cycle, but Electron from my experience at least used to be on the very heavy side. That might have changed though.

                  On the memory the statement basically boils down to “JavaScript is garbage collected, C is not”. Oh and the rendering engine certainly isn’t written in JavaScript. Also yes, you can still leak memory in JavaScript. I know it’s a bit harder, but then again I’ve seen it many times, essentially when using asynchronous JavaScript.

                  So, I am all for Anti-FUD articles, but that summary didn’t really counter any objections, I’ve heard other than from people that simply hate on Electron cause they feel like it. But I’d doubt that this article was targeting people that don’t switch to Electron for personal reasons. At least I don’t think that it would have any effect.

                  Other than that: Postage looks really interesting. I am certainly going to try it, as soon as Electron works on my platform. pgAdmin (both version) have certainly been a bit of a pain in many regards, so if Postage fixes that I’d be more than happy. For now I’m gonna stick to the command line.

                  Oh and one tip: Please don’t stop taking criticism though. I know there has been a lot of FUD and sometimes it can be hard, but a lot of criticism that is more elaborate than “X sucks” tends to come out of genuinely wanting a project to become better, else people wouldn’t bother writing those criticisms.

                  1. 2

                    So, I am all for Anti-FUD articles, but that summary didn’t really counter any objections, I’ve heard other than from people that simply hate on Electron cause they feel like it.

                    I’m not trying to convince people to try Electron. Various people have given us the impression that they won’t try Postage because of Electron. As I said in the article: “I hope you’ll give projects like Postage a try.” That was my goal. Rather than engage the original article directly I made the case that there are good reasons to use Electron and the sweeping generality that “Electron makes a project slow” runs the risk of overlooking useful, high performance software. If I made that case then I consider the article a success.

                    1. 1

                      Other than that: Postage looks really interesting. I am certainly going to try it, as soon as Electron works on my platform.

                      Please note that Postage is available without Electron. Just configure-make-install and if you have trouble just post an issue. We have it installed on a server (with no desktop) and access it remotely through various browsers. This way it works on mobile too. The chief advantage is that we can update it once and we’re all up to date.

                      1. 1

                        Electron does not work on my platform, while LibreSSL does. In fact I use it pretty much exclusively. I also haven’t encountered a system yet where it doesn’t work, so I am curious about where you had troubles.

                        We basically had to compile LibreSSL for every system, because it’s not the default on all systems yet. So our compiling process was 90% compiling LibreSSL included with Postage, 10% compiling Postage. This raised the barrier to entry into compiling it, and means that any compilation bug in LibreSSL will effect Postage, of which there have been a few.

                        Postage can still use LibreSSL, and it does for Windows because we have to ship a ssl library in the package anyway. Point is, we use whatever is already installed, be it OpenSSL or LibreSSL. Once the big four operating systems ship LibreSSL as default on the latest versions, then we will consider switching back to LibTLS, but LibTLS is just a LibreSSL specific wrapper for LibSSL, we now we just use that, reducing our compilation time, and it improves cross platform support.

                      2. 2

                        I’m working on a soon to be beta Electron app (http://www.serverwrangler.com/) and I have to say all the recent hate on Electron has me a little concerned. However I think the tradeoff between cross-platform development speed and runtime “bloat” makes the choice of Electron worth it. With Electron I can deliver a lot more features in a much shorter amount of time than I could writing a native app, much less a native app for each platform.

                        As for the comparison to Flash its more appropriate to compare it to Abobe AIR. I wrote quite a few AIR apps in the past (mostly educational research games used in unreliable network-connected elementary schools) and I still think the AIR platform is a better experience since it uses a single runtime and allows for installs via the web. I expect someone will try to reinvent the AIR single runtime for Electron using some sort of process isolation between running apps.

                        1. 4

                          I’m working on a soon to be beta Electron app (http://www.serverwrangler.com/)

                          Can you tell something more about your project? The screenshot makes it look like a terminal multiplexer (ala tmux) as an electron app (which would be way overkill in my eyes). I assume there are some specifics that made you choose Electron for this?

                          Apart from performance I share concerns posted by qbit in this comment. I also had the chance to look under the hood of Chrome (while porting Dart), it’s a very large and complex code base. With each electron app you ship you are bundling up a full copy of that with no easy ways to distribute security patches for a code base that gets regularly hunted down for security issues (see how frequently Chrome releases sec. patches). On top of that it’s not running on OpenBSD, and knowing what it takes to port that I doubt it ever will without upstream efforts.

                          1. 2

                            That’s just a very early screenshot with the ssh app running in each pane – really just a placeholder for now until I go into beta.

                            The idea for the app is that its a desktop gui with multiple tabs & panes that lets you connect (ssh), transfer (sftp), monitor (graphical realtime dashboard combining a lot of /proc files like cpuinfo, uptime, loadavg, meminfo, net/dev, and disk stats from df), manage processes (graphical process manager), provision (aiming to support all major VPS apis) and deploy (both a built in Ansible IDE and graphical runner). Sort of like a desktop cpanel on steriods without the security concern of installing any software on your servers.

                            I have a lot of ideas for “applets” within the app but I’m probably just going to go into beta with the ssh and dashboard applet enabled.

                            The reason I chose Electron is mostly for cross platform support and because the stack I’m using (TypeScript+React) enables me to build graphical apps much faster than if I used platform native controls. I’ve built a lot of native apps over the years on a lot of platforms and I really appreciate the development experience that Electron provides.

                          2. 1

                            What is your application going to deliver that ConEmu or ITerm2 + tmux don’t? The 3 hosts limit, in particular, seems kinda strange.

                            1. 1

                              Taking the risk of sounding like a spammer I’ll just re-use my comment from above.

                              The idea for the app is that its a desktop gui with multiple tabs & panes that lets you connect (ssh), transfer (sftp), monitor (graphical realtime dashboard combining a lot of /proc files like cpuinfo, uptime, loadavg, meminfo, net/dev, and disk stats from df), manage processes (graphical process manager), provision (aiming to support all major VPS apis) and deploy (both a built in Ansible IDE and graphical runner). Sort of like a desktop cpanel on steriods without the security concern of installing any software on your servers.

                              The 3 hosts limit is to allow for hobbysts and students to use the full program for free. Once I have provisioning and development working well in the app I’d like it to become the app you recommend to people when they say they need to setup a server on Linode, DO, etc. The app will come with a lot prebaked Ansible playbooks to securely setup a server with an initial frontend like puphpet.com that then lets you drop down in an Ansible IDE for tweaking and later editing.

                              1. 1

                                Ok, that makes more sense. That actually sounds kinda cool. You should mention those things on your site, instead of just showing the SSH shells.

                                1. 1

                                  That page is just a placeholder and I’ve really only mentioned it on this site. I plan on adding to the site soon once I get out of “friends and family” alpha stage. Thanks for the feedback!