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

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!

It's the fact that manpower can't keep up with the exploding amount of complexity and use cases that happened to computing in the last decades.

We went from CLI commands and a few graphical tools for the few that actually wanted to engage with computers, to an entire ecosystem of entertainment where everyone in the world wants 'puters to predict what could they want to see or buy next.

To maintain the same efficiency in code we had in the 90-2000s, we would need to instantly jump the seniority of every developer in the world, right from Junior to Senior+. Yes, you can recruit and train developers, but how many Tanenbaums and Torvalds can you train per year?

The biggest amount of cruft not only went to dark patterns and features in programs like animations and rendering that some people regard it as "useless" (which is debatable at minimum). But the layers went also to improve "developer experience".

And I'm not talking about NodeJS only. I'm talking about languages like Python, Lua, or even the JVM.

There's a whole universe of hoops and loops and safeguards made so that the not-so-genius developer doesn't shoot themselves in the foot so easily.

I'm sure that you can delete all of that, only leave languages like Rust, C and C++ and get a 100x jump in performance. But you'd also be annihilating 90% of the software development workforce. Good luck trying to watch a movie in Netflix or counting calories on a smartwatch.

Part of the "problem" with Windows is also lack of legacy reliance. As in: MacOS and Linux are at heart Unix systems, with a kernel architecture meant for 1970s hardware. The Windows NT kernel family is a clean-sheet design from the 1990s, a time where compute resources were much more plentiful.

For example, on Linux file system access has (by default) very basic permissions, and uses a closely coupled file system driver and memory system in the kernel. On Windows there is a very rich permission system, and ever request goes through a whole stack of Filesystem Filter Drivers and other indirections that can log, verify or change them. This is great from a functionality standpoint: virus scanners get a chance to scan files as you open them and deny you access if they find something, logging or transparent encryption is trivial to implement, tools like DropBox have an easy time downloading a file as you access it without dealing with implementing a whole file system, the complex permission system suits enterprise needs, etc. But on the other hand all these steps make the system a lot slower than the lean Linux implementation. And similar resource-intensive things are happening all over the kernel-API in Windows, simply because those APIs were conceived at a time when these tradeoffs had become acceptable.

Devs at MS have to make everything right in an universe where everything else is dead or crap. And the fact that Windows 11 can even run without crashing daily is an engineering marvel.

PD: Not to defend MS, but I'm sure their current devs are very capable and doing their best.

You are looking back with rose tinted glasses if you think all software was blazing fast back then. There was a reason putting your cursor on a progress bar to track whether it was moving was a thing.

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.

This doesn't strike me like something "everyone in the world wants", but rather something a small group of leaches is pushing on the rest of the population, to enrich themselves at the expense of everyone else. I'm yet to meet a person that would tell me they actually want computers to tell them what to see or buy. And if I met such person, I bet they'd backtrack if they learned how those systems work.

Exercise for the reader: name one recommendation system that doesn't suck. They all do, and it's not because recommendations are hard. Rather, it's because those systems aren't tuned to recommend what the users would like - they're optimized to recommend what maximizes vendor's revenue. This leads to well-known absurdities like Netflix recommendations being effectively random, and the whole UX being optimized to mask how small their catalogue is; or Spotify recommendations pushing podcasts whether you want them or not; or how you buy a thing and then get spammed for weeks by ads for the same thing, because as stupid as it is, it seems to maximize effectiveness at scale. Etc.

> I'm sure that you can delete all of that, only leave languages like Rust, C and C++ and get a 100x jump in performance. But you'd also be annihilating 90% of the software development workforce. Good luck trying to watch a movie in Netflix or counting calories on a smartwatch.

I'll say the same thing I say to people when they claim banning ads would annihilate 90% of the content on the Internet: good. riddance.

Netflix would still be there. So would smartwatches and calorie counting apps. We're now drowning in deluge of shitty software, a lot of which is actually malware in disguise; "annihilating 90% of the software development workforce" would vastly improve SNR.

The reason it's not a thing today is because those progress bars got replaced by spinners and "infinite progress bars". At least back then you had a chance to learn or guess how long slow operations would take. These days, users are considered too dumb to be exposed to such "details".

Yes, but still it seems to be useless to implementers, because practically every virus scanner implements braindead stuff like DLL injection for on-access-scanning.

By requiring more than that, we had to increase the essential complexity. I believe this tradeoff in itself is well worth it (and hopefully we can all agree on that going back to us-ascii-only locale is not a forward direction).

The problem I see is that the layers you also mention, each expose leaky abstractions (note that abstractions are not the problem, no person on Earth could implement anything remotely useful without abstractions — that’s our only tool to fight against complexity, of which a significant amount is essential, that is not reducible). Let’s also add a “definition” I read in a HN comment on what constitutes an ‘expert’: “knowing at least 2 layers beneath the one one is working with” (not sure if it was 1 or 2).

Given that not many people are experts and a tendency of cheaping out on devs, people indeed are only scratching that top layer (often not even understanding that single one!), but the problem might also be in how we organize these layers? When an abstraction works well it can really be a breeze and a huge (or only significant, see Brooks) productivity boost to just add a library and be done with it — so maybe the primitives we use for these layers are inadequate?

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.

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.

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.

Consider the feature set of JavaFX when used in combination with the AtlantaFX theme/widget pack. It isn't well known, but is maintained and has an active open source community today.

- All the same controls as mui.com shows and more advanced ones too, like a rich text editor, a way more advanced table view, tree views, table tree views, etc.

- Media and video support.

- 3D scene graph support. HTML doesn't have this! If you want to toss some 3D meshes into your UI you have to dive into OpenGL programming.

