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.
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)
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.
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.
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.
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.
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.
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.
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.
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)
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.
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.
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