Jitsi Meet Electron 2.0(github.com)
github.com
Jitsi Meet Electron 2.0
https://github.com/jitsi/jitsi-meet-electron/releases
165 comments
How do you feel about contributing what you’ve learned to the documentation?
I have been thinking about this exact use case! Are you going to share your party app?
Not OP, but I also made a party app (unrelated to jitsi). It's barebones, but you can use it free and anonymous at https://zonko.chat
Though Jitsi is also usable via "zero-install browser only", the electron package allows additional features like e.g., desktop sharing with remote control.
And due to bundled Chrome, some Firefox RTP problems are also circumvented with the Electron desktop version.
> And due to bundled Chrome
... bundled Chromium, ...
... bundled Chromium, ...
Does this have any privacy implications? ISTR Google made it very hard to remove Google stuff even from Chromium.
Not that much, just the brand and some less calls to home (but chromium still calls home)
You cant run browser extensions in your electron app, but you can in the website version. So for privacy, expect more tracking, fingerprinting and less control. That's not the case for Jitsi, just in general all electron based website wrappers.
If Chromium still calls home, does that mean the MSFT has to remove all that code to turn it into Edge?
If so, that seems like a lot of work. Especially if you want to verify that it’s removed for future versions.
If so, that seems like a lot of work. Especially if you want to verify that it’s removed for future versions.
No, they just have to edit it so it calls home to them.
Still a lot of work though :P
Still a lot of work though :P
exactly, see: https://github.com/Eloston/ungoogled-chromium
What is the significance of the distinction?
I haven’t tried this, but I have been on Zoom meetings with 30 simultaneous screens going at a good framerate on a normal device in Gallery Mode, and 400 participants.
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?
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?
we’ve used it with 30 users in gallery mode, works fine. Another group has used it with 500 people, and it seems to have worked as well.
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.
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.
Ah this explains so much! We were having a lot of trouble having meetings with more than 5 people. Nobody here uses chrome (for good reasons.)
Is there an issue on Firefox side tracking this problem ? as it seems a very big problem for that specific use case, and may be one of the reason why slack / teams etc. don't support firefox in their webapp ?
Various issues that have been open for quite a long time [1].
[1] https://github.com/jitsi/jitsi-meet/issues/4758#issuecomment...
[1] https://github.com/jitsi/jitsi-meet/issues/4758#issuecomment...
He was asking about an issue on the Firefox bugzilla instance, not on the Jitsi side.
The linked comment links to relevant Bugzilla bugs :)
It would be great if it could work. I am a bit of an Electron skeptic, though. Maybe browser canvases can give decent native performance, and we could dispense with Electron.
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.
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.
I understand the hate for Zoom. But...
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...
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...
> 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.
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.
Lots of people up in arms about Zoom et al but I personally don't care. If Microsoft or Zoom wants to foot the bill to give me HQ video I'd rather take that then waste my own bandwith on p2p.
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
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
Did anyone use Firefox? There's a fairly significant issue with video simulcast in FF, and if anyone on the call broadcasts video on FF it will use significantly more bandwidth than users on Chrome/Chromium-based browsers.
Tbh zoom on Linux is utter garbage. Every time I join a meeting, my CPU goes into deep frying territory. It's like compiling on heroin. In all fairness skype has been the most reliable for me so far, with jitsi being a close second.
Jitsi uses WebRC, so it's p2p. It's great for 2 person calls, could be good for 3 as long as you all have good connections to each other, but doesn't and will never scale higher.
I think this is just false. If you have more than 2 people I think there will be some bridge which picks the speaker and downscales other video feeds
Jitsi can work in either peer-to-peer mode or with a "videobridge" that acts as a server in much the same style as Zoom et al.
Any difference in the CPU usage?
So one app less to worry about unless it is required by a customer.
Can anyone explain how Jitsi is funded? Who's paying for the resources? Seems unwise to use software like that that's provided for free.
From the FAQ : "We are fortunate that our friends at 8×8 fully fund the project. 8×8 uses Jitsi technology in products like Virtual Office. The open source community and meet.jit.si service help to make Jitsi better, which makes 8×8 products better, which helps to further fund Jitsi. This virtuous cycle has worked well in the past and should continue to for many years to come."
If Facebook would be ads-free, free, and open-source, would you use it? I'd be scared as hell. Imagine this line:
> 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).
> 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).
Jitsi being open source removes a lot of that scare.
5 seconds of research yields this: https://jitsi.org/built-on-jitsi/#partners
Sorry, I thought this is obvious, but I guess I have to re-state my question. The business model is unclear to me, they don't even make money on ads like Facebook, so it might be something worse.
What's the point for them to put all the money in?
What's the point for them to put all the money in?
8x8 uses Jitsi for their video calls. Therefore funding Jitsi improves their paid service. I hope this clarifies it.
Doesn't make sense to me, sorry. I imagine paying for servers to run free Jitsi for all the people is tens of thousands of dollars per month (if not hundreds). Are you saying that it makes more sense than hiring additional developers for that money?
I don't think it's quite as expensive as you might think. Unfortunately I don't have sources right now but from memory the server component mostly handles session management.
Will try dig up some posts...
EDIT: Looks like one person self-hosted an instance on a Hetzner cloud instance for 2,49€ a month. https://dev.to/noandrea/self-hosted-jitsi-server-with-authen...
Regarding the official Jitsi meet site: "On a plain Xeon server (like this one) that you can rent for about a hundred dollars, for about 20% CPU you will be able to run 1000+ video streams using an average of 550 Mbps!"
https://jitsi.org/jitsi-videobridge-performance-evaluation/
I'm not a backend guy so not sure if this takes everything into account.
Will try dig up some posts...
EDIT: Looks like one person self-hosted an instance on a Hetzner cloud instance for 2,49€ a month. https://dev.to/noandrea/self-hosted-jitsi-server-with-authen...
Regarding the official Jitsi meet site: "On a plain Xeon server (like this one) that you can rent for about a hundred dollars, for about 20% CPU you will be able to run 1000+ video streams using an average of 550 Mbps!"
https://jitsi.org/jitsi-videobridge-performance-evaluation/
I'm not a backend guy so not sure if this takes everything into account.
Don't know about owners and such but you can set up your own server if needed.
Yeah, that'd cost you a substantial amount, probably more than paying for a Zoom subscription. Now imagine someone is just paying for you, for free, no ads. Isn't that weird? All I'm saying.
For small-medium groups, it runs just fine on a VPS that's half the price of a single paid Zoom account.
Alright everyone time to tear down all your Linux and Postgres servers...
Would you be willing to pay my AWS bills? It'll improve the open-source community!
No because you don't have a useful open source project. Otherwise you'd already have a sponsor
Why are the macOS and Windows versions are unsigned?
I understand not signing on Windows — it's a nightmare of incompetent, but expensive CAs, and unusable poorly documented mostly-broken tooling from the '90s. And in the end it hardly does anything, as you still get the executable blocked for a month.
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.
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.
> And in the end it hardly does anything, as you still get the executable blocked for a month.
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.
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.
Except when the signtool.exe defaults to SHA-1, generating a signature that Windows won't accept. And then you need to add an arg for a timeserver. And args in a wrong order just silently generate a useless signature. And documentation for all of it is mostly from IE5.5 era, fragmented over several unfinished reorganizations of MSDN.
And tooling for managing the certs is another pain. Mine required entering a PIN from a GUI every time certs were touched, so I couldn't automate the builds.
And tooling for managing the certs is another pain. Mine required entering a PIN from a GUI every time certs were touched, so I couldn't automate the builds.
It’s absolutely none of those things. $300 for five years and a single executable to do the signing with.
It costs money
Jitsi Meet is already on the iOS App Store. That would mean they already have an Apple developer account with which they could sign the Electron app.
Isn't Jitsi co-developed/sponsored by 8x8? An Apple developer account costs 99 per year. If the money is a problem, a lot of people would probably donate some amount if that helps getting signed releases.
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!).
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!).
Isn't the hoop just right-click and choose open? Or is there something more nowadays?
If by "hoop" you mean "workaround," yes. But normies are used to starting applications by double-left-clicking them, and there's nothing in the error message that appears after that indicating it can be worked around. Unless the normie thinks to ask a friend or the internet how they can go ahead and open the app anyway, they'll never find out about it.
To come at it from another direction, why is it your users' responsibility to work around your own cheapness/laziness? Just front the $100 and sign your damn app, especially if you're making money with it.
To come at it from another direction, why is it your users' responsibility to work around your own cheapness/laziness? Just front the $100 and sign your damn app, especially if you're making money with it.
As Cyberdog says, the hoop is that a lot of regular users do not know about.
Moreover, signatures and notarization are there for a reason. Code signing makes it more likely that the bundle was not tampered with. Apple can revoke the certificate if the developer key leaked. Notarization will catch at least some forms of malware.
I refuse to run unsigned code (with one exception), because it decreases security significantly. There have also been severe incidents in the past with unsigned code, e.g.:
https://blog.malwarebytes.com/threat-analysis/mac-threat-ana...
Moreover, signatures and notarization are there for a reason. Code signing makes it more likely that the bundle was not tampered with. Apple can revoke the certificate if the developer key leaked. Notarization will catch at least some forms of malware.
I refuse to run unsigned code (with one exception), because it decreases security significantly. There have also been severe incidents in the past with unsigned code, e.g.:
https://blog.malwarebytes.com/threat-analysis/mac-threat-ana...
in some cases, it can't be installed at all depending on the privileges.
We can help here. We'll do it free. Jitsi guys: Email me dave[at]todesktop.com.
This is just one of my guess here. If you look at the commit history the project doesn't look like being the main focus. Code signing is not as streamlined as Let's encrypt, the money part makes it bumpy, so I'm not surprised.
Not sure I understand your offerings. You seem to suggest that you offer code signing without an Apple Developer subscription? So are you using your own certificates to sign your clients’ code? If that’s the case it sounds like you’re probably breaking TOS and opening up your clients to immense risk: one client’s abuse results in all clients’ apps revoked.
edit: nvm
Unless free actually means a cash allowance (which would be very generous), I don’t see how this would work. I’m certainly not gonna let someone else register and pay for an Apple Developer account on my behalf.
It costs $100 a year to sign Apple programs (last time I was doing it). Jitsi has a corporate sponsor. Nobody involved with Jitsi could swing it? Really?
Authors explain why code signing (currently) was skipped here: https://github.com/jitsi/jitsi-meet-electron/issues/234#issu...
I've tried it before, but it seems to be only usable with the instance hosted at meet.jit.si. When I try to connect to any other instance, I'm just getting the error "external API not enabled". Sounds like there is some default configuration that prevents this from being used with most selfhosted instances.
The readme mentions this, and how to fix it: https://github.com/jitsi/jitsi-meet-electron#using-it-with-y...
I want to love Jitsi, I really do. But the 'Quick Install' of the server failed for me. So I tried the hosted service and it doesn't work in Firefox. Jitsi needs to work harder on ease of use.
Where did you find the quick install and what OS were you using? I was trying so hard to find a Jitsi server install for Windows but the only thing I found was a jar+batch file process that I couldn't connect to once I finally got it running.
Janus is easier to deploy and scales well.
Before the "We hate Electron" crowd gets here - congrats to all involved on this release: so far it works great, the UX is simple enough for anyone to use, it's open source and most importantly - it isn't Zoom.
Good enough for me.
Good enough for me.
I'm part of the crowd that dislikes the trend to use electron for everything. I have 8gb of soldered Ram on my laptop, and will be forced to buy a new machine because I'm swapping like crazy now. My workflow hasn't changed. My activity hasn't. But 2 years ago, Firefox and Virtualbox were the only hogs, for reasons I could accept. Now, dynalist, stremio, discord, signal, pulsesms and vscode are added to the mix.
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.
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.
> 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.
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.
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.
> Plenty of native desktop/mobile apps do video/audio/text without embedding a browser.
Yes and it's a pain to do: format is limited, packaging is hard, ability to manipulate/embed the video is annoying. In fact, most apps doing that ship ffmpeg and/or vlc and call it a day. The browser gives so you much for free.
Yes and it's a pain to do: format is limited, packaging is hard, ability to manipulate/embed the video is annoying. In fact, most apps doing that ship ffmpeg and/or vlc and call it a day. The browser gives so you much for free.
> The browser gives so you much for free.
including arguably the most attacked and compromised software surface in history.
including arguably the most attacked and compromised software surface in history.
Is it? ffmpeg as a library can decode about anything you want and put it in a buffer in less than 100 lines. Is that not for free? It's a self contained shared library.
Electron apps have the slowest interfaces on anything I've seen, lots of times each click of a button or menu has lag on a very solid computer. Who wants to have a program doing video embedded in a painfully slow interface?
Electron apps have the slowest interfaces on anything I've seen, lots of times each click of a button or menu has lag on a very solid computer. Who wants to have a program doing video embedded in a painfully slow interface?
This implies you dev in C or C++, and do all the controls, lifecycle and fallbacks yourself.
That a huge price.
That a huge price.
What do you mean by lifecycle and fallbacks? Also you just said that building in multimedia was the problem and when I point out libraries are easy to use and modular you say that C++ is the problem.
I think you are giving too much credit to people using electron. It really seems to be mostly people who haven't really looked at their options avoiding native languages at the expense of the user. If all someone knows is javascript and they don't really care about their users' lag or resources, then electron is any easy choice.
I think you are giving too much credit to people using electron. It really seems to be mostly people who haven't really looked at their options avoiding native languages at the expense of the user. If all someone knows is javascript and they don't really care about their users' lag or resources, then electron is any easy choice.
When I buy a computer, the first thing I look for is extendable memory. If I can't easily plopp in at least double the RAM than it has, I'm not buying it. Got bitten already enough with the old 286+ era computers. Since then the memory consumption has been increasing the whole time until now you can't even start your editor without 1-2 GB disappearing. Want a browser too? That's another GB at least. A chat program? Another GB. The times where a chat client was 40 kb are long gone, now it has to have emotes and embeded movies at a minimum.
Funny thing is, 2 years ago I had a machine with 32gb, and I never passed 16 even while willingly opening everything just for fun.
I though it was too much, and downgraded for a small, cheaper and more portable machine.
Today, I think 32 would be just right.
2 years, lol.
I though it was too much, and downgraded for a small, cheaper and more portable machine.
Today, I think 32 would be just right.
2 years, lol.
I had the freakish opposite experience where I went from an 8gb linux machine that was scraping the top of that to a 16gb machine at the same time I switched from openSUSE's standard release to their rolling release (Tumbleweed). My memory usage immediately dropped by 30-40% and the bits that didn't were all Electron-based. Even Waterfox with 4K tabs dropped significantly. I have no idea how they managed it, but it was a pleasant surprise at the same time it highlighted that if you use a lot of Electron apps there are no good options.
Imagine when Windows 10 is "updated" to essentially be a chromium browser with typescript used for all UI and builtin utilities. In such a case only special windows store apps are able to be installed... this is the future Microsoft and Google want for us.
I would imagine such a monstrostiy would be so slow with even 32gb that we would have to pay for extra cloud-based services to do menial tasks like edit documents.
God help us all.
I would imagine such a monstrostiy would be so slow with even 32gb that we would have to pay for extra cloud-based services to do menial tasks like edit documents.
God help us all.
It's been envisioned already:
https://www.destroyallsoftware.com/talks/the-birth-and-death...
The talk is hilarious, and very much on point.
https://www.destroyallsoftware.com/talks/the-birth-and-death...
The talk is hilarious, and very much on point.
I bought a mac with 32gb in 2013, figuring this would be good for a long while... these days with mem usage constantly hanging around 28-30gb, I'm now choosing between 64 and 128 for the next machine (with 128+ only being available in apple's 'pro' line...).
Without Electron many of programs/apps would not be available on Linux. I'm happy Electron exist and we have overall more Linux desktop compatibility in an easy way. Electron fulfilled what Java has envisioned, it's only bad there is not an universal ONE runtime below that all (although there are Electron bugs on github where this is worked on).
Any previous solution to do UI: QT, GTK, WX, etc were cross plateforms.
I don't think that's it.
Electron make it easy, if you know front end dev, to do an app. It's easy to package as well.
I don't know if you tried to design a beautiful QT app, but it's hard. A beautiful QT app with medias capabilities ? Extra hard. Packaging that? A royal pain.
I don't think that's it.
Electron make it easy, if you know front end dev, to do an app. It's easy to package as well.
I don't know if you tried to design a beautiful QT app, but it's hard. A beautiful QT app with medias capabilities ? Extra hard. Packaging that? A royal pain.
(minor side-note, since it's repeated: it's Qt. small "t".)
Yeah, because centring divs or making drop down menus out of unordered lists is so easy.
You don't, you have kits to do most things for you. That's the beauty of it: you can reuse the entire web community assets.
And when there are no existing widgets, crafting one is way, way easier than with QT. Especially with break points.
And when there are no existing widgets, crafting one is way, way easier than with QT. Especially with break points.
Yeah, right because component libraries aren't a thing in native UI since the early 90's.
Highly recommend Ripcord[1] to anyone who dreads opening Discord or Slack.
[1]https://cancel.fm/ripcord/
[1]https://cancel.fm/ripcord/
Now if only we didn't have to worry about Discord arbitrarily banning accounts for daring to use a third party client..
Agreed, although I've been using Ripcord for almost two years now, I typically use it for casual Discord use.
> My workflow hasn't changed. My activity hasn't.
> 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, 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
Sure, and you don't have to use a more modern car, you can always keep your old phones for 10 years.
But you would be very annoyed if when you upgrade, you'd notice the car actually eats more gas.
That's not what happens though. Modern cars are more ergonomics, and eat less gas.
It's not being entitled. It's just noting the drawbacks of some technological choices.
But you would be very annoyed if when you upgrade, you'd notice the car actually eats more gas.
That's not what happens though. Modern cars are more ergonomics, and eat less gas.
It's not being entitled. It's just noting the drawbacks of some technological choices.
These are all just more recent variants of tools which we have always used, e.g. some chat apps, some editor, etc. In that way, not much has changed. It make sense though to move on to newer tools, which are basically the same tools though, just updated, maybe more modern features, not necessarily more features in total.
And maybe offering these modern features is so much easier using the electron platform that offering the features based in something else is not worth doing.
There must be a benefit for developers for them to chose electron. And that benefit for developers will have an effect for the users in either more features, quicker rollout or more supported platforms.
There must be a benefit for developers for them to chose electron. And that benefit for developers will have an effect for the users in either more features, quicker rollout or more supported platforms.
I have a suggestion for you that helped me. Try running Android OS like Prime OS (https://primeos.in) in virtual box and you can run those Android apps with low memory usage(I'm assuming that they offer the same experience in Mobile or that you are okay with limited functionality). I set this up for my wife as she kept complaining that her 8 Gb RAM was quickly consumed by Chrome, Slack, Spotify and other apps.
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
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
I though about it, as a workaround. But realistically:
- my base ram consumption is 2Gb, so it would make 5gb with the VM, giving me 3gb for: firefox, and IDE, thunderbird, telegram, stremio, libreoffice, nautilus, veracrypt, liferea, gnome calendar, keypass, dev tools such as linter/dev servers/formatters, tilix, veracrypt, youtube-dl, jupyter, other VM I use for work... Even if I don't use them all at the same time, that's not a lot real estate. It used to be enough. When I used sublime instead of vscode, didn't have 4 communications apps and so on. You gotta hand it to the electron community: their software do bring good features.
- The ergonomics would be terrible for certain softwares. For chat, it would be alright (no notification is ok with me), but for stuff like dynalist, I need to be productive
- It's slow to use. You can feel the reaction time with every action. Android is slow in itself, but in an emulator, you want chain too many actions
- my base ram consumption is 2Gb, so it would make 5gb with the VM, giving me 3gb for: firefox, and IDE, thunderbird, telegram, stremio, libreoffice, nautilus, veracrypt, liferea, gnome calendar, keypass, dev tools such as linter/dev servers/formatters, tilix, veracrypt, youtube-dl, jupyter, other VM I use for work... Even if I don't use them all at the same time, that's not a lot real estate. It used to be enough. When I used sublime instead of vscode, didn't have 4 communications apps and so on. You gotta hand it to the electron community: their software do bring good features.
- The ergonomics would be terrible for certain softwares. For chat, it would be alright (no notification is ok with me), but for stuff like dynalist, I need to be productive
- It's slow to use. You can feel the reaction time with every action. Android is slow in itself, but in an emulator, you want chain too many actions
That's a lot of functionality! How are you handling it? I expect it to get worse as more and more electron apps keep showing up.
Well, would a shared electron runtime make things better [0]?
[0] https://news.ycombinator.com/item?id=22774088
[0] https://news.ycombinator.com/item?id=22774088
Yes and no.
Yes if people used it, but no because people would probably not.
One of the reason electron is so easy to package: it creates a big blog of statically linked everything. If you start having to play the packaging game correctly, you get back to the same problems other run time had.
So my guess would be most users would not do it.
Yes if people used it, but no because people would probably not.
One of the reason electron is so easy to package: it creates a big blog of statically linked everything. If you start having to play the packaging game correctly, you get back to the same problems other run time had.
So my guess would be most users would not do it.
> How are you handling it?
What do you mean?
What do you mean?
So, how to improve Electron?
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 ?
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 ?
The only improvement I see is to move away from electron. For alternatives everyone should take a look at Revery-ui written in Reasonml. Its starts in milliseconds, few megs of RAM usage, very low CPU usage and has most of the modern developer experience associated with Electron!!
MS probably knows. VSCode without any extension is pretty reactive and light. It becomes heavy when you have 20 tabs open with linters, languages servers, formatters and so on.
So maybe we CAN make electron lighter.
So maybe we CAN make electron lighter.
The real solution is of course to use the web browser as the "shared library", and develop a true PWA.
I know it's not always possible, but the web now offers a lot of powerful API's.
I know it's not always possible, but the web now offers a lot of powerful API's.
PWA are very limited:
- can't (realistically) use an alternative runtime. You are stuck with the JS ecosystem.
- can't start when the OS starts
- can't integrate with the UI (task bar, explorer menu, etc)
- can't run a server in the background for native perfs (like most electron apps actually do)
- can't open a server or a communication bus to allow apps cooperation, or playing well with the OS
- can't access the file system in any meaningful way to provide any kind of scanning ability
- can't store data reliably, or in any reasonable quantity
- can't call other local apps, run commands, etc
- can't access local libraries: so you do the crypto, hashing, dataprocessing in pure js
- can't access any non standard peripherics
- can't use the network, forget about avahi/bonjour, broacasting, capturing packets or doing CORS
- can't (realistically) use an alternative runtime. You are stuck with the JS ecosystem.
- can't start when the OS starts
- can't integrate with the UI (task bar, explorer menu, etc)
- can't run a server in the background for native perfs (like most electron apps actually do)
- can't open a server or a communication bus to allow apps cooperation, or playing well with the OS
- can't access the file system in any meaningful way to provide any kind of scanning ability
- can't store data reliably, or in any reasonable quantity
- can't call other local apps, run commands, etc
- can't access local libraries: so you do the crypto, hashing, dataprocessing in pure js
- can't access any non standard peripherics
- can't use the network, forget about avahi/bonjour, broacasting, capturing packets or doing CORS
Like I said, it has limitations.
But your comparison is also not really fair, since you assume everything runs and is stored on your local computer. This is not the case anymore at all.
Plus, the web browser is probably the first application that is started by a user.
Following applications all run in my browser: - email - video conferencing with screen sharing - (persistent) chatting - Office applications (word processor, spreadsheet, ...) - photo storage - games - development sandboxes - ...
In fact most Apps I have on my phone could just be PWA's.
I'm not saying we should all go web, but I'm saying that most things where you want to use electron, you could let it run on the web.
But your comparison is also not really fair, since you assume everything runs and is stored on your local computer. This is not the case anymore at all.
Plus, the web browser is probably the first application that is started by a user.
Following applications all run in my browser: - email - video conferencing with screen sharing - (persistent) chatting - Office applications (word processor, spreadsheet, ...) - photo storage - games - development sandboxes - ...
In fact most Apps I have on my phone could just be PWA's.
I'm not saying we should all go web, but I'm saying that most things where you want to use electron, you could let it run on the web.
You listed a whole bunch of "downsides" but they look more like good security measures for running an app inside a browser.
Half of the softwares installed on my computer would not run because of those good security measures.
The browser let you do CRUD apps, with a hint of medias handling. That's it.
And not even good ones since your storage can be wiped out an any moment.
The browser let you do CRUD apps, with a hint of medias handling. That's it.
And not even good ones since your storage can be wiped out an any moment.
That makes sense!
< Does it use a new instance for every app >
Unfortunately, yes.
Unfortunately, yes.
In principle, there is no reason why Electron must be so memory inefficient, right? We could optimize it in a way that it only loads resources it really needs. So in case of a video chat app, it would need video, audio, web RTC, a bit of HTML and JS. That should be possible to fit in a few MB of RAM. Only because Electron supports much more doesn't mean it must take so much memory.
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.
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.
MS does that pretty well with VSCode I think. It doesn't seem to be the default experience though.
Another route is to share the same resources between apps, i.e. make a progressive web app. I haven't used the Jitsi desktop app so I can't speak to it, but I'd be curious to know what features are missing from PWAs that mean a native wrapped Electron app is necessary.
But being more specific here: What exactly are the shared resources? The binaries? That could maybe save a couple of hundred MB but this is maybe still not the biggest part. The remaining memory is probably sitting there in memory allocations of JS or so, and I don't think that can be shared.
> The remaining memory is probably sitting there in memory allocations of JS or so
I'm not so sure about that. 5 Electron apps takes up far more memory than 5 tabs open in your browser because there are 5 copies of all the other browser resources. I don't know exactly what they are but anecdotal observation of using Slack and similar apps as browser tabs shows much less memory use. It makes sense: the browser rendering engine and JavaScript engine are going to occupy memory themselves.
I'm not so sure about that. 5 Electron apps takes up far more memory than 5 tabs open in your browser because there are 5 copies of all the other browser resources. I don't know exactly what they are but anecdotal observation of using Slack and similar apps as browser tabs shows much less memory use. It makes sense: the browser rendering engine and JavaScript engine are going to occupy memory themselves.
Yes, as evidence for this web browsers sitting at an empty new tab page are generally still using at least 100-200mb to do nothing. The likelihood that most of that is not the part that's most vital and feature rich is low.
I wonder if https://github.com/sentialx/electron-global could help with your issues
First time I hear about Dynalist. I'll add that to the ever growing note-taking apps I'm trying out.
It's a excellent software for managing things to do, and I pay monthly for it. It is very efficient to use, works offline and on mobile seamlessly, use a JSON format for storage, and can export in a standard format to avoid locking (even on the free plan).
I use it to manage things to do, listing, etc., but I would not use it for taking notes, IMO. The format doesn't look great for it.
Anyway, the free plan is good enough to try it on, and the customer support excellent.
I hope it will never be bought by some giant.
I use it to manage things to do, listing, etc., but I would not use it for taking notes, IMO. The format doesn't look great for it.
Anyway, the free plan is good enough to try it on, and the customer support excellent.
I hope it will never be bought by some giant.
I quickly played with the demo. I'm more a note-taking kind of guy than a todoist. I love the UI but yeah, since everything is a list it's not for me. For my use, Google Tasks is enough for me.
I've tried Evernote, Boostnote, Simplenotes, Notion, even a bunch of markdown files inside a Github repo and so far nothing was 100% perfect for me. :)
I've tried Evernote, Boostnote, Simplenotes, Notion, even a bunch of markdown files inside a Github repo and so far nothing was 100% perfect for me. :)
I tried. So. Many. Apps.
Same. I always go back to using the file system:
- it has a hierarchy
- I can use whatever file format I want, mix in images, odt, pdf, md, etc
- I can backup and sync
VSCode is a pretty good editor to manage it all, and I played with the idea of creating an app with the new editor view feature of the last version just for that. Support some metadata, create an automatic encrypted sync server and that's it.
So ironically... An electron app.
Same. I always go back to using the file system:
- it has a hierarchy
- I can use whatever file format I want, mix in images, odt, pdf, md, etc
- I can backup and sync
VSCode is a pretty good editor to manage it all, and I played with the idea of creating an app with the new editor view feature of the last version just for that. Support some metadata, create an automatic encrypted sync server and that's it.
So ironically... An electron app.
You shouldn't be using slack with 8gb of ram, use ripcord instead.
That's my point. Ripcord is not built using electron, yet provide the same features as the original slack app.
And it’s built by one developer, and supports Slack and Discord!
Imagine what these massive companies could do if they made their own native clients.
Imagine what these massive companies could do if they made their own native clients.
It wasn't anything like the original Slack app last I used it a few months back. Has this changed? It doesn't have a keyboard shortcut to jump between unread channels as a basic example. Or hiding read channels, so I've got a huuuge list.
>telegram
Doesn't Telegram use Qt?
Doesn't Telegram use Qt?
Yup. Telegram Desktop[1] and the web client[2] are separate projects.
The desktop client is still quite heavy on resources on Linux, and needs a restart every now and then.
[1] https://github.com/telegramdesktop/tdesktop
[2] https://github.com/zhukov/webogram
[1] https://github.com/telegramdesktop/tdesktop
[2] https://github.com/zhukov/webogram
I have exactly one electron app (VSCode) that I need for my regular daily work. Everything else I shut down when I don't need it. Then I look at my coworkers who have dozens of apps running at the same time and complaining that their laptop is slow, and I only shake my head…
Yeah, why having a multitask OS when you can do the scheduler job manually?
Card carrying member of the unnecessarily complicated stack skeptic's club here, but this is something Electron actually makes sense for. This is one of the few cases where bundling a complete WebRTC stack makes sense, because it's actually being used, and bundling the web browser could potentially make permission management a bit easier which is probably one of the remaining usability problems.
Couldn't they rip-out the WebRTC stack - leaving out the RAM-hungry parts of Electron/Chromium/V8/etc that aren't relevant to desktop applications (e.g. aggressive in-memory caching, process isolation, etc)?
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.
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.
The WebRTC stack depends on:
- the network code
- the video and audio playing code
- the video and audio capture code
- the crypto code
Making that generic is a huge task nobody will every do. So since you embed them, why no elso embed the UI code ? I mean, at this point...
- the network code
- the video and audio playing code
- the video and audio capture code
- the crypto code
Making that generic is a huge task nobody will every do. So since you embed them, why no elso embed the UI code ? I mean, at this point...
Not to mention making that generic would want to be accepted upstream in order to have upstream maintain this interface
I just wonder why an electron like chromium library isn't just provided by default by Windows and Linux. Then it could be updated by the system vs. each app updating individually and be much more secure.
The Electron team is tracking an issue for introducing an Electron runtime that is shared between multiple apps...
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...
[2] https://github.com/zserge/webview
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...
[2] https://github.com/zserge/webview
[deleted]
> Before the "We hate Electron" crowd gets here
This is one of those comments that has the same effect as its opposite (in this case, changing the subject).
This is one of those comments that has the same effect as its opposite (in this case, changing the subject).
I don't get it. Why make people download an app when the same thing can work in the regular Chrome browser? Just bookmark it or something.
If you don't get it, read the page
https://github.com/jitsi/jitsi-meet-electron#features
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...
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...
Ok but besides that one feature, almost every other feature can be done in Chrome. I run Slack in Chrome. Why not? Because of some features I don’t need?
I like native apps on my machine. I have enough tabs open in chrome as it is. And when I want side-by-side views of a Slack tab and some other webpage, those tabs turn into mutliple chrome windows. Then I'm alt-tabbing between Chrome - Chrome - Chrome - Mail - IDEA - Chrome - Terminal. Why is it so bad to install an app? This has been the default since computers became a thing, so what's the argument for sticking everything into your browser?
Why do people hate Zoom so much? I just received an email today from Zoom outlying all the fixes they just released.
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.
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.
Most problems they had (at least those reported on) were not really tied to the number of users though, that would be quite excusable. The criticism was mostly poor security[1] due to bad decisions in the first place.
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_...
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_...
They straight up lied about offering E2E encryption. Don't know if that's fixed, actually.
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).
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).
> So what they struggled?
It's not about that. People realized the privacy implications and the fact that Zoom was not forthcoming about some aspects of it.
It's not about that. People realized the privacy implications and the fact that Zoom was not forthcoming about some aspects of it.
> Stop hating Zoom.
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.
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.
this is tech, you can't trust anyone. it's par for the course here. zoom just happen to be chinese.
This has absolutely nothing to do with where Zoom is developed or by whom. It is the stated privacy policy and the software engineering practices to which the company adheres - and the security best practices to which they do not - which are abhorrent to me. This isn't about tech. This isn't about nationality. This is about a social tool being used to exploit people and the network effects that has on others who may have no choice.
That's why Jitsi Meet is important. It is everything Zoom isn't - while still accomplishing nearly everything Zoom attempts to accomplish while exploiting its users. That's why it's important.
Yes, you can trust - so long as you always verify while trusting.
That's why Jitsi Meet is important. It is everything Zoom isn't - while still accomplishing nearly everything Zoom attempts to accomplish while exploiting its users. That's why it's important.
Yes, you can trust - so long as you always verify while trusting.
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.