I think OP is both right, and there was people still complaining about it. Atom was seriously slow. Everyone said you couldn’t build a fast text editor that could compare to native ones. VS Code came and it was significantly faster. Atom was slow to the point of not being usable to some, while VS Code was perfectly usable. The people wanting vim or Sublime performance were still upset and wrote about it, but vscode was perfectly usable and fast enough for the majority of people. It was indeed held as an example of how to make a performant electron app. Still an electron app, but not absolute slog. Tbh, if you disable all extensions in vscode, it’s still fairly fast, and doesn’t even take that much memory. It’s not as usable without extensions though.

It comes down to package distribution.

Chrome had already solved the hard problem of "how do we support webcams on linux, windows, and mac" and you as the dev just needed to use the Javascript webcam api. ( https://developer.mozilla.org/en-US/docs/Web/API/MediaDevice... )

In C++ land, you are ultimately going to either need to cook up your own webcam library or look for a 3rd party (which, in 2010, likely didn't exist) to provide it.

Today, there are a few easy to discover rust crates which provide cross platform webcam apis. But further, rust does cross platform better than C/C++ IMO. It's really easy to change how code is compiled based on the target. That was all well thought out because rust was supposed to be a language for browsers.

Dynamic vs static linking is mostly a red herring for desktop GUI application development unless you want to integrate into something like Linux distro package managers, as dynamic libraries on Mac and Windows can be self-contained within the application bundle/directory with no disadvantage beyond marginally longer startup time, and you can do similar things with Flatpak and friends on Linux.

The real difference is that Rust provides a package repository with a unified build system that's as simple to use as NPM or NuGet.

vcpkg which is similar exists today, but it didn't in 2015 when Discord started, still isn't anywhere near as comprehensive as package repositories for languages where package management is part of the standard toolchain, and the underlying build systems are far messier under the hood.

It can also be helpful in development to use libraries built from source as part of the application's build process, at least as an easily-accessible option, which wasn't common practice in most C/C++ ecosystems historically where different libraries used different build systems and if you wanted to integrate them into something like a Visual Studio solution for easy reference to source code during development and debugging you were often on your own.

Why is it no one ever seems to do it then? I have never seen a Java app look or act native on Windows.

JetBrains IDEs arguably look/behave better than VSCode as far as a native app goes. I wouldn't say either look great on MacOS but a truly "native feeling" Mac app is usually quite different than a Linux/Windows equivalent.

I never really understand this attitude. It isn't really hard it took one or two evenings to understand how native libraries work and you close this problem forever.

> Strangely enough we managed to write portable code across platforms during the last century,

Yep, that argument always seems strange too me. Do people fear that much to design their own interface and hook to each platform ecosystem? You look at something like the BSD which runs brought one single kernel concept and various subsystems across a variety of hardware. And somethine like libao[0], which provides a common interface to various sound system.

Whatever the app, if you care enough, you can abstract the core features away from the GUI and other various dependencies.

[0]: https://xiph.org/ao/

GPUI/Zed devs are trying to contact discord to see what can be improved:

> Hi Stanislav, I'm one of the core maintainers for GPUI at Zed, if anyone at discord would like to talk to us about improvements to the framework or to upstream your customizations, please get in touch! My DMs should be open :)

https://twitter.com/radgendervibes/status/211810701651020193...

Herdr's new native app uses GPUI for it's mod framework, so hopefully as more apps adopt it, a better community/package/release process builds around it.

Click either of the 2 links at the top right of the page, and you get screenshots of GPUI apps.

Probably because it's not meant to be like Bootstrap.js where everyone's UI looks identical?

I'm not sure if a cross-platform UI framework is a good idea or not. I've been building with QT for 15 or 20 years now, and I'm still not sure if cross-platform framework is a better idea than just writing a different UI as a thin layer on top of your business logic for each platform.

Certainly, if you write a native UI for every platform, you're going to need a few more people because you have to have someone who understands each platform. However, with a little bit of work you can define some good interfaces to that UI and most of your needs are going to be things that are not the UI framework but they're logic that can be cross-platform.

What cross-platform frameworks give you more than the UI is all the other pieces you need. I've written a bunch of applications in Qt Core with no UI at all because it's so convenient to have those Qt abstractions.

That's like saying it would make sense to make Internet Explorer work on all platforms. It doesn't make sense.

The solution is to use user interface toolkits that are available on each platform. For example, wxWidgets or Qt or appropriate bindings to them if you can't be bothered to write UI code for each platform you're targeting.

Using Rust/wasm for a mobile apps sounds crazier to me than using Electron on desktop. I'm not sure of the details there but the APIs/SDKs bringing consistency is one of the best parts of mobile. There's less of an argument for that on desktop which moves slower and is mouse/keyboard instead of complex set of touch workflows, paging, and notification schemes.

nice point, people like to shit on the web but it has one of the biggest accessibility features that most of the gui frameworks would just leave them as feature suggestions for years

i switched a cross platform application TO web stack for this reason. accessibility and screen reader usability is incredibly important and massively overlooked in many domains

We could, if people would stop doing it today.

I made a bunch of Electron apps in my time. I always tried to talk the client out of it. "Just make it a website" I would say. Still, there were times where it made sense.

> We can just admit that it was a good solution for the problems of its time just like JQuery.

We would be lying if we did that. Electron was never, ever a good solution. It was something solely used by devs who prioritized their own ease of work over the actual user experience, i.e. bad devs.

I never thought election was a good solution for the problems of its time. Just call it a web app and don't lie to people releasing something "native" for them to download.

It was never a good solution and there is no reason to ever stop calling a turd a turd.

Electron was an ok solution to the problem they were looking at, “how do I waste as much compute as possible.” Unfortunately it had the side effect of drawing a bunch of stuff on the screen.

Luckily in the modern era we have invented language models, which allow us to expend vast resources on text generation instead.