5 ms·
> A lot of the blame gets placed on easy to see things like an Electron app I think this blame is fair. Electron is the most obvious example, but in general de
by blincoln 3y ago
> A lot of the blame gets placed on easy to see things like an Electron app
I think this blame is fair. Electron is the most obvious example, but in general desktop software that essentially embeds a full browser instance because it makes development slightly easier is the culprit in almost every case I've experienced.
I use a Windows 10 laptop for work.[1] The app that has the most lag and worst performance impact for as long as I've used the laptop is Microsoft Teams. Historically, chat/conferencing apps would be pretty lightweight, but Teams is an Electron app, so it spawns eight processes, over 200 threads, and consumes about 1GB of memory while idle.
Slack is a similar situation. Six processes, over 100 threads, ~750MB RAM while idle. For a chat app!
Microsoft recently added embedded Edge browser controls into the entire Office 365 suite (basically embraced-and-extended Electron), and sure enough, Office is now super laggy too. For example, accepting changes in a Word doc with change tracking enabled now takes anywhere from 5-20 seconds per change, where it was almost instantaneous before. Eight msedgewebview2.exe processes, ~150 threads, but at least it's only consuming about 250MB of RAM.
Meanwhile, I can run native code, .NET, Java, etc. with reasonable performance as long as the Electron apps aren't also running. I can run multiple Linux VMs simultaneously on this laptop with good response times, or I can run 1-2 Electron apps. It's pretty silly.
[1] Core i5, 16GB RAM, SSD storage. Not top of the line, but typical issue for a business environment.
- dmonitor 3y agoDon't blame Electron for Teams. It certainly doesn't help, but there's plenty of Electron apps that are perfectly functional and fairly snappy. Just compare it with VS Code. Same company, both Electron apps. The difference is astonishing.
- tracker1 3y agoCreate a cross-platform UI toolkit that is easy to use, has all the accessibility features of the browser built in, and has a UI control toolkit as rich as say mui.com ... Support SVG as well as stylized layout similar to html+css. It's not an easy task, and it's not something that anyone has really done. There are plenty of single platform examples, and Flutter is about as close as you can get in terms of cross platform. There are also alternatives that can use the engine of an installed OS browser. Tauri is a decent example for Rust. Also, Electron isn't to blame for the issues with Teams. VS Code pretty much proves you can create a relatively responsive application in a browser interface.
- CyberDildonics 3y agoit's not something that anyone has really done It has been done many times. Not only that, if you want to use a web page for a GUI, then do it by making a local web server back end and just use the web browser. This idea that electron is somehow the only way to get cross platform GUIs is some sort of bizarre twilight zone where a bunch of people who only know javascript ignore that last three decades of software.
- refulgentis 3y ago[flagged]
- tracker1 3y agoOkay, care to name some of these many cross-platform, easy to use UI toolkits that include the accessibility that the browser has? Also, I never said Electron was the only way... I specifically mentioned Tauri in my comment as an example of a browser renderer. And it doesn't need to use a local web server either.
- CyberDildonics 3y agoQt, FLTK, WxWidgets And it doesn't need to use a local web server either. Shipping an entire browser so someone can pop up a single window is not a positive. Again, if you want html as your interface, use html and let people use their own browser so that the entire program is 400KB instead of 400 MB
- tracker1 3y agoQt, open-source only or expensive licensing. C++ only bindings... wouldn't call it "easy to use" FLTK, no accessibility features WxWidgets, really limited theming, not even close to html+css. Cross platform compatibility is hit and miss, usually requiring a lot of one-off platform corrections. Also, as I said, you don't need to ship the entire browser... not once, but twice... try reading slower.
- joshstrange 3y ago> because it makes development slightly easier That "slightly" is doing a massive amount of heavy lifting in that sentence. I run a company on the side that produces software for events which require a website and mobile apps for iOS (iPhone and iPad)/Android. I cannot imagine being able to do this all on my own without being able to share a codebase (mobile apps built via Capacitor) across all of them. Would native apps be faster? Almost certainly but I'm not going to learn Kotlin and Swift and triple the number of codebases I have to work it. It's completely infeasible for me, maybe some of you are able to do that but I'm not, there aren't enough hours in the day. I fully understand the cruft/baggage that methods like this bring but I also see first-hand what they allow a single developer to build on their own. I'll take that trade. I'm a little less forgiving of large companies but Discord and Slack (and other Electron apps) work fine for me, I don't see the issues people complain about.
- tom_ 3y agoTeams has at least 2, maybe even 3 people working on it.
- deleted 3y ago[deleted]
- mysterydip 3y ago> work fine for me, I don't see the issues people complain about. What are the specs on the machine you're using?