Even vs code is slow compared to a native app - noticable with large or many files; with search and replace in larger files (xx mb) it even crashes

Actually I think "properly tuned" sounds like weasel words, a no true scotsman fallacy. "Oh electron is slow? Well, it is slow, but that's not real electron, see if you were doing things the right way it would be fast"

I'm fairly sure VS low performance and responsiveness is caused by their use of WPF for the UI. Never seen a single responsive application written in that toolkit, it's even worse than electron. Not surprised it hasn't taken off outside of enterprises.

It used to be fast before 2010, when they used MFC (or something very similar to it, I don't remember anymore), compiled to native code.

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.

IIRC Qt is LQPL, so if you linked it statically you'd have to license your code as LGPL too. Shipping Qt as a separate dll didn't trigger that issue.

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.

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

They had native looking skins for Swing that still felt slightly off and behaved differently. Netbeans IDE looked nice, but it was weird in subtle ways.

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/

Probably an economical thing. If you have a much higher effort with packaging and testing vs coding the app logic.

If developers don't want to be replaced by AI they need to bring something to the table because employment is not a charity.

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.

Honestly GPUI feels like the closest thing we have to a working UI framework for Rust. That's probably because GPUI is not developed in a vacuum, it actually needs to work at Zed's scale because they ship a real product and GPUI needs to deliver.

I'm very excited to see GPUI extended for general purpose usages in the future.

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.

You don't need "native" part if you are moving from Electron app

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.

Users will test.

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.

> bunch of janky apps that don't work right

Is that really fair? Those janky apps include vscode and slack! There are real technical arguments, but they're comparatively minor and very treatable when you look at it as a technical hurdle.

Which is I think why people who've picked a side get so upset over it and find themselves resorting to vague adjectives like "janky".