Good enough for me.
However, I understand that said apps may have not existed without Electron at all.
And especially, for jitsi, I think it makes perfect sense. If you are going to create an app that does video, audio and web rtc, it would be silly not to use a battle tested browser engine that does all this already.
Besides, having contemplated the state of UI in a world were you have a bazillions of combination of hardware type + screen format + OS kernel + OS version, I have to say Electron doesn't have much competition.
What are you going to do? QT? Phone support is abysmal and it's a pain to package. Kivy? Super slow, almost no widgets. Flutter ? Uses a niche language with a very small ecosystem and an unknown life expectancy.
I probably would go with the later, but I can't blame people for taking the easy road.
I think you mean "create an app that does video, audio USING web rtc".
Plenty of native desktop/mobile apps do video/audio/text without embedding a browser.
> Now, dynalist, stremio, discord, signal, pulsesms and vscode are added to the mix.
So your workflow has changed. You added additional tools to it. These tools have always been electron. You don’t have to use them. There are alternatives.
The people behind these tools have decided that they target an audience you don’t belong to. You are of course free to ask them to change the audience, but you are not entitled to that
Now the virtual box memory limit is set at 3 GB and she has no complaints. Obviously this is not for power users but it helps a lot when there is a severe shortage in memory
Does it use a new instance for every app, or it loads the engine once and reuses some of it for every instance? ie. can Electron be made to work like a system shared library, similar to GTK/Qt ?
Maybe it would make sense that we just focus on optimizing Electron for this case. That might take a bit of effort, but that effort might be worth it.
As much as we all have strong opinions about Electron, surely someone who is able to make a solidly built "DOM+CSS+JS+Optional extras" version of Electron would be make _bank_ overnight by servicing and consulting for it? I know lots of companies would love a build of Electron with a smaller attack-surface, for example.
https://github.com/electron/electron/issues/673
I suppose one issue is that you have to either be very good with backwards compatibility or at least support having a single instance of multiple different versions of the runtime installed side-by-side (e.g. similar to .NET Core).
There is also this.. 'Exploring lighter alternatives to Electron for hosting a Blazor desktop app' [1], which builds upon 'webview' [2].
[1] https://blog.stevensanderson.com/2019/11/01/exploring-lighte...
This is one of those comments that has the same effect as its opposite (in this case, changing the subject).
But for macOS it's way easier, and more needed. It actually silences the scary warnings. It's even a real security improvement, as you get your app's keychain protected.
This is very much not true - if you have unsigned executables for an app of any scale, 3rd party AV will be extremely Unkind to your app, especially if you try to do updates. Also, how long your app gets blocked depends on how many downloads you get, if your app is popular it can be unblocked in a matter of hours, and once a download URL is deemed trusted, this is largely a non-problem.
Also, while I'll 100% agree that CAs on Windows are a nightmare, the tooling is extremely straightforward, signtool.exe takes your cert file, a password, and an executable, then signs it.
At any rate, I think having unsigned binaries that are not notarized introduces additional hoops for non-expert users, since macOS requires signed bundles by default (which is a good thing!).
> We are fortunate that our friends at GoodCorp fully fund the project. GoodCorp uses Facebook technology in products like GoodCorp Social. The open source community and meet.facebook.com service help to make Facebook better, which makes GoodCorp products better, which helps to further fund Facebook. This virtuous cycle has worked well in the past and should continue to for many years to come."
And keep in mind that Jitsi seems like a more resource-hungry product (real-time video).
What's the point for them to put all the money in?
We have tried Jitsi a few weeks ago. And we couldn’t scale to meetings with more than 5 people. We tried our own server and theirs.
Then there is Skype and Hangouts. With both I can only meet for two hours or so on battery.
Somehow Zoom works flawlessly. Very easy setup and it worked straight out of the box and is not CPU hungry.
The UX is also great. It’s clear what the buttons are and do. Compare that to Skype where it’s not even clear when something is a button, and even then it’s often just an icon, which means nothing to me.
The product is great. But you pay with your personal data, I guess...
I doubt it's any worse than what you give out to Google or Microsoft for their solutions. After all, those are targeted advertising companies. Zoom had bundled the Facebook SDK to enable their social login, but removed it after the discovery that it phones home.
Some of the security threats to zoom are real of course, but I couldn't care less if Microsoft uses telemetry or whatever if I get a good service in return. I log into 20 different things with Google and Facebook and Microsoft already
They went from 10m users/week to 200m/week in less than one month.
So what they struggled? Most products would struggle with that kind of ramp up. They owned up to it and fixed pretty much all the complaints. And they're providing a valuable service to the world, most of it for free.
Stop hating Zoom.
It mostly highlights that in order to rush the product out of the door many shortcuts were taken and security shouldn't be one of them in this day and age.
[1]: https://www.schneier.com/blog/archives/2020/04/security_and_...
Apple had to release an update of their OS to remove Zooms rootkit.
(I'm not a Zoom user, but that's just because my employer uses something else).
It's not about that. People realized the privacy implications and the fact that Zoom was not forthcoming about some aspects of it.
No. I don't trust Zoom. I don't like that people like you apologise for them while they continue to make choices that actively endanger users.
I don't like their business model, and I don't like that I'm forced to use it to interact with people. I don't like that I can't verify it's doing what it says it's doing and am actively prevented from doing so. I don't like Zoom and I don't like that I can't choose to not install their spyware because people who don't know any better and don't have any way to protect themselves keep installing it and forcing me to use it.
No. I won't stop hating Zoom until I - and the people who don't know how Zoom is hurting them and so use it anyway - can be free of it and the people who make it so awful.
That seems to be Zoom’s signature achievement. I have not had any other commercial app even come close.
How does this compare, in endpoint software?
A major issue is still Firefox, as Firefox does not support simultaneously sending two WebRTC streams, so Firefox users heavily reduce performance for all other users as well, but the rest seems to work just fine.
I agree about Zoom’s failings. The existence of Facebook is living proof that privacy is a concern for only a relatively small number of folks.
However, there’s a big “but”. The documentation is abysmal. I’m sorry but that’s the cold hard truth. It’s been a nightmare to understand the pieces working while also using their libraries. Incredibly hard to read, and incomplete, docs. I’ve had to refer to the source to try figure things out most of the time. I say this because I think there’s soooo much potential there if it was more accessible. If you’re from jitsi and are keen for some good and critical feedback then hit me up, I’d love to help you out.
... bundled Chromium, ...
Just one example: the Jitsi Meet Electron app e.g., allows you to remote control a screen, if screen owner allows. This makes it a replacement for e.g. TeamViewer, VNC or so...
