Hacker News Reader

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

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

> The browser gives so you much for free.

including arguably the most attacked and compromised software surface in history.

Most attacked, I could believe. Most compromised, I'm not so sure. Browser teams ship out new versions very regularly, it's nothing compared to vulnerabilities contained within the first release of Windows XP, for example.

How many of those XP vulnerabilities were IE vulnerabilities?

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?

This implies you dev in C or C++, and do all the controls, lifecycle and fallbacks yourself.

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.

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

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.

It's been envisioned already:

https://www.destroyallsoftware.com/talks/the-birth-and-death...

The talk is hilarious, and very much on point.

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.

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.

Yeah, right because component libraries aren't a thing in native UI since the early 90's.

(minor side-note, since it's repeated: it's Qt. small "t".)

Highly recommend Ripcord[1] to anyone who dreads opening Discord or Slack.

[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

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.

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.

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

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

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

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.

> How are you handling it?

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 ?

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.

That makes sense!

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

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.

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.

< Does it use a new instance for every app >

Unfortunately, yes.

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!!

https://github.com/sentialx/electron-global

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.

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.

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.

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.

MS does that pretty well with VSCode I think. It doesn't seem to be the default experience though.

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

Telegram is a QT app, btw. Still can take quite a bit of RAM, but much less than, say, Signal or Slack.

Most of the RAM usage when it comes to Telegram (and other IMs I guess) is media autodownload. Once you turn it off - the problem is solved (same for the battery life on mobile)

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.

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?

My bad: https://github.com/telegramdesktop/tdesktop/tree/dev/Telegra...

I'll edit

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

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?