-
reezer
1 year ago
|
link
| on:
Facts about Electron Performance (from the Postage for PostgreSQL project)
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.
-
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.
-
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.
-
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.
-
-
yumaikas
edited
1 year ago
|
link
| on:
Facts about Electron Performance (from the Postage for PostgreSQL project)
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?
-
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.
-
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.
-
-
-
I know we keep saying we have autocomplete figured out and then you try to use it and it only works half the time BUT we really did a lot of work on it and we think it’s the best one yet. Hopefully we don’t have any show-stopping problems out there. Please file an issue if we do!!! https://github.com/workflowproducts/postage/issues
-
justintocci
1 year ago
|
link
| on:
Free, Open Source PGAdmin replacement Postage has a huge release today!
And all these new users caused us to fix a couple issues and tada! V3.2.2:
-
Since postage runs in a browser
Why is everything inside a browser now? Are native GUIs really that hard to work with?
-
-
Actually, we don’t even use jQuery. From the about box:
doT.js Version 1.0.3 Ace Editor Version 1.1.01 json_parse.js (modified) Version Unknown d3.js Version 3.5.16
Postage is built on Envelope technology. You get full featured widgets that connect straight to the database like so:
<gs-datasheet src=“tablename”></gs-datasheet>
-
-
-
Very good question. Thank you for asking.
Postage is built on Envelope technology. Envelope technology allows us to quickly write desktop-like database applications with rich interfaces including desktop quality widgets very quickly.
We’ve used Postage internally for many years but then had the idea of open sourcing it to show off how desktop-rich and performant a web app could be.
There is an issue open on Github that considers using Electron to make a desktop version. If you’re in favor of that then please make your voice heard there. https://github.com/workflowproducts/postage/issues/1
-
-
Workflow Products (makers of Postage) Testing PGAdmin4 now.
-
Downloaded to Windows. Installing now. I really like how the install process assumes you want to start PGAdmin.
-
I’m going to move this to slack.
Postgresteam.slack.com PGAdmin channel
-
Fun! Our reason for testing today was explicitly to test the speed. We claim in the Postage documentation that Postage is a fast alternative to PGAdmin. I was concerned that we’d need to remove that claim but I’m going to let it stand for now. Remote connections are our normal way of working and we want all the speed we can get. This was the original reason for writing our own Postgres SQL tool.
Our conclusion: We congratulate EDb and everyone that contributed to PGAdmin4. It’s a great product and looks to very shortly make Postage redundant. You all have our highest praise.
-
-
-
-
Michael and Nunzio put together a map that shows Postage users across the world…
-
Just checked out the repo. Looks like lots of work has gone into it already. Very cool to read about an alternative.
Can you guys add some screenshots to the website please?
-
added! thank you for the suggestion!
-
-
<gs-img class="image-id-1" style="background-image: url("images/ScreenShot1.png");" src="images/ScreenShot1.png" min-width="all {247px,200px}; sml {507px,409px};"></gs-img>What’s
gs-img? These don’t seem to be backwards compatible with the standardimgtag, and cannot be viewed without CSS, it looks like. (Even with CSS, they’re scaled down, and aren’t very accessible.) I think it’s best to use the standardimg, and make the images be links to themselves for easier viewing/zooming.-
<gs-img> is a web component. You are absolutely right, those should click through. We’ll add that. Thank you for the suggestion.
-
I made it so that the images zoom when you click on them (you may need to refresh the page). Thanks for the feedback.
-
that didn’t really work as well as hoped so now if you click on an image it just opens the image in a new tab.
-
-
-
-
-
I visited several of the links in this story but I could not understand what makes pgAdmin a pain point with postgresql. Now, I’m mostly a MS SQL Server user and so I relate pgAdmin to MS SQL Server Management Studio.
-
The original impetus was to bring it to a web page so that we could fix stuff while at customer sites. Often we’d walk up to a computer for the first time (we’re mostly remote) and have to install PGAdmin3 to start working.
We suspected that we could build something faster than our fifteen year old competitor, but even we were shocked at how much faster remote access is when using LibPq and a C binary. Once we saw the speed difference in our testing we were full speed ahead on building it.
We have autocomplete and can handle 20000 tables easy without scrolling speed issues (or crashing like PgAdmin).
Our datasheet view allows arbitrary selection with copy and paste, for example, you can select a few columns a few records down and paste over them. The copy and paste functionality is very rich.
Also, having a web client gives you more deployment options. We typically install it on our dev boxes but you could install Postage on the same server as your database. It doesn’t require a separate web server. It doesn’t require any config change to put it behind Nginx or Apache in a reverse proxy either, though you’d probably want to turn off SSL on the web side if it’s on the same box as the web server. It’s pretty slick.
-
-
Our C programmer tried to get a VM set up with Electron on OpenBSD so we could do testing. It was a massive time suck and never did get it working. It cost us a lot and the whole situation was very unfortunate.
At the moment, Electron is the easiest way to get a web browser app and packager. If there were something better, we’d try to use it.
This was posted recently: https://github.com/pojala/electrino
It’s effectively electron, but without the web browser & uses the system browser / javascript runtime directly instead of bundling it’s own. Not perfect, but easier to ship than electron!
I love it!