Hacker News new | ask | show | jobs
by ghosty141 66 days ago
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.

1 comments

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.