Most active commenters
  • tracker1(8)
  • CyberDildonics(6)

←back to thread

Windows NT on 600MHz machine opens apps instantly. What happened?

(twitter.com)
752 points dceddia | 13 comments | 23 Jun 23 14:02 UTC | HN request time: 0s | source | bottom
Show context
waboremo ◴[23 Jun 23 14:38 UTC] No.36447387[source]▶
We just rely on layers and layers of cruft. We then demand improvements when things get too bad, but we're only operating on the very top layer where even dramatic improvements and magic are irrelevant.

Windows is especially bad at this due to so much legacy reliance, which is also kind of why people still bother with Windows. Not to claim that Linux or MacOS don't have similar problems (ahem, Catalyst) but it's not as overt.

A lot of the blame gets placed on easy to see things like an Electron app, but really the problem is so substantial that even native apps perform slower, use more resources, and aren't doing a whole lot more than they used to. Windows Terminal is a great example of this.

Combine this with the fact that most teams aren't given the space to actually maintain (because maintaining doesn't result in direct profits), and you've got a winning combination!

replies(7): >>36447692 #>>36447714 #>>36447761 #>>36448103 #>>36448804 #>>36449621 #>>36458475 #
blincoln ◴[23 Jun 23 16:07 UTC] No.36448804[source]▶
> 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.

replies(3): >>36449096 #>>36450067 #>>36450235 #
tracker1 ◴[23 Jun 23 17:47 UTC] No.36450067[source]▶
Create 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.

replies(3): >>36450265 #>>36450385 #>>36451884 #
CyberDildonics ◴[23 Jun 23 18:03 UTC] No.36450265[source]▶
it'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.

replies(2): >>36450524 #>>36450699 #
tracker1 ◴[23 Jun 23 18:43 UTC] No.36450699{3}[source]▶
Okay, 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.

replies(1): >>36450838 #
1. CyberDildonics ◴[23 Jun 23 18:55 UTC] No.36450838{4}[source]▶
Qt, 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

replies(1): >>36450984 #
2. tracker1 ◴[23 Jun 23 19:10 UTC] No.36450984[source]▶
Qt, 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.

replies(2): >>36451369 #>>36451620 #
3. Narishma ◴[23 Jun 23 19:44 UTC] No.36451369[source]▶
Qt has been LGPL for ages. You can use it for free just fine in proprietary apps, as long as you don't modify Qt itself.
replies(1): >>36482607 #
4. CyberDildonics ◴[23 Jun 23 20:08 UTC] No.36451620[source]▶
Qt, open-source only or expensive licensing

It's LGPL, lots of programs use it like qTorrent, VLC and much more. You can make up criticisms but it has been a backbone of GUIs for decades.

FLTK, no accessibility features

What exactly do you need and do you need it for every GUI you make? If you want a web page, use a web page.

WxWidgets, really limited theming,

Suddenly theming is your deal breaker.

not even close to html+css

Thankfully, because that is often not a good way to make a GUI.

as I said, you don't need to ship the entire browser...

No, you said "it doesn't need to use a local web server either." Also 'entire web browser or not' electron programs end up being hundreds of megabytes for a simple window use hundreds of megabytes of RAM.

The bottom line here is not that electron is necessary. It is that you want to use javascript even though your users will hate it.

replies(1): >>36452348 #
5. mwcampbell ◴[23 Jun 23 21:25 UTC] No.36452348{3}[source]▶
> What exactly do you need and do you need it for every GUI you make?

A GUI toolkit that has no support for screen readers, or other assistive technologies that require accessibility APIs, should be a non-starter for most applications IMO. We need more options that meet that criterion without going all the way to a web page.

replies(3): >>36455625 #>>36482603 #>>36496056 #
6. CyberDildonics ◴[24 Jun 23 04:37 UTC] No.36455625{4}[source]▶
How is electron better than a web page for accessibility?
replies(1): >>36482587 #
7. tracker1 ◴[26 Jun 23 17:07 UTC] No.36482587{5}[source]▶
Browsers/Electron has great accessibility in the box.
replies(1): >>36486303 #
8. tracker1 ◴[26 Jun 23 17:08 UTC] No.36482603{4}[source]▶
From my original comment, "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"

So, you've failed to meet the requirements from the start.

I've also said, many times now, that you can use browser tech without an entire browser and the answer doesn't need to be electron.

9. tracker1 ◴[26 Jun 23 17:08 UTC] No.36482607{3}[source]▶
Sorry, I had forgotten.
10. CyberDildonics ◴[26 Jun 23 21:45 UTC] No.36486303{6}[source]▶
What does that mean and how does that answer the question? How is electron better than using a local webserver and web page for accessibility?
replies(1): >>36496103 #
11. tracker1 ◴[27 Jun 23 17:27 UTC] No.36496056{4}[source]▶
Sorry, accidentally replied under the wrong post below.
12. tracker1 ◴[27 Jun 23 17:31 UTC] No.36496103{7}[source]▶
Well, I've specifically stated more than once, you don't need to use Electron specifically. The advantage Electron does provide is relative isolation from your installed browser (which are generally well sandboxed anyhow). The only other significant advantage is they are easier to jail/isolate for use with the likes of appImage, Snap and Flatpak/Flathub. So you can target multiple Linux platforms with a single build process, without dependency hell or getting stuck on older repository releases. Electron also offers a consistent option for your application's packaging and updates along with a consistent browser surface, where a separately packaged application that uses the system's browser will be indeterminant in terms of potential render issues and bugs.

Again, not that I'm advocating for Electron specifically, and haven't been. I've specifically mentioned Tauri and others as alternatives that use the system's browser engine, which you have repeatedly ignored.

replies(1): >>36497279 #
13. CyberDildonics ◴[27 Jun 23 19:03 UTC] No.36497279{8}[source]▶
relative isolation from your installed browser

What does this mean? What specifically do you think is being prevented?

The only other significant advantage is they are easier to jail/isolate for use with the likes of appImage, Snap and Flatpak/Flathub.

How is a program with hundreds of megabytes of dependencies easier than a single small statically compiled binary?

Again, not that I'm advocating for Electron specifically,

This thread was about people using electron even though users hate it.