I love having multiple copies of Chromium installed on my system at the same time. 250 MB internet messengers please!
ā¢
You ever notice how everything installs and uninstalls super cleanly and easily these days and software gets consistent regular updates?
That's because developers stopped min/maxing storage and started bundling all of an application's dependencies with it instead of trying to rely on globally installed packages and frameworks that can break or be missing or lead to dependency hell.
No one likes larger download sizes and more storage being used but the tradeoff is by and large worth it.
ā¢
Isn't this about performance and not storage?
Making and managing an electron app is easier, but it is possible (with more work) to have clean install/uninstall, a nice UI, and consistent regular updates while still being fast and efficient.
Better programs will always need more work to create.
I am curious about what other options there are, and why Electron is what a lot of people go with.
ā¢
Options:
Native app for each platform:
- Pros: native code is going to be the fastest possible to run and have the smallest dependencies
- Cons: have to write all your code 3+ times in different languages, have less time to develop new features and optimize existing code.
Progressive Web App:
- Pros: single app, write once runs anywhere, no signing keys, no lock in, can be hosted anywhere, runs on everything
- Cons: artificially limited by Apple on iOS, doesn't have access to deep operating system resources, only what's exposed through the browser, limited multithreading capabilities
React Native:
- Pros: single app, write once, runs anywhere, similar enough to React Web that a lot of developers will have an easy time learning it
- Cons: still kinda finnicky, not super easy to make it work and perform well across all platforms, you'll probably still end up having to write some native code, not actually CSS / React Web so still a bit of a learning curve coming from there
Qt:
- Pros: single app, write once, runs anywhere, low level / compiled means that it will be small and performant
- Cons: written in C++, harder to find developers for, harder to implement modern out of the box niceties that CSS gives you for free, poor devX compared to react
.NET MAUI (formerly Xamarin):
- Pros: single app, write once, runs anywhere, low level / compiled enough to be more performant than most web apps out of the box, well documented
- Cons: written in C#, easier to find devs for but not many experts in it specifically, MVVM model is not as pleasant of a devX as React, again no css
Electron:
- Pros: single app, write once, runs anywhere, has full access to operating system resources and deep multithreading if needed, can be as simple as web app in a container or as complex as something like VSCode.
- Cons: takes up more storage and ram since you're bundling chromium with your app
People choose Electron because they already know how to write Chromium apps (web dev). It's really just ease of development, using another framework takes more specialized skills than using Electron.
That's why everything is Chromium these days.
ā¢
Thatās why everything is Chromium these days.
The root cause is one step deeper, tbh: Web apps are cheaper. You take BSc's and make them create web pages, and hey, with Chromium they can also be your desktop app devs. No need to have costly MSc's for backend or full-stack work.
I mean this might vary depending on where in the world you are, but web devs earn a fair bit less over here.
It's not really because the developers are cheaper, it's because the vast reduction in complexity is cheaper. Let's say you've got a great general app idea and you're going to build a startup. Your app is going to have to be mobile and desktop. To do that well, natively, this means:
- you're going to need a backend dev who are probably going to be building APIs that are touching on web tech.
- You're going to need a developer team who can target Apple platforms, Android, and Windows. I lump Apple together here because although it's not entirely fair to say that it's as simple as they promise where you just click a box and your iOS app works on macOS, you're at least able to work in the same general toolset (Swift, SwiftUI, Xcode, etc.)
- You're going to need designers who can design to the specific needs of the platforms, which is also going to mean more domain expertise.
- testing for each of those platforms.
- This is true regardless, but you're going to have to deal with more platform-specific support. More platform specific documentation, etc. How do you do think x on platform y? Where is the button on this platform vs that one?
- maintaining feature parity as you continue to build is going to be much more difficult, and you're going to have to decide if you want to maintain feature parity and slow the whole process, or give up and launch on some platforms first (hopefully there is no one that uses a Mac and an Android phone or Windows and an iPhone or an iPhone and a Samsung Tablet or that gets annoying real fast.)
In short, moving from one platform to two natively doesn't double complexity and cost, it's far, far worse than that. It's not that a good web dev costs $70k vs an iOS dev that makes $90k, it's that a good iOS dev costs $90k, and a good Android dev costs $85k, and a good Windows dev costs $80k and one of those people hopefully is familiar enough with each platform to be the team lead so you can tack on another $20k for them...
And all the while you're building that team and building your 3 different platform native apps, a competitor or several will launch on Electron and web tech and take the market because no one except us nerds give a shit about whether something is using the right platform idiom or even knows what they are, and far fewer still have any idea how to check RAM usage and the like.
ā¢
No need to have costly MScās for backend or full-stack work.
Lmao where are you seeing backend shops just full of MSc's writing new sorting algorithm and arguing about the BigO notation of their problem?
I've worked at Fortune 500 and MAANG companies, and the overwhelming vast majority of backend engineers that I've seen have BScs at best.
It doesn't even make logical sense in the context of your argument given that Electron is purely a frontend technology. It has no bearing on your backend costs or how many backend engineers you need if you're building your frontend natively or with Electron.
ā¢
It doesnāt even make logical sense in the context of your argument given that Electron is purely a frontend technology. It has no bearing on your backend costs or how many backend engineers you need if youāre building your frontend natively or with Electron.
Yeah, that's what I said.
ā¢
You take BScās and make them create web pages, and hey, with Chromium they can also be your desktop app devs. No need to have costly MScās for backend or full-stack work.
?
In this situation you never needed MSc's...
ā¢
You ever notice how everything installs and uninstalls super cleanly and easily these days and software gets consistent regular updates?
Not really. Well maybe I take it for granted having switched to Linux.
I mostly hate Electron for the dumb RAM usage.
ā¢
Pretty sure that's more about a switch from physical distribution where storage is expensive (CDs) to digital where it's cheap.
ā¢
250 MB internet messengers please
Hum... Make them some of those large-sized megabytes if it's Teams.
ā¢
Teams is truly exceptional, more so because the same company has VSCode.
Both show the inherent lag and sluggishness of Electron apps, but they're on totally opposite ends of the spectrum. Which is wild. It's like a case study or something.
ā¢
Wouldn't it be great if there was a way for all these electron apps to share the same runtime so people don't have to bundle it with their applications.
You know, I bet if the applications without the runtime are small enough, you could probably stream them directly from the internet without even downloading anything up front!
I guess that shared runtime would need some way to browse the applications....
^(vscode gets a pass)
ā¢
Use the system webview, you cowards!
Developers bundle all of Chromium, because they're afraid the OS webview will have a different browser engine. Testing is too hardā¦
This is such a terrible excuse ā usually the same app runs in browsers too, so it already has to deal with even wider variety of browser engines.
ā¢
I will say that unless something's changed in Windows recently, the win32 API webview is still a vestigial version of internet explorer due to Microsoft's obsession with non breaking changes (not saying that's a bad thing)
Given I lived through those years as an engineer, I completely understand people wanting to avoid that particular ancient eldritch horror.
Edit: apparently there's webview2 now based on edge (and therefore chromium), I take it all back
ā¢
I mean even for something like .NET, apps install the version of the runtime they need in a shared space, so that they can be used by everyone desiring that specific version.
ā¢
Ooh! Just unlocked a memory of a computer I was setting up and one piece of software assumed its version of .NET would be present and just failed install every time because it wasn't. I ended up just installing it later once I had other stuff installed
ā¢
You mean instead of downloading the app, we could just browse through them? That's a revolutionary concept. We could call them hyper-apps!
ā¢
Outside of PWA shortcomings, I believe there's a way to have a .NET application run a WebView with Edge (Chromium). I believe Windows 11 has both pre-installed now.
I don't even want to run NodeJS anymore. I would run all my server apps on headless Chromium if I could.
ā¢
Don't bundle your app, let the CDNs do their job. God damn, that's revolutionary.
Hopefully your idea takes off like the idiot that started the "monorepos" craze.
To your credit, your idea is actually good.
ā¢
We live in a timeline where desktop apps all run in a browser, whereas mobile websites are all their own apps.
ā¢
For now at least, PWAs work on Android and I believe many apps already use electron or something similar under the hood
ā¢
When I worked support for an android device manufacturer I had some strange issues with other apps that were resolved by clearing the cache in Chrome. Its all webpages all the way up and down baby!
ā¢
ā¢
Yet Internet just scaled up to handle worldwide traffic, while WWW evolved into mess noone is able to implement anymore.
ā¢
ā¢
Inspect any major website, you'll see boilerplate of <div><div><div><div> and unreadable pile of JavaScript programs your browser need to run to build the website.
Sites should be done in a way that is still readable after you disable one element (for example disable CSS function, scripts or HTML specific tag).
Internet is modular, based on stacked protocols. Want to fit Tor between TCP and HTTP? No problem. Web is also like that, build of semi-independent formats, in theory. But in practice devs are using frameworks that assume Chrome, Firefox and Safari are and would ever be the only things existing. Now if you want to develop new browser you not only need to display HTML and add other things later. You need to get all specifications of all standards working right away or sites would spectacularly break.</div></div></div></div>
ā¢
It's a bit of a shame that HTML went from describing documents to describing UIs. I do miss the days of simple websites, although I'm not old enough to remember the old old internet.
ā¢
What's the alternative? Or an alternative I guess I should say. I agree though, I wish folks would use HTML for all documents. Like why the hell am I downloading a PDF of a thing I'm never printing? (PDFs are still acceptable for printing though.)
ā¢
I don't think there's anything wrong with using HTML/XML-ish format for describing a UI (although having a standardized presentation format that all "viewers/browsers" follow exactly the same way would be nice), I'm just sad that websites have become described as UIs rather than as well-structured documents.
ā¢
ā¢
ā¢
Yes, the issue is with web developers not following standards. However, because all of them fail to do this, the problem ends up being with the browser that doesn't support everyone's non-standard developments.
I just want my text in the centre of the page (not with rows stretched across a widescreen monitor) and for things to not jump about as they load. Figure out where things should go, then display it.
ā¢
What else works across as many platforms and screen sizes as well as the combination of HTML/CSS/JS?
Most attempts to build that just lead to a worse version of it.
I'll be the first to admit it's bloated to all hell after 25 years of people stacking crap on top of more crap, and it's perilously close to being completely controlled by Google, but it is what it is.
ā¢
What else works across as many platforms and screen sizes as well as the combination of HTML/CSS/JS?
Doom. It runs on every-fucking-thing
ā¢
(Undergirded ever so slightly by a Raspberry Pi but don't mention it)
ā¢
Maybe I do not specify clearly what I mean.
Why to order taxi, access bank, register a domain name do we have to have apps on all platforms and then to fix this problem we bloat the web by creating webapps. Why not just plain simple HTML website beautified with CSS instead?
Real cross-platform apps are those written in, for example QT. Then came Android and iOS forcing everyone to use their toolkits so we started to abuse poor web.
ā¢
Well I'm in agreement there.
The only reason they want everything as an app is so they can push notifications and do any tracking they can legally get away with (and some they can't but who's gonna know?)
Dominos have locked all their deals that actually make a pizza a normal price that humans would willingly pay for a pizza behind their app. There's no reason for them to do this. Surely their business model is selling pizza? So now I go to a little family run pizza shop, pay less and get decent pizza.
ā¢
Yep.
Your standard web browser has to many privacy protections for you and your data.
Its why they want to push you to an app, that asks for WAY to many permissions to do what it needs to do. Cause it doesnt need that access to function. It needs that access to monitize you. Cause they make more off stealing your information, than they do off you being a customer, Which is why you get so many discounts for using apps.
ā¢
It seems every new shiny technology today tries its darndest to short-circuit 40+ years of advances in OS virtual memory design. Between Electron and Docker, the entire idea of loading an image into memory once and sharing its pages among hundreds of processes is basically dead. But at least there's lower support burden!!!1111
ā¢
Docker is just a lightweight container that has the app and OS all in one package. It uses the underlying kernel of the host system. No where near the same as electron apps.
ā¢
Except each container has its own libc and any other dependencies. If any linked binary or library has a different inode, it gets loaded separately. I would say it is indeed quite similar, even if the images in question here aren't hundreds of megabytes in size like with Electron.
That's not entirely true. OverlayFS supports page cache sharing for files in image layers. If your images share the same base image layer, then it should share libc and friends in the page cache.
https://docs.docker.com/storage/storagedriver/overlayfs-driver/#overlayfs-and-docker-performance
ā¢
"Different inode" means a different file entirely, not necessarily its majorminor:inode tuple resolved through bind mounts/overlayFS/whatever. I'm saying that if you have containers using even slightly different base images, you effectively have n copies of libc in memory at once on the same system, which does not happen when you do not use containers.
If you're running enough images on the same machine to make that a relevant point, you have absolutely no excuse not to provide common base images.
Basically, there are two scenarios here: you're running some service for others to deploy their images (Azure etc), then you want isolation. Or you're running your own images, then you should absolutely provide a common base image.
ā¢
If your applications require different libc versions, then regardless if you used containers or not, you'd have each of them in memory. If they don't require different versions, then you're just blaming containers for something the user is responsible for managing. When alpine images are a dozen or so MBs, base image disk size is basically irrelevant in the grand scheme of things, as you probably have much more than that in dependencies/runtimes. Even Debian base images are pretty tiny these days. Depending on the application, you could have just a single binary with no OS files at all. So if you do care about disk and memory space, then you would take advantage of the tools containers give you to optimize for that. Its the users choice on how many resources they want to use, its not the fault of the tooling.
ā¢
The funny thing is, as much as people shit on Java, that's exactly what its Java EE container arch was for. Truly tiny microservices in wars, an entire app in an ear. All managed by a parent container that can dedup dependencies with a global class loader if done well, and automatically scale wars horizontally, too.
No idea how to get that level of sharing with OS-level containers.
ā¢
Still the same issue of a still pretty big overhead that is unnecessary in the vast majority of situations.
At my current workpalce, ~20% of hardware goes to docker. Is it still worth it? For the company it is I assume, since we can let developers with fuck all operations experience deploy stuff without bricking our servers. But we could also be hiring operations people who know how to run applications on servers without fucking them up, but of course in a money game docker wins out for ease and speed.
Importantly, comparing stuff like Electron though, we can scale up the hardware and that's included in the cost of running docker. Desktop users stuck with shit like VSCode, Beekeeper or Mongo Compass can't realistically do that though, PC upgrades aren't something you do in 10 minutes and even then your options are limited.
So for companies and servers, docker makes a lot of sense. Especially on the business side. For a private end user, these virtualization tools remove the potential performance all that fancy hardware nowadays could provide. And in the case of Electron shit, they also make for a worse inconsistent UI and laggy interactions.
ā¢
Hey, what do you mean 20% of your hardware goes to docker? If you're not running linux then docker isn't the issue, it's the VM. If you are running linux, it should be just as lightweight as say, systemd
ā¢
Yea, docker only eats up storage. And not even much, if you share the same base image.
Not really any CPU or RAM overhead
ā¢
So for companies and servers, docker makes a lot of sense. Especially on the business side. For a private end user, these virtualization tools remove the potential performance all that fancy hardware nowadays could provide.
Excellent point!
ā¢
As a freelance fronted dev, I really love Docker. I don't need to mess up my system installing ancient Java versions or whatever Python wants to easy_install, pip or whatever, I can just run the backend Docker image and go on with my life. Especially when project A's backend has incompatible Java/Ruby/Python dependencies with project B.
You can shit on npm all you want (yes, I was there for left_pad), but at least they got the dependency issues between projects solved.
ā¢
Electron is awesome, badly coded apps just suck. Look at Voyager for Lemmy, it's great and it's just a web app.
ā¢
Electron apps are nice in some ways, but use a ton of memory
I usually don't mind electron apps too much, but I do prefer native apps
ā¢
No, it's not nice. Looks good only on Windows where everything have unmaching look anyway.
ā¢
Uh huh. Electron apps look good on Windows. Sure.
No electron app ever looks good anywhere. They are consistent insofar that they look shit on all OS, equally. And alias their fonts wrong. And scale them wrong. And break accessibility.
ā¢
They don't break accessibility. Electron fares better in accessibility than some native app frameworks.
ā¢
Sure, there's always a bar to clear. And yet Electron can't even properly alias fonts if the creator doesn't do it properly, as it tries to use Chrome's broken font rendering by default. Nevermind scaling the size of anything, which just becomes a blurry mess if the app wasn't created well enough (see the mess that is Signal as an example).
ā¢
Voyager is made with Ionic. The difference with Electron is that in Ionic, trough Swift/Kotlin, shows a WebView from the System Browser (mobile only) while Electron āinstallsā Chrome each time (desktop only).
WebApps are great, but Electron is just too much
ā¢
If I have to load elements from the web just to use the electron app properly, Iād rather use a web app and load the whole page each time and not have the tracking.
ā¢
Folks in this thread complaining about Electron I think miss the point. It is a trade-off. It is designed to allow engineers who have a web dev skillset to write desktop apps. For those like me who want to write the occasional hobby app - it's great. It's also great for orgs to be able to have cross functional teams. Just like React Native allows this for the mobile world. This could be because they're small and can't afford specialist native engineers for each platform they want to support - or it could be that they want to spend their money in other areas and happy to trade off app performance. If it was as lean or as performant as native apps there would be a lot of people in this thread looking for work.
ā¢
Electron is just the "easiest, most common option", because things like TauriJS and NeutralinoJS exist, which do what electron does without having to bundle a whole-ass Chrome browser.
ā¢
It's not terrible, electron is good for stuff like what you discuss
I just like native apps better haha
ā¢
Native apps have the potential to be better than electron apps for sure. I get that.
This is a surface level thing though - the question is: would THIS app, written by THAT organisation be better if it was native? Unlikely because they don't have the skillset for it...otherwise it would have been a native app. Its also likely that less apps would even exist because the barrier to entry is higher without electron and similar.
But this is just a meme and I'm taking this way too seriously!
ā¢
It's still terrible because of its ram usage, electron uses minimum 300Mb per instance so that's 3GB for 10 apps while if you open them all in Chrome you save 100s of mb
ā¢
Chrome won't give Web apps access to the file system amongst other things. I'm a firm proponent of web apps - but they can't do everything a desktop app can, and so electron offers an alternative with the trade offs I mentioned.
ā¢
That's why I got 32GB ram when I upgrade my PC. I don't give a fuck to how many ram they use now.
ā¢
This is the same coping mechanism as "just build another 4 lane highway. That should solve the traffic issues". You are just shifting the problem.
ā¢
I'm not shifting the problem if I have actually paid the money to build the 4 lane highway.
ā¢
The point is that you're not fixing the problem, you're just masking it (and one could even argue enabling it).
The same way adding another 4 lane highway doesn't fix traffic long term (increasing highway throughput leads to more people leads to more cars leads to congestion all over again) simply adding more RAM is only a temporary solution.
Developers use the excuse of people having access to more RAM as justification to produce more and more bloated software. In 5 years you'll likely struggle even with 32GiB, because everything uses more.
That's not sustainable, and it's not necessary.
ā¢
The same way adding another 4 lane highway doesnāt fix traffic long term (increasing highway throughput leads to more people leads to more cars leads to congestion all over again) simply adding more RAM is only a temporary solution.
How is adding more RAM a temporary solution? It would lead more workload to the CPU... which is good?
ā¢
- People have enough RAM.
- Developers see people getting more RAM.
- Developers allow their software to use more RAM (either by doing more cool stuff or optimizing less stuff).
- People have little RAM.
- People buy more RAM.
- goto 1;
This also applies to CPU and GPU.
ā¢
You're giving the devs too much credit. They didn't give a fuck even when we have not enough RAM. Otherwise this post won't be such a common experience.
ā¢
I don't know much about car traffics but I don't see how adding more RAM to solve the problem of not having enough RAM is a poor solution
ā¢
The idea is that increasing road capacity will increase demand and basically make traffic as bas again and similarly "just add more ram"-ing will just lead to developers using less memory efficient practices leading the same situation down the line.
ā¢
Which is a flaw logic as it implies
- The RAM capacity of any PC is a publicly available information like the road capacity; AND
- Electron app developers are checking info of 1. (if it's somehow available) to decide how they optimize their app. Which doesn't seems reasonable as electron apps are not games and thus not expected to use 100% RAM.
ā¢
Of course the average amount of ram in computers isn't some secret. What are you on about? It's only thanks to the fact that we have gigabytes of ram these days that inefficient practices are possible. If developers didn't know that, they would have no idea that was possible. How on earth do you think developers would ever optimise software and determine their performance requirements if specs were unknown? I'm not saying they're snooping on YOU individually (although there's a ton of telemetry these days everywhere and ram is probably a common statistic collected by software - Steam's hardware survey is public and shows millions of computer's specs. Any software you use knows your ram capacity - it's not secret. The ram capacity of newly sold systems is public is obviously shown on spec sheets)...
ā¢
I got 32 on my desktop so I'm fine there, but my laptop explodes if I try to run the same amount of stuff with 8GB ram
ā¢
Easy solution, get a laptop with 32 GB RAM/s
Seriously though, the problem is either on both or on neither. It's an additional expense on the customer though, like everything else nowadays. I personally ended up getting a super powered laptop/tablet and relying on it for all my computing needs because laptops are good enough for most use cases nowadays and desktops are limited to specific use cases.
Thinking about it though, the reason it's only limited tasks needing more power might be because everything else is electron.
ā¢
My friend... have you heard of our lord and savior downloadmoreram.com? You can DOWNLOAD more ram FOR FREE!
ā¢
Yeah, then we can have marginally more responsive web apps.
Seriously though, web apps are usually just optimized like shit in addition to using chrome.
ā¢
Do you know what this even is? It's not marginal at all. Check the comparisons of Tauri and Electron. And it does not use Chrome. Electron also doesn't use Chrome.
ā¢
Tauri is the exact same problem, just done a bit more cleanly.
The problem is the evolutionary dead end that - hopefully - is web framework based "desktop" apps. There is already a framework for desktop apps, and unless you're still used to those, you wouldn't notice just how slow any web framework is by comparison. It's mostly the user interactions, that small but noticably delay on every interaction, every click, every type, everything. Funnily enough, my actual web browser (Firefox) shows one of the shortest delays when typing into web pages like this compared to all the "native apps" I got installed that are just web pages, too.
Tauri is an improvement. To the problem. It's not a solution.
ā¢
We just not there yet. Tauri tries to be Electron or React, where you write only once and use everywhere. This is very cost efficient. So even though it's of course not perfect overall, but it is the perfect alternative, that brings web apps closer to native-like experience. Small but important step to greatness.
In the end the question is: Election or Tauri? And not a debate on whether web frameworks are bad etc.
ā¢
Basically, but not basically. After all, Chromium is (F)OSS, and Chrome is proprietary.
ā¢
I think most people are more upset about the engine being the only thing devs target now, similar to the old IE days, not as much on the chrome vs chromium aspect when it comes to this.
ā¢
I was pleasantly surprised to find a tauri app in the wild at my work. Our time tracking software uses it, at least for the Linux version.
ā¢
Oh of COURSE, how could I be so stupid
That is hilarious though, I got some German friends I need to ask about this
ā¢
Dutch people use it (although I doubt it's an official word), meaning something like "that's what you get" or "oh well".
ā¢
Well, people tend to pick the easiest way to achieve an objective, even though the solution is not simple nor optimised.
ā¢
Audio chat is "not supported" by discord in Firefox last I checked. Are you spoofing user agent also?
ā¢
It works for me.
I did originally have some issues and did some searching that there used to be firefox issues that are now resolved. Mine were fixed by restarting my VPN, but otherwise no problems.
ā¢
Damn, I didn't even think about running Discord in a separate FF instance like that. Been looking for a more privacy focused approach then installing from the .deb. Thanks man!
ā¢
I use a separate FF profile. It has no addons, apart from Vencord and a custom userChrome.css to hide the top tab bar (as full screening it would obstruct swaybar). I then just made an xdg .desktop entry which opens canary.discord.com with firefox using that profile.
Overall it somehow uses less RAM (albeit with another FF instance open, so maybe some resources are shared) than the official App and all other forks (eg. custom electron version) I looked at. Nearly everything works, but:
- File upload for the soundboards is greyed out, switching user agents to chrome results in some obscure error
- Game activity does not work as the browser version cannot access the process list (Though that never even worked acceptable on Linux anyway)
- I did not manage to get xdg-desktop-portal to run properly for screen sharing on Wayland with Nvidia, as - bummer - the latter misses something in their driver. So no screen sharing for discord either
- You sometimes suddenly 'rejoin' a call/VC, which produces a very annoying sound every time. It's either a problem with my connection or the browser version of discord (or both). Disabling join/leave sounds 'fixes' that
Overall all of those problems are a better alternative to the constant flickering that happened with all electron apps on my system if they are not interacted with for a few minutes (eg. by being on another monitor/workspace). That's just distracting as hell and often even breaks functionality. And of course, Nvidia is at fault again. Like for 90% of other problems with my system.
::: spoiler
Little rant: Some issues that happen on my Nvidia system (wayland) that are not present on my Dell Laptop w/ Intel HD graphics. I spent hours and days researching those Problems with potential solutions, very few improved some things a bit.
- Electron apps flicker
- Generally, windows with less than 60 FPS will flicker, with transparent stripes letting you see the background/wallpaper
- Firefox sometimes just freezes whole websites, you need to un- and reload the site to continue using it. May be related to hardware accelerated mode tho.
- One update temporarily let games in full screen freeze. Even after killing them. And it still displayed after switching to a tty and back. And it even persisted killing the wayland session. It was just a frozen picture on output 2 forever, while in graphics mode.
- Features such as sharing the screen via xdg-desktop-portal do not work :::
ā¢
The main thing that keeps me from running messaging applications in the browser is the lack of a tray icon
ā¢
Sadly the audio quality sucks for discord web for me on Linux. Maybe because there's either little or no audio processing unlike in the desktop app with krisp or whatever
ā¢
We use flutter and the app on iOS and Android look great. The web version looks and works like shit though