- When using FXML, semantic markup (<TabView> etc)

- Straightforward layout management.

- A dialect of CSS2.something for styling, a TextFlow widget for styling and flowing rich text.

- Fully reactive properties and collections, Svelte style (or moreso).

- Icon fonts and SVG works.

- Sophisticated animations and timelines API.

And so on. It's also cross platform on desktop and mobile, and can run in a web browser (see https://jpro.one where the entire website is a javafx app), and can be accessed from many different languages.

Flutter is actually not quite as featureful in comparison, for example there's no WebView control or multi-window support on desktop, though Flutter has other advantages like the hot reload feature, better supported mobile story. The community is lovely too.

Then you have AppKit, which is also very feature rich.

So it's definitely a task that people have done. Many of these toolkits have features HTML doesn't even try to have. The main thing they lack is that, well, they aren't the web. People often find out about apps using hypertext and being able to have a single space for documents and apps is convenient. When you're not heavily reliant on low friction discovery though, or have alternatives like the app stores, then web-beating UI toolkits aren't that big of a lift in comparison.

> 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

Electron is great, but most apps aren't VS Code. On my 2019 Intel MacBook Terminal.app starts in <1 second and WhatsApp starts in about 7 seconds. Electron is Chrome and Chrome's architecture is very specifically designed for being a web browser. The multi-process aspect of Chrome is for example not a huge help for Electron where the whole app is trusted anyway, though because HTML is so easy to write insecurely, sandboxing that part of it can still be helpful even with apps that don't display untrusted data. That yields a lot of overhead especially on Windows where processes are expensive.

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.

I also said, "Flutter is about as close as you can get" regarding coming close to what I was referring to.

AppKit is NOT cross-platform. Beyond this, you have other means of embedding a browser-ui application without all of chrome included, see Tauri as one example.

What are the specs on the machine you're using?

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

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.

It later turned out to be due to some Unicode handling in-built into a windows api they were using, while the developer’s version also not completely feature-complete. But both sides were sort of right.

Like beyond truly "dumb" tasks like downloading a file it's basically a guessing game how long it will take anyway, right? Say you split the whole loading bar into percentages based on the number of subtasks, suddenly you end up with a progress bar stuck on 89% for 90% of the total loading time.

Obviously you could post-hoc measure things and adjust it so each task was roughly "worth" as much as the time it took, but people rarely did that back in the day and my boss would get mad at me for wasting time with it today. Hence, spinners.

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.

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.

Sure. But now as a user, I get to see the glimpse of what's going out under the hood. Combined with other information, such as a log of installation steps (if you provide it), or the sounds made by the spinning rust drive, those old-school determinate progress bars were "leaking" huge amount of information, giving users both greater confidence and ability to solve their own problems. In many cases, you could guess the reason why that scrollbar is stuck on 89% indefinitely, just by ear, and then fix it.

Conversely, spinners and indeterminate progress bars deny users agency, and disenfranchise them. And it's just one case of many, which adds up to the sad irony of UI/UX field - it works hard to dumb down or hide everything about how computers work, and justifies it by claiming it's too difficult for people to understand. But how can they understand, how can they build a good mental model of computing, when the software does its best to hide or scramble anything that would reveal how the machine works?

Just to make sure I'm not being one of those people: What AccessKit [1] has now, across Windows, macOS, and Linux, took roughly six person-months of work. We still need to support more widget types, especially list views, tables (closely related), and tree views, but we do already have text editing covered on Windows and macOS. Perhaps it helps that I'm an accessibility expert, especially on Windows. Anecdotally, it seems that implementing UIA from scratch is daunting for non-experts. But I guess in the big picture it's really not that hard.

[1]: https://github.com/AccessKit/accesskit

Almost like some kind of... web OS?

To think we almost had it, but Palm made some bad decisions back in 2009 and the dream of app-as-browser + Node.JS + consistent application styling and syscalls through a provided JS framework (Enyo) is, sadly, probably dead forever.

Microsoft has been trying to migrate Windows development to a managed language for over 20 years; their first attempt at this was a complete disaster and NT 6.0 (Vista) would ultimately be developed the old way.

It's only really been in the last 5-7 years, with Windows 10 and 11, that MS has managed to get their wish as far as UI elements go, which is why the taskbar doesn't react immediately when you click on it any more and has weird bugs that it didn't have before.

I thought that the NT Kernel was heavily based on VMS. When Dave Cutler, their chief OS architect/guru left for Microsoft and took a bunch of engineers with him. FTA:

"Why the Fastest Chip Didn't Win" (Business Week, April 28, 1997) states that when Digital engineers noticed the similarities between VMS and NT, they brought their observations to senior management. Rather than suing, Digital cut a deal with Microsoft. In the summer of 1995, Digital announced Affinity for OpenVMS, a program that required Microsoft to help train Digital NT technicians, help promote NT and Open-VMS as two pieces of a three-tiered client/server networking solution, and promise to maintain NT support for the Alpha processor. Microsoft also paid Digital between 65 million and 100 million dollars."

[0] https://www.itprotoday.com/windows-client/windows-nt-and-vms...

The early 00’s “open standard” of web forum + eMule + VLC would still be light years ahead of Netflix&co. if it weren’t for how hard it’s been gutted by governments, copyright lobbies, ISPs and device/platform vendors through the years. Heck, the modern equivalent often still is (despite all the extra hoops), unless you are trying to watch the latest popular show in English.

Not my area but AFAIK modern (electron based) desktop apps are less accessible then classic win32 apps from win2k - win7.

You just describe modern Web Development.

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.

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.

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.