Hacker News Reader

Comment by pointlessone | Hacker News Reader

I’d wager that it’s as native as Electron. It might be faster, sure, but it’s not native to any platform.

raph wrote about that already: https://raphlinus.github.io/rust/gui/2022/07/15/next-dozen-g...

I agree that there’s chaos everywhere and system integration on individual axes is a better way to look at it but then it turns out that Electron is more native than most GUI libs out there. Browser devs worked very hard and for a long time to integrate with host OSes. Browsers have native text rendering, good accessibility, IME support on all platforms, etc. All these features are usually missing from the hot new UI libs.

ImHex is a great hex editor, lots of features. It’s got antialiased fonts like only a year ago. Fonts still look not exactly as the rest of the OS. Has no accessibility integration at all.

Zed, looks pretty good at first glance. No accessibility.

“Native” implies all the features that the platform provides. It is chaotic on all major platofrms but it’s still meaningful.

How so? It renders to a window buffer using your GPU API and interfaces with your OS for event handling. Electron renders using an embedded browser and uses said browser for input/events. Isn't that quite different?

> but it’s not native to any platform

Why is this still a talking point? So what if the app renders with AppKit or Cairo on macOS, you can both look as native as the other, doesn't the actual UX matter more than how the implementation was made?

> you can both look as native as the other, doesn't the actual UX matter more than how the implementation was made?

An Electron app that draws all its components mostly like the native controls will still not be native and have the same integrations etc. that native apps usually get.

You could get close but some things like for example "ctrl+f" search have native widgets that work different/look different that an electron app realistically won't have. Or for example you will never get the same liquid glass materials that macOS uses in an electron app.

So yea, native in my books means using the platform native (UI) apis. On Ubuntu for examples thats GTK, on Windows its.... idk at this point, WinUI? and on KDE it would be Qt.

You can technically get those platform native things by integrating with the native APIs. There's basically a full spectrum from "native" to "custom" rather than it being either-or.

You can get all those things in a Rust application drawing with Cairo on macOS, but that isn't "native" according to you regardless, because it's using Cairo instead of AppKit/SwiftUI?

Again I don't understand the obsession with caring so deeply about the implementation, as long as the end results are the same, why it matters so much?

My point is practically you don't get the same results unless you use the native APIs the the platform provides.

Take my Liquid Glass for example, you simply won't be able to match the look in an electron app in practice.

Ofc if the result is the same it doesn't matter how, but in reality it's almost impossible to imitate the look and capabilities since it would require a Herculean effort to keep feature parity.

Right, but you could call native APIs from JavaScript or Java say, then in your world that's a "native" application because it uses the APIs the platform provides, regardless of how it actually was implemented? Meanwhile, an application could be implemented with Objective-C and/or Swift but not use Cacoa/AppKit/SwiftUI APIs, then that's not an native application because it doesn't look like one? Like games written with Vulkan/OpenGL aren't "as native" as one using Metal I'd presume?

you could call native APIs from JavaScript or Java say, then in your world that's a "native" application because it uses the APIs the platform provides

Yes, this is what we want.

an application could be implemented with Objective-C and/or Swift but not use Cacoa/AppKit/SwiftUI APIs, then that's not an native application

Correct. The toolkit matters, not the language. Native toolkits have very rich and subtle behavior that cannot be properly emulated. They also have a lot of features (someone mentioned input methods and accessibility) that wrappers or wannabe toolkits often lack. To get somewhat back on topic I notice and appreciate that Xilem mentions accessibility.

games written with Vulkan/OpenGL aren't "as native"...

Games are usually fullscreen and look nothing like desktop apps anyway so it doesn't matter what API they use.

Reply on news.ycombinator.com